Re: [dnsext] DNAME YXDOMAIN validation

["George Barwood" <[e-mail]>]

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


> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi George,
> 
> On 05/16/2011 08:14 AM, George Barwood wrote:
>> What are the requirements on resolvers for validating DNAME YXDOMAIN responses?
> 
> There are no requirements.  Because there is no text in RFC2672 or -bis.

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.

>> 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.
> 
> Yes.
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
> 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).

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