Subject: [dnsext] some NSEC confusion on cname wildcards

From: bert hubert <[email-masked]>
Date: Sun, 26 Jul 2009 23:40:24 +0200

Hi everybody,

I now have my prototype live-signing PowerDNS-with-DNSSEC working well
enough that I know of no further protocol related issues with it,
except for one discrepancy where I am not sure that what I am doing is
wrong.

Everyone is cordially invited to compare the results of
powerdnssec.org as served by the PowerDNS experimental code with those
served by more established servers. A version of the zone signed by
dnssec-signzone can be found on http://www.powerdnssec.org.
(non-do queries to this PowerDNS code may still miss some DNSSEC data).

Now for the discrepancy, if we query PowerDNS for
www.belgium.powerdnssec.org AAAA, we find that BIND and PowerDNS agree
on the answer section:
www.belgium.powerdnssec.org. 3600 IN	CNAME	powerdnssec.org.
www.belgium.powerdnssec.org. 3600 IN	RRSIG	CNAME 5 3 3600
20090806000000 20090723000000 44332 powerdnssec.org.
d3y5gxVaE7otS7eZjKtlVwmEq1EpmgqcFQD+V2qyrzxtoAxcZ/g65ucf
A+az7TmxFCs2ZU6Lga1ZnibUK1RmjAXvsqg4uWy9sxxgN66QA7BHEF65
ME62tuldrePIggUDYjswpDbQGcXgr0NN0p/yLVALqUlEcBJe+WCFa7Pq BKM=

(in the zone, there is: *.belgium.powerdnssec.org. 3600 IN CNAME
powerdnssec.org.)

However, PowerDNS then adds;
*.belgium.powerdnssec.org.
3600	IN	NSEC	server.belgium.powerdnssec.org. CNAME RRSIG NSEC
*.belgium.powerdnssec.org. 3600	IN	RRSIG	NSEC 5 3 3600 20090806000000
20090723000000 44332 powerdnssec.org.
j/e4XDJYJOh1oGlawMMpPCDQuW8//+yYrlTCmzld+86NujpJOXRgelsT
Fu6w867UcIMHqICqdP2nefkTFO9g0K/FTCO+qzmlPe8CcQNPrLpil/1h
TpSE7E+b/Ph9e9DJQAUBwJvq1yaN7prPL8S08hrlb3Tg1wNFqZGwhmBw r8Y=

Whereas BIND emits the 'next' NSEC:
server.belgium.powerdnssec.org.	3600 IN	NSEC	france.powerdnssec.org. A
RRSIG NSEC
server.belgium.powerdnssec.org.	3600 IN	RRSIG	NSEC 5 4 3600
20090806000000 20090723000000 44332 powerdnssec.org.
T92UcTDqG8FVwIw+XL2rzdzhhKUEKpaD2uw7WFLx+gcQry/xJ9eL+nRH
OPXRhmsFsu+mpDuwlWcXYQq2PtnjUxXIPEA9eu2IDkJhIg+ePOfmrLNs
plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec=

Bind & PowerDNS then both add the powerdnssec.org SOA and NSEC
records, and signatures.

I've been scanning the various RFCs, but perhaps my eyes are a bit
tired after all this coding, and I can't find elucidation. I'm
assuming BIND is right, but I can't see why yet.

If I'm missing the obvious, my apologies. If I've discovered a bug in
BIND "9.5.0.dfsg.P2-1ubuntu3.1", I again apologise for not having used
the right list to report it.

  Bert

--
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: bert hubert <[email-masked]>
Date: Mon, 27 Jul 2009 00:19:14 +0200

Thanks to a quick off-list tip (thanks!), it turns out the covering
NSEC in such cases should be generated from the original query name,
and not from the wildcard name that matched it.

I expect the rationale of supplying both an RRSIG for the
wildcard-synthesised record, together with a 'covering' NSEC, is that
the first proves the presence of a wildcard, the second one proves
there was no non-wildcard data that would have trumped the wildcard?

Both powerdnssec.org nameservers have been updated with this fix.

I hope in the future only to bother you with real protocol questions,
and not misunderstandings.

    Bert

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Sun, 26 Jul 2009 18:35:25 -0700

Bert and all,

  Your welcome.  I didn't think I helped that much though...  Also
I am sure your correct that the covering NSEC generated by the original
query name is what should happen, not the wildcard.  That could be
manipulated however if you desire to allow signed wildcards...

> > the right list to report it.

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: Mark Andrews <[email-masked]>
Date: Mon, 27 Jul 2009 14:05:41 +1000

> plrVO2RsXOGPbQ2KXs8ZnT1nGVfu1RobL1y+aKLPdtW4WmTHbx1zQoOI Jec=

You have to prove the QNAME does not exist to prove that the wildcard
answer is valid.  This requires finding the NSEC record that covers
QNAME and show that QNAME was not in the zone.  This is to prevent
answers being picked apart, reassembled and replayed to get the
wildcard rather than a record that is there (e.g.
server.belgium.powerdnssec.org).  www.belgium.powerdnssec.org is
between server.belgium.powerdnssec.org and france.powerdnssec.org
when the zone is sorted in DNSSEC order so that is the NSEC that
is returned.

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

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 27 Jul 2009 08:25:59 +0200

> and not misunderstandings.

Well, keep these questions coming, they may indicate that the specs  
are not clear.

In fact, any implementation experience, specifically clarifications  
can be put in:
http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-bis-updates

Maybe you can capture what you learned in that document.

--Olaf

---

From: Edward Lewis <[email-masked]>
Date: Mon, 27 Jul 2009 10:01:02 -0400

>Well, keep these questions coming, they may indicate that the specs

That's would have been my reply.

There are lots of places where "the rationale" didn't seem to make it 
into text.

In this instance - DNSSEC is not meant to only add signatures to what 
is sent, but to also add signed records to prove that the algorithm 
in RFC 1034, 4.3.2 was properly followed.  (I.e., prove when "...at 
some label, a match is impossible" resulting in looking "to see if a 
the [sic] "*" label exists".)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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.