Subject: Re: [dnsext] [DNSOP] RFC2308/6604 violation in NSD and BIND?

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 26 Oct 2012 09:53:49 -0400

<dnsext-chair-hat=on>
Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted 
are under DNSEXT change control.
Please move the discussion there.

<dnsext-chair-hat=off>

On 26/10/2012 09:25, Peter van Dijk wrote:
> Hello Mark,
>
> Thank you for your swift and accurate response.
>
> On Oct 26, 2012, at 15:12 , Mark Andrews wrote:
>
>>
>> You asked a ANY query.  ANY and CNAME have different processing rules.
>> The query is NOT restarted with the target of the CNAME.  See RFC 1034.
>>
>>> NSD returns the same minus the ra flag.
>>>
>>> PowerDNS, however, returns:
>>
>> You asked a different question (A != ANY).  If you want to compare
>> answers you need to ask IDENTICAL questions.
>
> My mistake.
>
> NSD:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34556
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; QUESTION SECTION:
> ;nxd.example.com.		IN	A
>
> ;; ANSWER SECTION:
> nxd.example.com.	120	IN	CNAME	nxdomain.example.com.

This is perfectly OK as NSD in this case is not performing the
optional server side CNAME processing.
The cname exists thus this is a valid answer and valid RCODE.
A recursive resolver now has to ask for nxdomain.example.com and will 
get the no name error.

>
> BIND, PowerDNS (same except for ra flag)
>
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 4382
> ;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> ;; QUESTION SECTION:
> ;nxd.example.com.		IN	A
>
> ;; ANSWER SECTION:
> nxd.example.com.	120	IN	CNAME	nxdomain.example.com.
>
> ;; AUTHORITY SECTION:
> example.com.		86400	IN	SOA	ns1.example.com. ahu.example.com. 2000081501 28800 7200 604800 86400
>

This is fine as well but harder to understand :-) as the RCODE refers to 
the target of the CNAME not the qname.

>
> To be complete:
>
> - for the A query, BIND and PowerDNS return NXDOMAIN+SOA, NSD returns NOERROR.
> - for the ANY query, NSD and BIND return NOERROR, PowerDNS returns
>    NXDOMAIN+SOA.
>
> Then, as far as I can tell, BIND and PowerDNS do the right thing for the A
> query. NSD and BIND do the right thing for the ANY query, going from Mark's
> interpretation of the RFCs.
>
> However, 2308 and 6604 totally ignore the ANY exception to following CNAME
> chains, and one might argue that thus, 2308 and 6604 still mean that QNAME is
> the end of the CNAME chain in the response, and the RCODE thus should be
> NXDOMAIN. I think this argument could go either way.
> s
> Unless conflicting opinions come in, I will fix PowerDNS to do the right thing
> for ANY, and will report the A query issue to the NSD developers.
>

In the case of ANY IMHO no CNAME processing should take place.
And I encourage you to file errata against the RFC's that we can discuss 
on the dnsext mailing list, before it is approved.

> Kind regards,

Good observations.
	thanks
	Olafur

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 26 Oct 2012 16:10:08 +0200

Hello Paul,

moved this reply to dnsext too, as requested by Olafur.

On Oct 26, 2012, at 16:01 , Paul Wouters wrote:

>> nxdomain.example.com does not exist.
>> 
>>> How would offline signers deal with this? Pregenerate nsec records
>>> for data that _is_ in the zone?
>> 
>> Offline signers would already have generated the NSEC(3) that denies existence
>> of nxdomain.example.com, simply by virtue of the name not existing in the
>> zone.
> 
> But wouldn't the chain be built based on LHS? Let's check opendnssec:
> 
> [root@nohats signed]# ldns-nsec3-hash cname.nohats.ca. -t 5
> javgjvs1ictdbmts0fcjome4s37kndg0.
> [root@nohats signed]# grep javg nohats.ca javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca.	3600	IN	NSEC3 1 0 5 -  jn89c3qpvavcumn3cv172r7gbu8h6ffs CNAME RRSIG javgjvs1ictdbmts0fcjome4s37kndg0.nohats.ca.	3600	IN	RRSIG NSEC3 8 3 3600 20121109223118 20121026121347 52368 nohats.ca.  zjkB06zMPYIAdtGnWoA3wRqe2Fg5y4Y7R21qaQovhqXtijwMQJfukhKA4OWO4oj5DVL/v0WTZRJII64XuAUzVs9RZMAcCuDceR0BdAT5CgjbkvEwgq08/PI06hXvScTjPzFSRPPfRJ3ViAinFDPd2JZHgMkTO9Wen0KkVPH/vhc=
> ioukpqjt07l1b83ppfd1grdcc57864ja.nohats.ca.	3600	IN	NSEC3 1 0 5 -  javgjvs1ictdbmts0fcjome4s37kndg0 A RRSIG
> 
> So cname.nohats.ca is part of the nsec3 chain.
> 
> So in some sense, the record "exists". I guess validators would have to
> be very careful handling the NXDOMAIN, they might decide it is spoofed
> because they have an existing NSEC/NSEC3 entry for it.
> 
> Odd corner case.

There is no corner case. The NXDOMAIN is about the last name in the CNAME
chain (RFC2308 1) or the last lookup done in optionally following the chain
(RFC6604 3), not about the original QNAME.

In your zone you have:

cname.nohats.ca.	5	IN	CNAME	doesnotexist.nohats.ca.

cname.nohats.ca exists and is an entry in your NSEC3 chain.

doesnotexist.nohats.ca does not exist and is denied by your NSEC3 chain:

  doesnotexist.nohats.ca (5jng314a18r89qab1ilhe54l393kfu8a) denied by 4nbrqak4o1esr5qpg452fucnh8k23d15..6hlm0p5e9c1f3haq64ci0puo97lmtp8g

As for validators, they are not supposed to look at the RCODE anyway. The
actual error status ('no such record type' or 'no such name') can always be
derived from the NSEC(3) records provided.

Kind regards,
-- 
Peter van Dijk
Netherlabs Computer Consulting BV - http://www.netherlabs.nl/

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 26 Oct 2012 16:22:35 +0200

Hello Olafur,

On Oct 26, 2012, at 15:53 , Olafur Gudmundsson wrote:

> Strictly speaking this is dnsext fodder not dnsop as the RFC's quoted are under DNSEXT change control.

Thanks for the pointer. I was not sure where to post but I figured I would
reach most of the right audience on either list.

> A recursive resolver now has to ask for nxdomain.example.com and will get the no name error.

I could not find a reference about CNAME processing being optional, but I'll
gladly take your word for it.

I was going to protest, however, because even if CNAME processing is optional,
2308 states that RCODE regards the end of the CNAME chain. However, 6604 3
restricts this to "final query" instead of "end of chain" and as such, NOERROR
is a correct response if the CNAME simply has not been followed. Under the
resolver recommendations in the last sentence of 2308 2.2.1, the difference
becomes uninteresting in any case.

Now, I know that NSD will in fact follow the CNAME if the target already
exists, so I doubt this NOERROR is intentional, but I agree it is within the
letter of the relevant RFCs.

> This is fine as well but harder to understand :-) as the RCODE refers to the target of the CNAME not the name.

Yes, I find time and again that 2308 and 6604 confuse people, especially as
the redefinition of QNAME in 2308 1 is easy to miss.

> And I encourage you to file errata against the RFC's that we can discuss on the dnsext mailing list, before it is approved.

Yes, I agree that this rule from 1034 makes sense. I will file against 6604,
would that be right? I am not very familiar with standards work.

Kind regards,

---

From: Paul Wouters <[email-masked]>
Date: Fri, 26 Oct 2012 11:18:22 -0400 (EDT)

On Fri, 26 Oct 2012, Peter van Dijk wrote:

> As for validators, they are not supposed to look at the RCODE anyway.

I was not so much thinking of the orignal query. I was thinking of the
case where the NSEC3 has made it into the cache, and some new query causes
the validator to check its cache to see if it has nsec(3) records
proving a QNAME does or does not exist.

The odd thing is that cname.nohats.ca "kinda" exists if you look at the
nsec(3) chain. I guess resolvers implement a negative cache on the QNAME,
so they never used this data to not even ask about a QNAME, and they
still query for the QNAME despite having proof in the cache about it
not existing. In which case, my issue would not come up.

Paul

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 29 Oct 2012 10:33:22 +0100

Hi,

> A recursive resolver now has to ask for nxdomain.example.com and will

NSD does do CNAME processing. I interpret RFC 1034 that a name server
should return NOERROR:

            If the "*" label does not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.

However, RFC 2308 considers 1034 to be unclear and clarifies that the
error refers to the final resolution of the CNAME chain. But it also
mentions that some servers don't do that. So far so good.

In RFC 6604 however, the RCODE clarification after xNAME (and thus
CNAME) is pretty straight forwarded. To my belief, NSD should be
returning NXDOMAIN there.

If people think I have interpret this incorrectly, please let me know.
Otherwise I will be fixing this for upcoming NSD releases.

>> example.com.        86400    IN    SOA    ns1.example.com.
>> ahu.example.com. 2000081501 28800 7200 604800 86400
>>
> 

I think it is easy to understand, as the resolver sees that the NXDOMAIN
cannot apply to QNAME (there is an answer RR for that). Also, the
resolver can now expect an NXDOMAIN denial of exisntence proof, not a
NODATA proof.

Best regards,
  Matthijs

> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext