Re: KPNQwest ns.eu.net server.
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
At 11:04 -0700 5/6/02, Randy Bush wrote:
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
randy
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 On Thursday 06 June 2002 01:08, Joao Luis Silva Damas wrote:
At 11:04 -0700 5/6/02, Randy Bush wrote:
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
randy
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. -- Neil J. McRae - COLT neil@COLT.NET
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 On Thursday 06 June 2002 15:59, Neil J. McRae wrote:
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.
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.
--On Thursday, June 06, 2002 10:47:52 -0400 Sean Donelan <sean@donelan.com> wrote:
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... -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
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
On Thu, 6 Jun 2002, Randy Bush wrote:
that was the fast track. it can take months.
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. -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz
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 -
On Thu, Jun 06, 2002 at 04:24:40PM +0200, Daniel Concepcion wrote:
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
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.
On Thu, 6 Jun 2002, John Payne wrote:
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.
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. --==-- Bruce. [1] teckla.apnic.net, trf.nic.ad.jp, etc[3] [2] Some ISPs do still 'need' to allow recursion to cater for their roaming customers. imo, customers are easier to change than the root. [3] some quick stats on the hosts mentioned in the root ('.') zone from a viewpoint in Amsterdam: Number of records: 657 Number of fully valid hosts: 481 Number of partially valid hosts: 110 Number of invalid hosts: 175 Number with reverse matching: 455 Number knowing about themselves: 551 Number not knowing about themselves: 106 fully valid = all of the nameservers for the domain the nameserver is in know about the nameserver (all NS for example.com answer for for ns1.example.com) partially valid = some of the NS for the domain the nameserver is in do not know about the nameserver in question. Note that the answer is skewed slightly due to multiple answers received. invalid hosts = This host only exists in the root glue. No nameservers for the domain the nameserver is in know about the nameserver. Answer possibly skewed due to my assumption in what the 'parent' domain for the nameserver is (cut -d '.' -f 2-) reverse match = name -> A -> PTR == name knowing about self = Asking the ip in the root glue for the name gives a sensible answer. (imo, this is a Good Thing, but unfortunately I don't believe that any exact requirement for this exists)
participants (10)
-
Bruce Campbell -
Daniel Concepcion -
Joao Luis Silva Damas -
John Payne -
Kurt Erik Lindqvist -
Måns Nilsson -
Neil J. McRae -
Randy Bush -
Sean Donelan -
Simon Lyall