even if Randy is successful to get IPv6 glue records added to the the
root zone, how would I get to them? This is not obvious from my corner
of the net.
In a message written on Fri, Jan 18, 2008 at 12:59:08PM -0800, Andreas Ott wrote:
even if Randy is successful to get IPv6 glue records added to the the
root zone, how would I get to them? This is not obvious from my corner
of the net.
IANA recently made an announcement that AAAA glue in the root will
be added in early February. I believe there are either four or
five root servers with currently operating IPv6 capability that
will be the initial listing.
This particular problem is all but solved, and should be done in
under a month.
even if Randy is successful to get IPv6 glue records added to the the
root zone, how would I get to them? This is not obvious from my corner
of the net.
your point that no root server is bootstrappable by a v6-only site is well taken.
even if Randy is successful to get IPv6 glue records added to the the
root zone, how would I get to them?
well, over dual stack, i guess. but this only means that there is no way to run a v6-only site in a dual stack universe without nat-pt. this is not a surprise to me.
but right now, without being able to find out how to put AAAA in the com zone, even dual stack does not work!
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?
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.
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.
seems perfectly reasonable.
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 ccTLDs' delegations are not changed by one bit.
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.
i strongly agree with this goal. i also see icann as a pawn of the usg and have been very unhappy about this for a loooong time. but you knew that already.
what i do not see is how it is relevant in this particular case. no one is asking to change any ccTLD.
the iana publishes data about one of *my* servers. these data have become erroneous by omission. i am merely asking that they be fixed.
We've requested IANA add AAAA records for some of our TLD name servers. Following the same procedure as making any other change to our delegation information we have had no surprises. And the AAAA's were added in a timely manner.
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?
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.
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 ICANN Email Archives: [root-glue-comments] for the responses). Unfortunately, things sort of got stuck. Hopefully, Randy's request will unstick things.
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.
btw, rip.psg.com serves a few non cctld zones, like throw a few zeros between the 23 and the decimal point. is there policy that we need to seek the approval of the admin and tech pocs of all those zones too?
poor horse. but we should also feel sorry for the virgin chickens.
In a message written on Fri, Jan 18, 2008 at 05:21:18PM -0800, David Conrad wrote:
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 ICANN Email Archives: [root-glue-comments]
for the responses). Unfortunately, things sort of got stuck.
Hopefully, Randy's request will unstick things.
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".
I'm all for giving people a reasonable way to object, and/or "protect"
the things they run. I think though giving them an opportunity to
stop any process completely in its tracks is, well, stupid.
I'd get involved in making the process less stupid, but frankly IANA
politics make my head hurt.
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.
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".
This is along the lines of what we're going to propose. It will be interesting to see what happens.
I'm all for giving people a reasonable way to object, and/or "protect"
the things they run. I think though giving them an opportunity to
stop any process completely in its tracks is, well, stupid.
I've heard this opinion stated (usually by technical folks) quite frequently. Trust me when I say I don't disagree. It is interesting (in the 'Ebola virus' form of interesting) to see what happens when international politics and apolitical technology intersect...
I'd get involved in making the process less stupid, but frankly IANA
politics make my head hurt.
> 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.
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).
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 ;).
> 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.
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.
So instead of using rip.psg.com for the 23 ccTLD, create
ripe-XX.psg.com, where XX is the code for the ccTLD. That way, a
change will require ACK by only one ccTLD manager.
It should be enough but, if you have enough IP addresses, it may be
safer to have different IP addresses as well, in the case of a bug in
Verisign zone generator, bug which would prevent several name servers
to have the same IP address (that's what the RIPE-NCC did).
