Subject: DNAME [4.3]: DNAME is Always Included in Outgoing Packets.

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

Issue [4.3]:
   Old resolvers or firewalls may drop packets with this unknown RR
   type.

It could only be sent if EDNS DO bit indicates understanding (for example).

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: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Oct 2006 21:26:18 +0100

>    Old resolvers or firewalls may drop packets with this unknown RR

	Subsequently, I wrote:

	IMHO, a conformant resolver must not drop a packet simply on account
	of the presence of one or more unknown RRs.  I'll follow this up in
	a subsequent mail ...

	Here goes.

On 16 Aug 2006, at 18:43, Peter Koch wrote (off list):

> What should a poor old DNAME-agnostic client do when it
> sees this "garbage" in the response?

	I replied:

Process the CNAME, if any, as specified in RFC2672.
If the CNAME isn't available, lose.

It follows that DNAME "pseudo-delegation" can work only if the servers
carrying the zone containing the DNAME records consistently implement
CNAME synthesis, as they SHOULD.  This is a stronger requirement than
is sufficient for compliance with RFC2672.  The "pseudo-delegatee"
needs to be aware of, and take responsibility for, arranging this.

	[ Why this falls to the "pseudo-delegatee", rather than to the
	  "pseudo-parent" is another discussion. ]

	And shortly afterwards, I made further observations:

The authoritative server SHOULD synthesize the CNAME record, unless the
request includes a signal that the resolver supports DNAME. Synthesis
isn't the resolver's job.

The resolver algorithm is specified to give priority to the CNAME record
(step 4.c) over the DNAME record (step 4.d).  The DNAME record is  
therefore
ignored (if and) because the synthesized CNAME record is present, and  
not
because the DNAME record is "not understood".  Crucially, the algorithm
doesn't involve checking for unsupported or invalid content in the
response from the server, but rather step-by-step processing of the
supported and valid content.  Robustness is good.

	Now, this is a particular reading of 2672, and perhaps not
	yet recognized as orthodox, except by myself.  8-)

Indeed, on 18 Aug 2006, at 15:38, Peter Koch wrote:

> When discussing 4.3.2 for Wildcard clarify
> there was clarification to this regard:
>
> RFC 4592, section 3:
>
>    The algorithm in section 4.3.2 is not intended to be pseudo-code;
>    that is, its steps are not intended to be followed in strict order.
>    The "algorithm" is a suggested means of implementing the
>    requirements.  As such, in step 3, parts 'a', 'b', and 'c' do not
>    have to be implemented in that order, provided that the result  
> of the
>    implemented code is compliant with the protocol's specification.
>
> (assuming the same logic should be applied to 4.3.2 and 5.3.3).

	This assumption and its consequences need to be examined.
	Different arguments may apply, as sections 4 and 5 (of RFC1034)
	address different circumstances.

	Enough for now.

Best regards,

Niall O'Reilly
University College Dublin Computing Services

PGP key ID: AE995ED9 (see www.pgp.net)
Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: Niall O'Reilly <[email-masked]>
Date: Thu, 12 Oct 2006 20:41:14 +0100

IMHO, a conformant resolver must not drop a packet simply on account
	of the presence of one or more unknown RRs.  I'll follow this up in
	a subsequent mail, as soon as I find the off-list discussion which
	contains my argument.

	I wonder, en passant, whether anyone has estimated how many such
	"old resolvers" are be "out there", and whether they represent a
	significant proportion of the population.

> It could only be sent if EDNS DO bit indicates understanding (for  

	That would update, and partially supersede, RFC2672.  This might be
	no bad thing but I wonder, is it the intention?  After all, the
	abstract uses the term "clarify", rather than "respecify".

	What I'm reading into this is a suggestion that the response include

	 - synthesized CNAME only (for extreme backward compatibility),
	 - both CNAME and DNAME (for 2672-compliant backward compatibility), or
	 - DNAME only (for no backward compatibility at all)

	according to the estimated competence of the query source.  The
	different flavours of response might correspond respectively to
	no EDNS, EDNS0, EDNS<some to-be-specified later level>.

	Or ?

Best regards,

Niall O'Reilly