Subject: DNAME [4.14]: Small Corner Cases

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 12 Oct 2006 12:37:48 +0200

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.
   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
       qname=a.x.x
   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.
   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,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Oct 2006 10:44:40 +1000

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Issue [4.14]:

	The synthesised CNAMES are not signed.
	
>        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.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFFLhr8kDLqNwOhpPgRAizvAKCu1ze1zAY17Gc1amYZwcoZKoZfDwCgsXef
> PVVroEZTYynkNAs36LUgaP8=
> =E85B
> -----END PGP SIGNATURE-----
> 
> --
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]