Randy, On Jan 18, 2008, at 3:29 PM, Randy Bush wrote:

i'll bet you one really nice dinner that the icann and commerce political process to fix this will actually complete before you can get email back from all admin and tech pocs from 23 cctlds.

I would not take that bet.

and please tell me why any of the tech and admin pocs of these cctlds should give a <bleep> what my server's actual ip address is.

The theory is: because they are responsible for the domain. You see, existing policy states that IANA is not supposed to make changes to TLDs (especially ccTLDs which are considered to have national sovereignty issues tied up with them) that have not been explicitly requested by the administrative and technical contacts for the zone. I believe the idea is that there was concern that ICANN (seen as a pawn of the US government in many quarters) could pull the rug out from under a ccTLD admin without their knowledge. That would be bad. Hence, IANA requires explicit approval from _all_ the parties involved. And in the case of a shared name server amongst multiple TLDs, this can take an exceptionally long time. I am aware of the implications (dare I say silliness) of this requirement, but that's layer 9 for you. I believe your request will cause some forward motion towards trying to resolve this, but don't expect changes overnight. Regards, -drc

Randy, On Jan 18, 2008, at 5:07 PM, Randy Bush wrote:

but, in actual fact, this does not change the ccTLD's zone file or date one bit. the request is to add a AAAA RR to the existing A RR *for my server* in the root zone to act as glue.

The key term here is "root zone". As you are undoubtedly aware, there are those who treat the contents of the root zone (including glue) as sanctified ground that may only be tread upon after a ritual purification, sacrifice of numerous virgin chickens, etc. Or something like that. More seriously, as I've said, this is a known problem and your request will likely help movement towards fixing it. My apologies that it hasn't been fixed already.

the ccTLDs' delegations are not changed by one bit.

I won't argue although there are those that could (and have).

the iana publishes data about one of *my* servers. these data have become erroneous by omission. i am merely asking that they be fixed.

Understood. And current policy requires IANA to get explicit agreement from the AC and TC that they approve that fix (even though they are not directly responsible). As much as I might wish otherwise, IANA (in the layer 9 world it occupies) can't unilaterally change that policy.

is the horse dead yet? :)

I (sincerely) wish... Regards, -drc

On Fri, 18 Jan 2008, David Conrad wrote:

Randy,

On Jan 18, 2008, at 5:07 PM, Randy Bush wrote:

...

but, in actual fact, this does not change the ccTLD's zone file or date one bit. the request is to add a AAAA RR to the existing A RR *for my server* in the root zone to act as glue.

The key term here is "root zone". As you are undoubtedly aware, there are those who treat the contents of the root zone (including glue) as sanctified ground that may only be tread upon after a ritual purification, sacrifice of numerous virgin chickens, etc. Or something like that.

...

the iana publishes data about one of *my* servers. these data have become erroneous by omission. i am merely asking that they be fixed.

Understood. And current policy requires IANA to get explicit agreement from the AC and TC that they approve that fix (even though they are not directly responsible). As much as I might wish otherwise, IANA (in the layer 9 world it occupies) can't unilaterally change that policy.

Once you realise that layer-9 issues are the sticking factor, you quickly go the route of setting up different, ccTLD-specific names for your nameserver to ensure that future changes require just 3 parties, you as technical contact, the ccTLD admin as admin contact, and IANA. It beats 3+N parties being involved, where N is the number of ccTLDs that you have secondaried, plus it also eases future migration when you have a secondaried ccTLD being the next hot thing in query rates. Or you could hope that whoever processes your request at IANA doesn't check for how many ccTLDs your nameserver has ;). -- Bruce. eg, ns-XX.ripe.net where XX is the ccTLD code.

On Jan 18, 2008, at 5:08 PM, Edward Lewis wrote:

Sticking up for IANA...

Thanks!

It makes sense to me. If I ask someone to slave my zone, I'm placing (perhaps implicit) trust that they will operate the server in a responsible way. I don't have the prerogative to tell the other person how to run their server but I have the prerogative to withdraw the slave request if I an unhappy with the way they operate the server. It makes sense to me that if you are operating a slave for someone, they get to be notified of the changes you make before they go into effect.

Even if it may take time to contact all the zones administrators.

Right. The challenge is that current policy requires explicit approval from both the Administrative and Technical contacts for the zone (to ensure they have really been notified). As shocking as it might be to some, there are ACs and TCs that don't respond to (repeated) e-mail (or faxes or telephone calls) from IANA. This can (and has) caused requests for name server changes to block. This is a known problem and was the subject of a public comment request quite some time ago (see http://forum.icann.org/lists/root-glue-comments/ for the responses). Unfortunately, things sort of got stuck. Hopefully, Randy's request will unstick things. Regards, -drc

On Fri, Jan 18, 2008, Leo Bicknell wrote:

It would seem to me that a middle ground is in order.

Contact the TLD's. Send them two e-mails, and two faxes. But all of those should contain "you have 30 days to object, or we will move forward anyway".

You'd think there'd be a SLA in place. Agreeing to run part of the internet infrastructure implies you'll respond to certain requests within a given timeframe. Or am I simply asking too much? :) Adrian

On Sat, Jan 19, 2008 at 08:29:15AM +0900, Randy Bush wrote:

...

IANA is expecting to add the AAAAs of the 4 root servers that have requested it (to date) on/around 4 Feb.

way cool!

...

As you will (or already have) discover, you are entering a particularly unpleasant area of existing policy, namely dealing with a name server that is shared by many TLDs. We're trying to fix this, but (as with seemingly all things associated with ICANN), it is taking too long.

indeed. part of the reply i got is utterly amazing! quote from that reply (not from you) is as follows:

...

Before we can make the IPv6 address addition for this name server in the root zone, we need to get confirmation from the listed contacts for all 21 ccTLD managers (both the administrative and technical contacts for each TLD).

[ aside from s/21/23/ ]

i'll bet you one really nice dinner that the icann and commerce political process to fix this will actually complete before you can get email back from all admin and tech pocs from 23 cctlds.

and please tell me why any of the tech and admin pocs of these cctlds should give a <bleep> what my server's actual ip address is. isn't the dns specifically supposed to provide the level of indirection to obviate this?

its been this way since at least 2003, when there was an effort to get som servers changed, when ICANN first allowed AAAA records into the root zone. Some requests are over four years old. :(

i hope they pay you a lot.

randy

On Sat, Jan 19, 2008 at 11:08:54AM -0800, David Conrad wrote:

Bill,

On Jan 19, 2008, at 10:52 AM, bmanning@vacation.karoshi.com wrote:

...

its been this way since at least 2003, when there was an effort to get som servers changed, when ICANN first allowed AAAA records into the root zone. Some requests are over four years old. :(

The oldest root management request IANA has in its queue is about 1 year old and is unrelated to glue policy. The oldest glue related request (adding a AAAA to f.root-servers.net) is 10 months old and will be processed (along with the 3 other outstanding root server requests) on/around 4 Feb after the ICANN board mandated public notification period.

If you have reason to believe there are older outstanding requests, please let me know (preferably privately as I would imagine this isn't particularly in the charter of NANOG's mailing list).

ah... a bit of digging shows that the IANA (prior to your tenure) closed the request for unspecified reasons. I suspect that it was due to the then unstated policy that ccTLD holders control the glue of the nameservers publishing their data. --bill

Thanks, -drc

On 21 jan 2008, at 14:02, Stephane Bortzmeyer wrote:

...

and please tell me why any of the tech and admin pocs of these cctlds should give a <bleep> what my server's actual ip address is.

Going back to operational issue (yes, incredible as it may seems, I won't write here what I think of ICANN), there is a *technical* solution to this issue, which is the one deployed by the RIPE-NCC. Give a different *name* (and may be a different *IP address*) to every ccTLD.

This is suboptimal because it limits the opportunity for nameservers to measure RTTs and contact the fastest server. TLD operators should make up their mind: either control their servers, or trust the people that they gave control to to make these kinds of decisions.

On 22-Jan-2008, at 03:47, Stephane Bortzmeyer wrote:

Currently, with the present ICANN procedures, this is not an option. ICANN knows only the TLD managers, not the nameserver managers. For ICANN, rip.psg.com depends on the TLD it serves, not on Randy Bush. (It would be a sensible model, but a different model, with different actors.)

With the current process, renumbering servers can be a lot of work: imagine arranging for (say) twenty different TLD managers of varying responsiveness and with different first languages to send the same message at roughly the same time to IANA, and then imagine the collation exercise required at the IANA to match together the non- synchronised and inconsistent requests that actually arrive. This perhaps goes some way to explain the observed actions of TLD nameserver operators to either avoid or limit the pain of renumbering. Many servers are now numbered out of PI /24s which are used for nothing else; the RIPE NCC's approach (of not re-using the same nameserver name) has already been mentioned. Randy's goal of adding an AAAA record in the root zone to rip.psg.com is, in effect, an exercise in renumbering (even though it's adding an address, rather than changing an existing one). Based on what I've seen, the pragmatic approach is: 1. Renumbering is hard, but there's no workaround, so get ready to endure the pain. 2. Do what you can to avoid having to experience the pain again. In this case, (2) might involve not only adding the AAAA (and, ideally, doing so from a PI /48 assigned under an RIR's critical infrastructure policy, and never using that /48 for anything else), but also renumbering rip.psg.com's IPv4 address into a similarly PI / 24. If there was ever a desire to change the name of the nameserver, this would also be the time to do it. This doesn't fix anything for anybody who follows, of course. Joe

...

Based on what I've seen, the pragmatic approach is: 1. Renumbering is hard, but there's no workaround, so get ready to endure the pain. 2. Do what you can to avoid having to experience the pain again.

On Jan 22, 2008, at 7:46 AM, Joe Abley wrote: 3. Fix the stupid root level glue change notification policy.

which was my goal. i did put "</troll>" at the bottom of the message that started this thread. anything else is a sad hack that does not scale, does not last, and does nothing but make us all feel pretty stoopid. and thank you for working on it, drc. randy

On 22 jan 2008, at 16:46, Joe Abley wrote:

In this case, (2) might involve not only adding the AAAA (and, ideally, doing so from a PI /48 assigned under an RIR's critical infrastructure policy, and never using that /48 for anything else), but also renumbering rip.psg.com's IPv4 address into a similarly PI / 24. If there was ever a desire to change the name of the nameserver, this would also be the time to do it.

I'm quite unhappy about the trend to put everything in their own blocks that happen to be the longest possible prefixes. This means that one oversight in prefix length filtering can take out huge numbers of important nameservers. We really need as much diversity as we can get for this kind of stuff. There is no one single best practice for any of this.

Iljitsch van Beijnum writes:

...

Going back to operational issue (yes, incredible as it may seems, I won't write here what I think of ICANN), there is a *technical* solution to this issue, which is the one deployed by the RIPE-NCC. Give a different *name* (and may be a different *IP address*) to every ccTLD.

This is suboptimal because it limits the opportunity for nameservers to measure RTTs and contact the fastest server.

Only if these nameservers do the Bad Thing and track responsiveness by server name rather than by server address. (I think a well-known DNS implementation does or used to do it this Bad way, which was part of the reason that it sometimes locked on to a server with an unreachable IPv6 address and a fast-responding IPv4 address - and of course it would always try the IPv6 address first )-: -- Simon.