> I think I'll have to re-iterate my earlier point, from June 2004, now,
> because it was probably forgotten:
>
> http://darkwing.uoregon.edu/~llynch/dnsop/msg02940.html
As for the IPv6 addresses question.
IPv6 addresses are generally a single label (ignoring mapped
addresses, e.g. ::ffff:123.123.123.123).
> Have these changes been reviewed and/or adopted by DNSEXT WG?
>
> We've produced a similar document like this one at v6ops, and the IESG
> stomped on it, because they wanted that the concerned WGs fix the
> problem, e.g., by new specifications, not that possible fixes are just
> described in an informational RFC -- check out
> draft-ietf-v6ops-v6onbydefault in the I-D tracker if interested.
>
> That is, if a dnsop document is proposing protocol fixes, those fixes
> must actually get in the dnsext pipeline, and we must actually wait
> for those fixes to be finalized before going forward. (Or, then we
> just remove the recommended protocol fixes.)
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> .
> dnsop resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
2.6.1 Recommendation
The following sentence is not true.
But in any case, the
address record must still be present in this zone, either as
authoritative data or glue.
The classic example is the root zone where the address
records for the root servers are not part of the root zone.
The root zone contains glue for the NET servers and the NET
zone contain glue for ROOT-SERVERS.NET servers.
I would make 'missing "in zone" address records' a fatal load
error. Error messages don't get read unless the server stops
serving the zone. A address record is not "in zone" if there
is a delegation between the top of zone and the owner name of
the address record.
Note: this also catches the cases were people only put in
glue records. In a IPv4 only world one could often get
away with this. In a IPv4/IPv6 world this fails miserably.
2.3 Inability to follow multiple levels of out-of-zone glue
Should also say how to avoid this pactice. The simple rule
is that "a server SHOULD be an official server for the zone
it lives in". Historically this was the case. Something like:
You can avoid triggering this problem by always having a server
offically serve (be listed in the NS RRset) the zone it lives in.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
