Re: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt

[Mark Andrews <[e-mail]>]

> 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: [phone]                 INTERNET: [e-mail]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html