This is a discussion on Re: DNAME [4.14]: Small Corner Cases - DNS ; > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Issue [4.14]: > There are also some corner cases to discuss and clarify. These are > small issues, but additional examples can give more guidance to > implementors. [[editors note: ...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Issue [4.14]:
> There are also some corner cases to discuss and clarify. These are
> small issues, but additional examples can give more guidance to
> implementors. [[editors note: The following is to be expanded]]
> 1. Example of why DNSSEC validators MUST understand DNAME.
The synthesised CNAMES are not signed.
> 2. Examples of the DNAME name substitution. whole labels only, name
> can get longer and shorter. The '*' label is handled as a fixed
> string during substitution. apex is not substituted. name can get
> too long.
> 3. Corner case: queries for synthesized CNAME. Not a problem,
> current algorithm already creates the CNAME again from the DNAME
> for such a query and follows the chain of DNAME/CNAMEs. Server
> reminded that it must return no error.
> 4. Corner case: loops with single DNAME record possible. Loop: x
> DNAME y.x. Loop: x DNAME x. Loop: x DNAME "." for queries
> 5. Servers must not allow zones to be loaded below a DNAME. This is
> similar to requesting to not load a zone when a domain name below
> a DNAME contains resource records, as the RFC requests.
UPDATE has adding and removing a delgating NS RRset in seperate
operations restores the zone to original state. DNAME processing
can be handled in the same way. A DNAME ocults all records below
the DNAME in the zone.
This is similar to the way a NS RRset occults all records other
than address records below a NS RRset.
> 6. Caches must not allow data to be cached below a DNAME. CNAMES
> below a DNAME must be re-synthesized from the DNAME, or checked
> against the DNAME if needed.
> This is to help implementors understand the ramifications of DNAMEs.
> Explicit examples of corner cases that could cause trouble.
> Best regards,
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> iD8DBQFFLhr8kDLqNwOhpPgRAizvAKCu1ze1zAY17Gc1amYZwc oZKoZfDwCgsXef
> -----END PGP SIGNATURE-----
> to unsubscribe send a message to firstname.lastname@example.org with
> the word 'unsubscribe' in a single line as the message text body.
ISC Training! October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP. Email email@example.com.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.