Given the current situation of KPNQwest and the possibility
of its services going offline sometime soon, the RIPE NCC in
agreement with KPNQwest will be temporally hosting this
server (ns.eu.net) in its premises.
nice emergency hack and sorry to whine. but i used them both
to get diversity.
when in less of a panic, please move it to moscow or something.
randy
> Given the current situation of KPNQwest and the possibility
of its services going offline sometime soon, the RIPE NCC in
agreement with KPNQwest will be temporally hosting this
server (ns.eu.net) in its premises.nice emergency hack and sorry to whine. but i used them both
to get diversity.
Hi Randy,
there are 16 ccTLDs for which ns.ripe.net and ns.eu.net are both secondary. So we will definitely request those ccTLDs to look for a new host as soon as possible.
The rest can take bit more time to think what they want to do since ns.eu.net will keep running.
We are offering secondary service on ns.ripe.net for any ccTLD that we weren't sencodaring for, as are other people.
The idea is not to have ns.eu.net running for ever, just to enable people to have time to take rational decisions, without the fear of having the server going away because of some unexpected turn of events.
when in less of a panic, please move it to moscow or something.
Panic? what panic? this is just common sense
Joao
Hi People,
Here from Intelideas (AS12359) we are ready for hosting ccTLDs in our
network. We are present in Espanix, Linx, Catnix and diverse upstreams.
Our contact data:
DNS: dns@intelideas.com
DNS Master: Enrique Iglesias Rodriguez. (+34 917882517)
regards,
Daniel
Intelideas
I suggest that if the RIPE need another provider that they
take time and issue a proper RFI/P/Q through the European
Journal. It does ask an interesting question over disaster
recovery in situations like this.
Regards,
Neil.
Yes Neil,
It should be interesting to know the 'official' requirements/recommendations
for ccTLD's hosting
For example: diversity geographical, network needs, security needs, building
environment., etc
Regards,
Daniel
Intelideas
This is not a political question, only operational process.
Has ICANN and NTIA worked out their operational issues so they can quickly
change the root zone to reflect changes in ccTLD nameservers if people
need to change which name servers are handling the ccTLDs. Last year,
some of the ccTLD operators were complaining it sometimes took weeks after
they submitted the change for it to make it into the root zone.
I tried this game fall 2000. It was a farce. We (I then worked at NIC-SE,
the SE registry) tried to remove "sparky.arl.mil" from the SE delegation.
After all the politcs in Sweden wrt this move had been sorted out, we
e-mailed the correct (as announced on webpage) contact at IANA/ICANN.
Weeks went by.
Nothing happened.
We grew tired of this and started pulling some threads. ONLY after informal
prodding (by well-known people that then had no formal role in SE
operations) the root zone was updated! And, we NEVER got any
acknowledgement back, we simply noticed that the delegation had been
adjusted.
We were not impressed. I thought along the same lines as Sean, poor ccTLDs
if this (root admin unresponsiveness) is a continuing state of affairs...
Has ICANN and NTIA worked out their operational issues so they can quickly
change the root zone to reflect changes in ccTLD nameservers if people
need to change which name servers are handling the ccTLDs. Last year,
some of the ccTLD operators were complaining it sometimes took weeks after
they submitted the change for it to make it into the root zone.
that was the fast track. it can take months.
luckily, the dns protocols will route around this kind of damage as
long as a primary or secondary remain alive.
randy
ns.eu.net has not "broke". At least not yet.
KPNQwest still has very competent people (and I would like to specifically thank Berislav Todorovic for embracing the idea of placing ns.eu.net outside KPNQwest to ensure stability and for all the support in actually doing it)
The RIPE NCC doesn't currently need further support to operate the service, which is why we volunteered to do it, to provide a stable service until further steps are undertaken without the concern for the time period KPNQwest will be able to continue to operate.
With time, since EUNet will not exist, ns.eu.net should also disappear (I am not quite sure the RIPE NCC would want to "own" the eu.net domain), but it should be after everyone has got time to think properly about a solution that suits them in the long term.
Cheers,
Joao
I've only been able to find a best practise guideline that specifies
that the nameserver be online 24/7.
(http://www.wwtld.org/ongoing/bestpractices/BestPractice_10Mar2001.html)
I found it interesting to note that a significant number of cctld servers
ignore the suggestions for root-servers in BCP40/RFC2870...
"Other major zone server operators (gTLDs, ccTLDs, major zones) may also find
it useful." and leave recursion enabled on the ccTLD servers (2.5) - the old
ns.eu.net was one of these, I believe RIPE have done the right thing with the
new one.
What is even more disturbing is that there is a non-zero number of ccTLD
servers that are still cache poisonable.
Months? Years more like.
.nz have been trying to update their whois information for a couple of
years (IIRC) now. From what I understand the update have been refused
since their won't sign the ICANN contracts (like 95% of the other TLDs)
NOTE: The specific change I'm thinking of is their street address (and
organisation name for that matter). I *think* a name server change *did*
go though after a lot of pushing.
Disclaimer: I'm not involved with running .nz at all nor ICANN politics
for that matter.
This is not a political question, only operational process.
Has ICANN and NTIA worked out their operational issues so they can quickly
change the root zone to reflect changes in ccTLD nameservers if people
need to change which name servers are handling the ccTLDs. Last year,
some of the ccTLD operators were complaining it sometimes took weeks after
they submitted the change for it to make it into the root zone.
Actually what worries me more is the following.
I did a small check on how frequently DNS servers occure in the European ccTLDs NS records. If I leave out the ones that only oocure once, I get the following :
14 NS.EU.NET.
10 NS.UU.NET.
9 SUNIC.SUNET.SE.
3 NS2.NIC.FR.
2 NS.RIPE.NET.
2 NS-EXT.VIX.COM.
2 DNS.PRINCETON.EDU.
2 AUTH02.NS.UU.NET.
This is after checking 18 ccTLDs. Most of them only have four secondaries. If I read this correctly, the geographic distribution of servers is not that bad, but it could be better. Preferably by going with more than four secondaries. Consider that up until not to long ago, several of these servers where behind the same upstream.
Best regards,
- kurtis -
A lot of the older secondary nameservers for ccTLDs were also the
recursive nameservers for the ISP/Organisation providing the secondary
service. ns.eu.net is a classic example of this.
With the valid quips about how long it takes to update glue/NS sets in the
roots[1], a fair number of these ISPs/Organisations had found that
shifting the ccTLD secondary function to a proper non-recursive server[2]
was simply not practical.