Subject: DNAME Issue 4.3 (open)

From: "Scott Rose" <[email-masked]>
Date: Tue, 6 Feb 2007 20:18:17 -0500

Issue 4.3 DNAME is always included in outgoing packets

This issue is still open

Original email 

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01333.html

follow ups:

http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01367.html
and
http://ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01366.html

A discussion about the algorithms in RFC 1034 and changes 
that may need to be made in this draft to accommodate DNAME

Additional topics

- Firewalls and middle boxes may not understand DNAME or
  the synthesized CNAMEs

- Microsoft Windows resolvers may reject responses 
  with DNAME RRs
  http://support.microsoft.com/kb/920162

So the formal issue of "what should be returned in the response
packet" is still open for discussion.  Please provide feedback, 
with text as appropriate.  

Scott & Wouter
DNAME clarification draft editors

--
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: Wed, 07 Feb 2007 13:32:02 +1100

> - Firewalls and middle boxes may not understand DNAME or

	I could believe old ones not understanding DNAME.  Mind you
	DNAME has been on standards track for 7 1/2 years now.  Any
	middlebox being released today should understand DNAME.  If
	it doesn't it is well and truely *broken*.

	I don't believe that any middlebox will have a problem with
	CNAME's unles they are trying to enforce a ttl of 0 based
	on the presence of DNAME.

	Do we have any evidence of any (current) middle-ware being
	broken?

	Any middle-ware vendor that is looking at the contents of
	packets need to make sure they stay current with the protocol
	they are examining.  I think, that if after, 7 1/2 years
	all vendors of middle-ware that examine DNS packets should
	be aware of DNAME.  If they are not then they are negligent.

	We expect vendors of DNS server / clients to track changes /
	corrections to the DNS protocol.  That one of the reasons
	why we publish RFC's, why we listed the RFC's that update
	a existing RFC. 

	I don't see any point in not publishing DNAME's in the
	answer section.  The barn door has been open for 7 1/2
	year now.  There is no point in trying to shut it now.

>   http://support.microsoft.com/kb/920162

	A nameserver that was released 4 years after DNAME was
	put on standards track for which there is a fix.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]