Subject: [dnsext] DNAME YXDOMAIN validation

From: "George Barwood" <[email-masked]>
Date: Mon, 16 May 2011 07:14:59 +0100

What are the requirements on resolvers for validating DNAME YXDOMAIN responses?

http://tools.ietf.org/html/draft-ietf-dnsext-rfc2672bis-dname-22#section-5.3.1

says

  The domain name can get too long during substitution.  For example,
   suppose the target name of the DNAME RR is 250 octets in length
   (multiple labels), if an incoming QNAME that has a first label over 5
   octets in length, the result would be a name over 255 octets.  If
   this occurs the server returns an RCODE of YXDOMAIN [RFC2136].  The
   DNAME record and its signature (if the zone is signed) are included
   in the answer as proof for the YXDOMAIN (value 6) RCODE.

which implies that YXDOMAIN responses can be validated.

However, I'm wondering if this is actually useful, and simply clearing the AD
bit would be acceptable. i.e. "validators MAY validate YXDOMAIN responses" but no stronger.
Or maybe I'm wrong, and YXDOMAIN responses MUST be validated if possible, in which case I think
this would be best stated explicitly.

As an aside,  I may be mistaken, but it seems that both BIND and UNBOUND don't
currently handle YXDOMAIN responses, returning SERVERFAIL instead of YXDOMAIN. 
I think this is quite likely to be the behavior for legacy resolvers as well, maybe that could be noted.

George

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 16 May 2011 10:51:04 +0200

Hi George,

> What are the requirements on resolvers for validating DNAME YXDOMAIN responses?

There are no requirements.  Because there is no text in RFC2672 or -bis.

> which implies that YXDOMAIN responses can be validated.

Yes.

> this would be best stated explicitly.

I thought it would be good to include the DNAME (I believe the authority
servers already include the DNAME for YXDOMAIN responses, so the
signature (when appropriate, DO flag, signed zone) is not a lot of
work), just because you can.

> I think this is quite likely to be the behavior for legacy resolvers as well, maybe that could be noted.

Yes, there does not seem to be a great deal of utility for validating
the YXDOMAIN.  It is nice that there is some sort of proof for the RCODE
(since for many other RCODEs no proof is possible, and considering the
length of effort we took to prove NXDOMAINs).

Best regards,
   Wouter

---

From: "George Barwood" <[email-masked]>
Date: Mon, 16 May 2011 19:15:21 +0100

----- Original Message ----- 
From: "W.C.A. Wijngaards" <[email-masked]>
To: <[email-masked]>
Sent: Monday, May 16, 2011 9:51 AM
Subject: Re: [dnsext] DNAME YXDOMAIN validation

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi George,
> 

Ok, given the general imprecations to validate as per http://tools.ietf.org/html/rfc4035#section-4.2
I think a statement that YXDOMAIN responses need not be validated would be useful.

> length of effort we took to prove NXDOMAINs).

Ok, but I don't think that either BIND or UNBOUND handling of YXDOMAIN is correct (IMO).
I'll admit as bugs go, this is extremely minor, and very unlikely to cause any kind of operational problem, 
so this may seem very pedantic, but..

With both UNBOUND and BIND, the behavior depends on whether the DNAME is cached.

UNBOUND:
If the DNAME is cached, UNBOUND correctly returns just the DNAME with Rcode=YXDOMAIN (great!). AD is not set (ok).
If the DNAME is not cached, UNBOUND seems to regard the YXDOMAIN response as Lame, since it repeats the query 6 times before giving up and returning SERVERFAIL.

BIND:
If the DNAME is cached, it correctly returns the DNAME (only), but with Rcode=Ok rather than YXDOMAIN. AD is set.
If the DNAME is not cached, it doesn't repeat the query, but returns SERVERFAIL.

The test domain I'm using is

a123456789.longd.test2.itec-usa.com

Kind regards,
George