Subject: [dnsext] dnssec-bis-updates question #1

From: David Blacka <[email-masked]>
Date: Thu, 9 Jul 2009 19:28:34 -0400

In trying to get -09 out, I've come up with a few things that I think  
need clarification.  Here is the first one.

In dnssec-bis-updates-08 (and many earlier versions) section 3.3  
(Check for CNAME) says:

   Section 5 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs.  When validating a NOERROR/
   NODATA response, validators MUST check the CNAME bit in the matching
   NSEC or NSEC3 RR's type bitmap.  If the CNAME bit is set, the
   validator MUST validate the CNAME RR and follow it, as appropriate.

This paragraph, when I read it closely, doesn't make any sense to me.  
The second sentence is talking about validating a NOERROR/NODATA  
response.  But the third sentence says "MUST validate the CNAME RR and  
follow it..." What CNAME RR?  If there was a CNAME present, then the  
response wasn't a NOERROR/NODATA response, right?

I *think* that the general idea here is to make sure that someone  
didn't take a CNAME response and turn it into a NODATA.  This is a  
situation that a validator might miss because it will check the  
original qtype and forget to check for the CNAME bit in the NSEC  
record.  But if it gets such a case, then the only recourse is to  
consider the response bogus.

My suggested replacement text:

   Section 4 of [RFC4035] says little about validating responses based
   on (or that should be based on) CNAMEs.  When validating a NOERROR/
   NODATA response, validators MUST check the CNAME bit in the matching
   NSEC or NSEC3 RR's type bitmap in addition to the bit for the query
   type.  Without this check, an attacker could successfully transform a
   positive CNAME response into a NOERROR/NODATA response.

Is this better?

I am assuming that we don't need to clarify the validation of a  
positive CNAME response even though RFC 4035's section 5 doesn't  
really explicitly address it.

--
David Blacka                          <[email-masked]>
Sr. Engineer          VeriSign Platform Product Development

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Jul 2009 23:59:02 -0400

An example of the topic is this (I think it helps sort out the 
multiple errors in the initial text):

$ dig www.neustar.biz hinfo

; <<>> DiG 9.6.1 <<>> www.neustar.biz hinfo
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42989
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.neustar.biz.		IN	HINFO

;; ANSWER SECTION:
www.neustar.biz.	900	IN	CNAME	neustar.biz.

;; AUTHORITY SECTION:
neustar.biz.		900	IN	SOA	PDNS1.ULTRADNS.NET. 
sec_grp.neustar.com. 1246888833 10800 3600 604800 600

;; Query time: 191 msec
;; SERVER: 68.105.28.12#53(68.105.28.12)
;; WHEN: Thu Jul  9 23:15:59 2009
;; MSG SIZE  rcvd: 120

If this were a signed answer, the ANSWER would have

www.neustar.biz   CNAME    neustar.biz
                   RRSIG    CNAME

AUTHORITY would have this (right?) and maybe a SOA/RRSIG(SOA)

neustar.biz       NSEC(?)  ... not what's asked for ...; or hash(X) for NSEC3
                   RRSIG    NSEC(?)

At 19:28 -0400 7/9/09, David Blacka wrote:
>In trying to get -09 out, I've come up with a few things that I 
>think need clarification.  Here is the first one.
>
>This paragraph, when I read it closely, doesn't make any sense to 
>me. The second sentence is talking about validating a NOERROR/NODATA 
>response.  But the third sentence says "MUST validate the CNAME RR 
>and follow it..." What CNAME RR?  If there was a CNAME present, then 
>the response wasn't a NOERROR/NODATA response, right?
>

(Sect 4 or 5? I think you meant 5)

Section 5 of RFC 4035 says little about validating responses whose answer
section contains one or more CNAME RRSets and no RRSet matching the 
QTYPE.  Such responses ought to have a NSEC(?) RRset owned by the 
name indicated by the last of the CNAME RRSets in the Authority 
section.

In such a response:
     for each CNAME RRSet in the Answer Section the CNAME RRSet signature
     MUST be validated,

     the collection of CNAME RRSets must form a chain, from RDATA of one
     CNAME RRSet to the owner of the next starting with the QNAME as owner,

     and the final name of the CNAME "chain" being the NSEC(?) owner in
     the Authority section.

(Sorry, it's a run-on otherwise.) Failure to check these three 
conditions could result in acceptance of ... an improperly assembled 
answer.

In essence, the validator just has to check the all the usual 
signatures and that there is no matching TYPE in the NSEC(?) inside 
the AUTHORITY.

Am I missing something?

>Is this better?

I think the new wording needs more help, even mine.  It's been a long 
day and it's about midnight here for me.

>really explicitly address it.

Haven't looked at that.  A positive CNAME response is the same as any 
other positive response.  when QTYPE=CNAME, we don't "chase" through 
CNAME RR Sets, we match CNAME like any other type.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.

--
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: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 09 Jul 2009 22:18:33 -0700

Ed and all,

  Also not unsurprisingly neustar.biz has some other DNS
problems as well. See:
http://www.dnsstuff.com/tools/dnsreport?domain=neustar.biz&token=05308c03c7e974de2751ce970e090010

> CNAME RR Sets, we match CNAME like any other type.

Regards,

Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln
"YES WE CAN!"  Barack ( Berry ) Obama

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: "Blacka, David" <[email-masked]>
Date: Fri, 10 Jul 2009 07:46:48 -0400

> (Sect 4 or 5? I think you meant 5)

5.  This is what I get for not cutting and pasting...

> signatures and that there is no matching TYPE in the NSEC(?) inside  

I think you are misreading the original intent of this section of  
dnssec-bis-updates (or maybe I am).  From my reading, the intent was  
to address a common (or presumed to be common) validator error.  I am  
thinking that you think it was about how to validate responses with  
CNAMEs in general, right?

>>
>> Is this better?
>
> I think the new wording needs more help, even mine.  It's been a  
> long day and it's about midnight here for me.
>
> Haven't looked at that.  A positive CNAME response is the same as  
> any other positive response.  when QTYPE=CNAME, we don't "chase"  
> through CNAME RR Sets, we match CNAME like any other type.

No, what I meant by "positive CNAME response" wasn't a response to a  
qtype=CNAME query, but what you actually describe above. That is, a  
response containing one or more CNAMEs that do not terminate in a  
final answer.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 10 Jul 2009 05:31:11 -0700

> http://www.dnsstuff.com/tools/dnsreport?domain=neustar.biz&token=05308c03c7e974de2751ce970e090010

The first warning is bogus:  its complaining that the .biz GTLD is not  
giving glue records for the nameservers, which are:
neustar.biz.            900     IN      NS      PDNS5.ULTRADNS.INFO.
neustar.biz.            900     IN      NS      PDNS6.ULTRADNS.CO.UK.
neustar.biz.            900     IN      NS      PDNS1.ULTRADNS.NET.
neustar.biz.            900     IN      NS      PDNS2.ULTRADNS.NET.
neustar.biz.            900     IN      NS      PDNS3.ULTRADNS.ORG.
neustar.biz.            900     IN      NS      PDNS4.ULTRADNS.ORG.

out of bailywick completely for the .biz gtld, and returning those  
would be pointless because no nameserver should accept it.

The second warning is bogus: it simply goes "Oh, there's no glue, so I  
can't say a thing...", when it actually did do a lookup.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Jul 2009 10:19:33 -0400

At 7:46 -0400 7/10/09, Blacka, David wrote:

>to address a common (or presumed to be common) validator error.  I 
>am thinking that you think it was about how to validate responses 
>with CNAMEs in general, right?
>

Here's the "offending text" (again) as it is in -08:

3.3.  Check for CNAME

The issue is, as seen in the example dig I used last night, is that 
if you are validating a NoError/NoData response there won't be any 
CNAME RRSets present in the reply.  The language in 3.3 is imprecise 
to the point of nothing-but-jargon.

"NoError/NoData" mean that the RCODE field is 0 and the ANCOUNT is 0.

Reading RFC 1034, my fav section 4.3.2 (the algorithm for responding servers):

             If the whole of QNAME is matched, we have found the
             node.

             If the data at the node is a CNAME, and QTYPE doesn't
             match CNAME, copy the CNAME RR into the answer section
             of the response, change QNAME to the canonical name in
             the CNAME RR, and go back to step 1.

So, each time you see a CNAME on the path to resolution, you copy it 
into the answer section (thus ANCOUNT++)

If you run across the need to synthesize from a wild card name match 
(per RFC 4592's update):

       If the data at the source of synthesis is a CNAME, and QTYPE
       doesn't match CNAME, copy the CNAME RR into the answer section of
       the response changing the owner name to the QNAME, change QNAME to
       the canonical name in the CNAME RR, and go back to step 1.

Again ANCOUNT++

Finally, if you get to a name without a CNAME, you apply this rule:

             Otherwise, copy all RRs which match QTYPE into the
             answer section and go to step 6.
and step 6:
    6. Using local data only, attempt to add other RRs which may be
       useful to the additional section of the query.  Exit.

The "copy all RRs (sets) which match QTYPE" might mean copy zero RR sets.

So, there's no difference in the answer section of a response whether 
there is matching data or not.  All differences are in the authority 
section.

What's missing from the discussion is found in RFC 2308 (NCACHE):

    "QNAME" - the name in the query section of an answer, or where this
    resolves to a CNAME, or CNAME chain, the data field of the last
    CNAME.  The last CNAME in this sense is that which contains a value
    which does not resolve to another CNAME.  Implementations should note
    that including CNAME records in responses in order, so that the first
    has the label from the query section, and then each in sequence has
    the label from the data section of the previous (where more than one
    CNAME is needed) allows the sequence to be processed in one pass, and
    considerably eases the task of the receiver.  Other relevant records
    (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.

and (relating to NXDOMAIN, included for completeness):

    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.

and

    NODATA is indicated by an answer with the RCODE set to NOERROR and no
    relevant answers in the answer section.  The authority section will
    contain an SOA record, or there will be no NS records there.

    NODATA responses have to be algorithmically determined from the
    response's contents as there is no RCODE value to indicate NODATA.
    In some cases to determine with certainty that NODATA is the correct
    response it can be necessary to send another query.

    The authority section may contain NXT and SIG RRsets in addition to
    NS and SOA records.  CNAME and SIG records may exist in the answer
    section.

Ok, so in 2308 "NODATA" does not mean ANCOUNT==0, rather that there 
is no relevant response RR Set.  And it defines what goes into the 
authority section (SOA, no NS).

What 3.3 should be conveying is that it is important for the 
validator to validate all relevant records AND check that the process 
as described above is followed.  I.e., check the CNAME RR set 
signatures and that they do form a chain.  This is true whether it is 
a NoError/NoData response, a NoError/withData response, NXDOMAIN 
response, or a CNAME-leading-to-a-referal response/condition.

Same basic idea for DNAME validation and treatment of the 
DNAME-synthezized CNAME (as opposed to a wild card synthesized CNAME).

---

From: David Blacka <[email-masked]>
Date: Fri, 10 Jul 2009 13:17:27 -0400

> Here's the "offending text" (again) as it is in -08:

...

> to the point of nothing-but-jargon.

Right, which is why I brought this up in the first place.

> "NoError/NoData" mean that the RCODE field is 0 and the ANCOUNT is 0.

That is the common understanding, yes.

[elided description of how CNAME processing is defined in 1034]

> So, there's no difference in the answer section of a response  
> whether there is matching data or not.  All differences are in the  
> authority section.

This sentence makes no sense.  If there is "matching data", then there  
is a difference in the answer section, clearly.

> What's missing from the discussion is found in RFC 2308 (NCACHE):

...

>    contain an SOA record, or there will be no NS records there.

...

> authority section (SOA, no NS).

So, CNAMEs aren't "relevant answers"?  Is that what you are saying?  I  
think you are asserting that as long as the CNAME chain in the answer  
section doesn't terminate in the final answer, the response is still  
NOERROR/NODATA.  This is news to me.

> validator to validate all relevant records AND check that the  
> process as described above is followed.  I.e., check the CNAME RR  
> set signatures and that they do form a chain.  This is true whether  
> it is a NoError/NoData response, a NoError/withData response,  
> NXDOMAIN response, or a CNAME-leading-to-a-referal response/condition.

OK, Ed.  My point was that the original intent of section 3.3 wasn't  
to describe this at all.  No one (until now) has been complaining that  
4035 doesn't adequately describe how to actually validate responses  
with CNAMEs in them.  What I think it is trying to describe is this:

Attacker takes this original response:

   RCODE: NOERROR
   ;; QUESTION SECTION
   ;www.example.com. IN AAAA

   ;; ANSWER SECTION:
   www.example.com. IN CNAME example.com.
   www.example.com. IN RRSIG CNAME ...

   ;; AUTHORITY SECTION:
   example.com. IN SOA ...
   example.com. IN RRSIG SOA ..
   www.example.com  IN NSEC x.example.com CNAME RRSIG
   www.example.com  IN RRSIG NSEC ...

And turns it into:

   RCODE: NOERROR
   ;; QUESTION SECTION
   ;www.example.com. IN AAAA

   ;; ANSWER SECTION:

   ;; AUTHORITY SECTION:
   example.com. IN SOA ...
   example.com. IN RRSIG SOA ..
   www.example.com  IN NSEC x.example.com CNAME RRSIG
   www.example.com  IN RRSIG NSEC ...

And the naive validator says: This is a NODATA response.  OK, I see no  
AAAA bit in the type map ... OK, great! Secure!

So, the advice is to "Check for CNAME".  I.e., don't accept this  
response as Secure because the CNAME bit was set, so there should have  
been a CNAME.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 10 Jul 2009 19:45:08 +0200

On 07/10/2009 07:17 PM, David Blacka wrote:
> So, the advice is to "Check for CNAME". I.e., don't accept this response
> as Secure because the CNAME bit was set, so there should have been a CNAME.

+1.
Yes similar to advice for validation of cases described in
the dname-bis draft.  If an NSEC(3) is presented to prove
the non-existence of a type then check the CNAME and DNAME flags
in the NSEC(3) type map.

Best regards,
    Wouter

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Jul 2009 13:45:57 -0400

>>  So, there's no difference in the answer section of a response whether there
>>is matching data or not.  All differences are in the authority section.
>
>This sentence makes no sense.  If there is "matching data", then there is a
>difference in the answer section, clearly.

What I meant was - whether QTYPE == CNAME or QTYPE == something not 
in the zone, the last non-RRSIG in the ANSWER section will be a 
CNAME.  (I assume you mean by a "positive CNAME" result as QTYPE == 
CNAME.)  Comaparing digs for "www.neustar.biz/in/hinfo" and 
"www.neustar.biz/IN/CNAME" are the same in the ANSWER section.  The 
differences are in the AUTHORITY section.

>NOERROR/NODATA.  This is news to me.

Instead of "relevant" I should have said "matching" in the sense of 
QTYPE matching.

It's news - from RFC 2308, see the last paragragh of 2.2 (showing the header
for 2.2.1 to give the position in the section):

2.2 - No Data

...
    These examples, unlike the NXDOMAIN examples above, have no CNAME
    records, however they could, in just the same way that the NXDOMAIN
    examples did, in which case it would be the value of the last CNAME
    (the QNAME) for which NODATA would be concluded.

2.2.1 - Special Handling of No Data

>OK, Ed.  My point was that the original intent of section 3.3 wasn't to
>describe this at all.  No one (until now) has been complaining that 4035
>doesn't adequately describe how to actually validate responses with CNAMEs
>in them.  What I think it is trying to describe is this:

Register my replies to say - 3.3 is confusing.

>   www.example.com  IN RRSIG NSEC ...

Why would there be the NSEC/RRSIG(NSEC) in the authority?  That's a 
side issue, the point is that the attacker could already have it and 
slip it in.  The "malicious" form is indeed possible.

>And the naive validator says: This is a NODATA response.  OK, I see no AAAA
>bit in the type map ... OK, great! Secure!
>

Blanket rule, it's not enough just to validate the signatures, a 
validator MUST also check to see if the response shows that the 
responder properly followed the protocol.  In this case, if the 
response indicates that the QNAME's match owned a CNAME, there's 
better be a CNAME in the answer section.  This all follows that 
blanket rule.

Summing up - the intent of 3.3 is now clear to me, but the words in 
it are imprecise.  E.g. "based on CNAMEs" is all jargon.  As you can 
see, it certainly confused me as to the intent.

>>>>   positive CNAME response into a NOERROR/NODATA response.

but not without this exchange of messages.

PS - is the "legitimate" dig (as I copied here) a properly assembled reply?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "Roy Arends" <[email-masked]>
Date: Sat, 11 Jul 2009 23:12:07 +0100

> response wasn't a NOERROR/NODATA response, right?

Right!

I highlighted this issue at Dallas IETF in 2006, and re-iterated here:

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01623.html

  (3) spoofing cname into nonexistence.

  If response is of type nodata: check NSEC for absence of CNAME type, 
  otherwise a claim for nodata at name X/type Y might be a spoof, since 
the 
  type might exist at the canonical name for X.

> didn't take a CNAME response and turn it into a NODATA.

Correct.

> This is a 

That is better.

> really explicitly address it.

Right.

Kind regards,

Roy Arends
Sr. Researcher
Nominet UK