Subject: [dnsext] draft-eastlake-dnsext-xnamercode-02 was Re: CNAME and NXDOMAIN

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Aug 2010 12:10:00 -0400

(http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02)

Okay, so I am not letting the go easily.

In RFC 1035, section 4.1.1, the definition of the RCODE=Name Error is 
given as this:

                 3               Name Error - Meaningful only for
                                 responses from an authoritative name
                                 server, this code signifies that the
                                 domain name referenced in the query does
                                 not exist.

"Referenced in the query" is the phrase that piques my interest here.

In RFC 2308, section 2.1,

2.1 - Name Error

    Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
    in the RCODE field.  In this case the domain referred to by the QNAME
    does not exist.  Note: the answer section may have SIG and CNAME RRs
    and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.

followed by its TYPE 1 example.

 From comparing these two, I'd say that 2308 is mistaken in the 
example.  In 1035, an NXDOMAIN referring to the name in the query to 
me reads as there would no RR sets matching (no CNAME and nothing to 
sign).

I ran across this again in looking carefully at the AA bit - which is 
defined to apply to the queried name only.

The only appearance of AA in 2308 is in section 10 (titled "Example") 
and that example is at best under-specified.  This is a query against 
a cache, not the authority.  Today, caches don't work this way. 
Also, looking at the definition in 1035, I wonder if a cache should 
ever return a Name Error.

(Obviously, the goal isn't to declare all known recursive servers 
wrong, the alternative is to document the deviation from the full 
standard...and at some point elevate the deviation to full standard 
too.)

At 9:19 -0400 6/29/10, Josh Littlefield wrote:
>I think the I-D captures the alternatives correctly, and I agree that
>"B" is the best alternative, as well as being consistent with RFC 2308.
>
>-josh
>
>Donald Eastlake wrote:
>>  I also agree that B is the best alternative and should be the
>>  mandatory behavior.
>>
>>  Thanks,
>>  Donald
>>
>>  On Tue, Jun 22, 2010 at 1:30 PM, George Barwood
>>  <[email-masked]> wrote:
>>  
>>>  It's my view that alternative 3.B is correct.
>>>
>>>     When an xNAME chain is followed, all but the last query cycle
>>>     necessarily had no error. The RCODE in the ultimate DNS response MUST
>>>     BE set based on the final query cycle leading to that response. If
>>>     the xNAME chain was terminated by an error, it will be that error
>>>     code. If the xNAME chain terminated without error, it will be zero.
>>>
>>>  If the final query cycle gives rise to a NXDOMAIN, then there must be a
>>>  NXDOMAIN
>>>  NSEC proof in the response, and a validating resolver will check that this
>>>  proof is correct.
>>>
>>>  It would be bizarre I think for the RCODE not to match the NSEC proof that
>>>  is present.
>>>
>>>  George
>>>
>>>  ----- Original Message -----
>>>  From: Donald Eastlake
>>>  To: [email-masked]
>>>  Sent: Tuesday, June 08, 2010 3:27 PM
>>>  Subject: Re: [dnsext] CNAME and NXDOMAIN
>>>  To help facilitate the resolution of this question I have written a draft,
>>>  current version
>>>  http://tools.ietf.org/html/draft-eastlake-dnsext-xnamercode-02
>>>
>>>
>>>    
>>
>>  
>
>--
>Josh Littlefield                                  Cisco Systems, Inc.
>[email-masked]                             1414 Massachusetts Avenue
>Phone: +1 978-936-0001                     Boxborough, MA  01719-2205

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 25 Aug 2010 11:55:06 +1000

In message <a06240800c89996ea6d2c@[192.168.129.32]>, Edward Lewis writes:
> --============_-929455990==_ma============
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> 

The point of RFC 2308 was to allow caches to return name error by
providing a mechanism which allowed it to be cached for a prescribed
amount of time.  The intent was to also make it clear that it applied
to the QNAME at the end of a CNAME chain.

You couldn't have a pure cache with RFC 1035.  You needed a cache/proxy
hybrid.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 25 Aug 2010 08:17:55 -0400

>to the QNAME at the end of a CNAME chain.

That should be documented in the Draft Standard/Full Standard revision.

(Or we have to deal with the same issues that came up with the 
alleged "clarify" documents - that they weren't just clarifications, 
they altered the base in some way.)

>You couldn't have a pure cache with RFC 1035.  You needed a cache/proxy

I'm curious about that statement.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Aug 2010 10:44:34 +1000

> they altered the base in some way.)

RFC 2308's intent was to change things.  It was never a clarifying
document.  Now I may not have done a good job of replace old text with
new text.

> I'm curious about that statement.

Early caches basically checked to see if the answer was in the cache
then if it wasn't made the upstream queries and basically passed the
answer back to the client just correcting the qid.  CNAMEs modified
it a little bit as you would copy the records to the end of the
partially constructed response.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 26 Aug 2010 10:42:52 +0000

> partially constructed response.

Are you saying that early implementations did not try to complete the
CNAME chain?  I'm sure that this step was not required very often
because you didn't throw away untrusted data back then.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Edward Lewis <[email-masked]>
Date: Thu, 26 Aug 2010 10:02:30 -0400

>document.  Now I may not have done a good job of replace old text with

Just to be clear about all this.

There's no issue with changing things in general.  It is just that 
having not otherwise read any text stating that change was the 
intent, I assumed that 2308 (and other docuements) was just filling 
in missing parts of the original specification.

I'm picking on 2308 because it has related to some issues, on the 
list and internal to our development team, recently.  Otherwise 2308 
is not special, no better and certainly no worse (worthy of 
criticism), in this regard.  I am not saying that 2308 is in any way 
deficient or anyone didn't do a good job.  What I am saying is that 
we should improve the state of the documents by capturing more of the 
things left unsaid.

New programmers are those who benefit.  Sooner or later those of us 
who wrote these documents are going to stop answering emails about 
them (for one reason or another) and the text left behind is all that 
the next generation can rely on.  Don't take any "the text needs to 
be clearer" as a criticism on the effort back in the day but as a 
comment on how we can improve the legacy for the future.

>partially constructed response.

Asking for clarification - I understand this is the way older 
recursive servers with caches worked.  I guess I'm mystified by can't 
"have a pure cache with RFC 1035" and what is called a "cache/proxy 
hybrid."  I know that there are points in STD 13 (1034/1035) that 
show that no one really thought through servers that were both 
authoritative and caches - yes, they are mentioned in places but left 
open issues.  In 4.3.2 of 1034, the algorithm there mentions 
consulting authoritative data and cache lookups, but in other places 
there are conflicts in the concept (I can't think of a specific now).

Do you think 1035 didn't allow for hybirds?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: bert hubert <[email-masked]>
Date: Thu, 26 Aug 2010 11:26:44 +0200

Perhaps relevant in this context, there are now a number of domains sending
out NXDOMAIN CNAMEs, like for example:
$ dig +norecurs my.smsfeedback.ru @ns.majordomo.ru

; <<>> DiG 9.6.1-P2 <<>> +norecurs my.smsfeedback.ru @ns.majordomo.ru
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10885
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;my.smsfeedback.ru.             IN      A

;; ANSWER SECTION:
my.smsfeedback.ru.      3600    IN      CNAME   click.smsbliss.ru.

;; AUTHORITY SECTION:
.                       3600    IN      SOA     ns.majordomo.ru.
support.majordomo.ru. 2004032900 3600 900 3600000 3600

Users demand that this works, and BIND and Unbound support this. But I'm
confused, it says NXDOMAIN, and proceeds to send some data, plus a bogus
authority section.

What do people think?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 27 Aug 2010 10:03:58 +1000

In message <AANLkTi=FuBp=[email-masked]>, bert
> confused, it says NXDOMAIN, and proceeds to send some data, plus a bogus

I think ns.majordomo.ru is mis-configured and is accidentally leaking
answers from internal namespace (the private version of the root zone).

The NXDOMAIN just indicates that the name or the name it is a alias for
does not exist.

Mark