Subject: [dnsext] NSEC3 confusion (in .org)

From: bert hubert <[email-masked]>
Date: Mon, 10 Aug 2009 18:52:44 +0200

Hi everybody,

As indicated previously, I'm implementing DNSSEC in a PowerDNS
prototype, and this is succeeding pretty well, well enough that I've
decided to go for NSEC3 support.
I've previously asked DNSSEC questions on the list, and was invited to
keep this up, as questions from implementation may imply inclarity in
the RFCs, so I gratefully make use of the invitation by asking another
question.

I'm now studying the huge complexity that is NSEC3, and I'm confused
for what RRSETs I should generate NSEC3 records.

When I query .org for a non-existent delegation, I get three NSEC3's
returned. Wouter Wijngaards helped me understand why three are
required (thanks!), but what I don't get is how two of these three
NSEC records appear to start from an A RRSET. As far as I know, there
are no non-glue A records in ORG?

Or does this mean I need to hash non-authoritative data too?

To observe, try:
$ dig www.123.456.powerdnssecc.org +dnssec @D0.ORG.AFILIAS-NST.org. |
grep "IN NSEC3"
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 1 1 1 D399EAAB
H9RSFB7FPF2L8HG35CMPC765TDK23RP6 NS SOA RRSIG DNSKEY NSEC3PARAM
3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 1 1 1 D399EAAB
3GNP00TJJB0VVL9K7OCT4RDEBB9NJ229 A RRSIG
vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 1 1 1 D399EAAB
VAJL90D4DFJFL9N6TVEDLDAI33BGAO6S A RRSIG

I've also asked Afilias what their take on this is, but I assume I
misunderstand how NSEC3 works. RFC 5155, 7.2 however appears to imply
that NSECs should only be generated for authoritative data.

Thoughts?

     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: Edward Lewis <[email-masked]>
Date: Mon, 10 Aug 2009 13:29:13 -0400

Just to make sure, the "error" is in "powerdnssecc.org" and the 
www.123.455 is just a red herring here.

What the NSEC and NSEC3 both are doing is providing proof that the 
algorithm in RFC 1034, 4.3.2 ("the algorithm") is indeed being 
followed and "where a match is not possible" - that a match was 
indeed not possible.

The difference here between NSEC and NSEC3 is that NSEC "exposes" the 
internal structure (as well as all the names, but that's not the 
issue here) of the zone while NSEC3 "flattens" the zone into a single 
list.

Because of wild cards, you need to have three proofs to deny that 
there is a match for a name.  One is the name itself must be 
"absent."  Two, you need proof that the  *claimed* "closest encloser" 
is indeed the closest encloser.  And then three you need proof that 
there was no "*" label below the closest encloser.

I'm no whiz with hashes so I tried this:

;; QUESTION SECTION:
;powerdnssecc.org.		IN	A

h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM
3gltncluplu62jh7veingh4epqqfj6pj.org. 86400 IN NSEC3 ...
vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ...

administrators-computer-4:~ edlewis$ dig powerdnsseccc.org +dnssec

h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM
jmnb7p7ulrsn3c0h2fnun2bo4eos72tt.org. 86400 IN NSEC3 ...
vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ...

I'll wager then that "h9p7u7tr2u91d0v0ljs9l1gidnp90u3h" is the hash 
for the apex (it owns NSEC3PARAM).

And I'll wager that "3gltncluplu62jh7veingh4epqqfj6pj" covers the 
first name (as opposed to the one with yet another c).

So that means "vad5ip2eetmcrkvsv6teloij2vi1cul3" would cover the asterisk.

To try to confirm that, I'll ask for it...

;*.org.				IN	A

;; AUTHORITY SECTION:
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 86400 IN NSEC3 ... NSEC3PARAM
vad5ip2eetmcrkvsv6teloij2vi1cul3.org. 86400 IN NSEC3 ...

This time I get two - because the proof there is no asterisk label 
(exact match) is the same as the proof that there is no "source of 
synthesis" (RFC 4592 speak for the "*" label).

Does that make sense?  NSEC3 #1 says the QNAME isn't here, NSEC3 #2 
identifies the closest encloser (by denying their is a closer name to 
QNAME), and NSEC3 #3 reports that there's no source of synthesis.

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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Aug 2009 14:20:34 -0400

At 19:58 +0200 8/10/09, bert hubert wrote:

>The thing I wonder about is how two of the NSEC3s can claim to have an
>A in its type-set, since .org is 'delegation only'.

This is the tricky part.  I mean "getting over that."

The catch is that the hashes are sorted in the order of the hashes, 
not the order of the zone as DNSSEC has come to define.  (Pre-DNSSEC 
there was no order to a zone except that the apex came first.)

Hmm, oh, yeah, about why there are "A" records in the bitmaps.  Good 
question.  I missed looking into that last message.  I don't see them 
in "gov." NSEC3's. (You still get 3 NSEC3's, but the bit maps are 
"NS" - just haven't hit a DS'd one.)

>Not looking forward to the empty non-terminals bit either.

In the development days, there was a large fear of them.  But then we 
"discovered" the notion of the closest encloser and that erased a lot 
of the pain.

Yes, you have to generate NSEC3's for all nodes, empty or not, and 
that is one nuisance I didn't like.  But once all is set up, then 
processing queries is not hard - because in the case of a NXDOMAIN 
response you still need the same three NSEC3's - the QNAME, proving 
the closest encloser, and the lack of a *-label.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Tue, 11 Aug 2009 10:10:57 +1000

> are no non-glue A records in ORG?

	No. Just your assumption is false.  NS RRsets are removed
	by registrars without the glue records beneath them also
	being removed for spam and other network abuse issues.  This
	causes the glue to become authoritative data.

	The same thing happens in COM, NET and I presume all other
	zones with a registry/registrar model.  The registrars
	really should be pulling the glue records as well.  It's
	up to the registry enforce this however.

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

---

From: Florian Weimer <[email-masked]>
Date: Tue, 11 Aug 2009 07:34:53 +0000

* bert hubert:

> As far as I know, there are no non-glue A records in ORG?

There are:

; <<>> DiG 9.5.1-P3 <<>> @a0.org.afilias-nst.info. dns1.buddycard.org. +norecurse
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51573
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 4

;; QUESTION SECTION:
;dns1.buddycard.org.            IN      A

;; ANSWER SECTION:
dns1.buddycard.org.     86400   IN      A       219.88.243.244

;; AUTHORITY SECTION:
org.                    86400   IN      NS      a0.org.afilias-nst.info.
org.                    86400   IN      NS      a2.org.afilias-nst.info.
org.                    86400   IN      NS      b0.org.afilias-nst.org.
org.                    86400   IN      NS      b2.org.afilias-nst.org.
org.                    86400   IN      NS      c0.org.afilias-nst.info.
org.                    86400   IN      NS      d0.org.afilias-nst.org.

;; ADDITIONAL SECTION:
b0.org.afilias-nst.org. 86400   IN      A       199.19.54.1
d0.org.afilias-nst.org. 86400   IN      A       199.19.57.1
b0.org.afilias-nst.org. 86400   IN      AAAA    2001:500:c::1
d0.org.afilias-nst.org. 86400   IN      AAAA    2001:500:f::1

;; Query time: 123 msec
;; SERVER: 199.19.56.1#53(199.19.56.1)
;; WHEN: Tue Aug 11 09:29:16 2009
;; MSG SIZE  rcvd: 278

This domain is in state "PENDING DELETE RESTORABLE".  The zone file
provisioning is buggy.

The majority of signed resources in .org are such spurious A records:

$ zgrep "RRSIG A"  org-2008770137-zone.gz | wc -l
5949
$ zgrep "RRSIG DS"  org-2008770137-zone.gz | wc -l
20

-- 
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: bert hubert <[email-masked]>
Date: Mon, 10 Aug 2009 19:58:56 +0200

On Mon, Aug 10, 2009 at 7:29 PM, Edward Lewis<[email-masked]> wrote:
> Just to make sure, the "error" is in "powerdnssecc.org" and the www.123.455
> is just a red herring here.

The rest of your analysis looks sound (thanks), even though I continue
to have a very hard time grasping the finer details of NSEC3.

> QNAME), and NSEC3 #3 reports that there's no source of synthesis.

It is all incredibly clever.

    Bert

---

From: Matt Larson <[email-masked]>
Date: Wed, 12 Aug 2009 01:05:46 -0400

> 	up to the registry enforce this however.

That is not correct.  At least in .com and .net, the registry business
logic prevents a domain from being deleted if name servers (i.e., host
objects in the registry database that result in glue A or AAAA RRs in
the zone) under that domain still exist.  E.g., a registrar must first
delete the name server "ns.foo.com" before deleting the domain
"foo.com".

Authoritative A and AAAA records do appear in .com/.net, however, when
a domain goes on a hold status (there are various kinds), which causes
the domain's NS RRs to be removed from the zone.  In this case, any
name servers (A and AAAA RRs) below it are not removed.  Since they
are now no longer below a delegation, they become authoritative data.

Note that this behavior is changing soon for DNSSEC reasons: in the
future, when a domain goes on hold, all A/AAAA RRs below it will be
removed along with the NS RRs for the duration of the hold status.
This change obviates the need to sign what would then become
authoritatve data and, in my opinion, conforms better with the
principle of least astonishment.

I can't speak for .org's business logic, so I don't know under what
circumstances authoritative A/AAAA RRs appear in that zone.

Matt

---

From: Mark Andrews <[email-masked]>
Date: Wed, 12 Aug 2009 15:36:07 +1000

In message <[email-masked]>, Matt Larson writes
> delete the name server "ns.foo.com" before deleting the domain

I wasn't talking about a delegation being deleted.  Note I qualified
the removal based on "spam and other network abuse issues".
 
> a domain goes on a hold status (there are various kinds),

including spam and other network abuse issues

> which causes

We both said the same thing.  The NS RRsets is pulled from the zone
without the glue records being pulled.
 
> principle of least astonishment.

Agreed.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Aug 2009 06:10:06 +0000

> Date: Wed, 12 Aug 2009 01:05:46 -0400
> From: Matt Larson <[email-masked]>
> ...
> removed along with the NS RRs for the duration of the hold status.  This
> change obviates the need to sign what would then become authoritatve data
> and, in my opinion, conforms better with the principle of least
> astonishment.

so if VIX.COM goes on hold then NS-EXT.VIX.COM's A RR will no longer be
queriable at the COM servers even if other zone cuts (either under COM
or elsewhere including TLD zone cuts in the root zone) still reference it?

---

From: Matt Larson <[email-masked]>
Date: Wed, 12 Aug 2009 10:37:38 -0400

> the removal based on "spam and other network abuse issues".

Hold statuses are administrative and are most often used for
non-technical reasons.  Domains go on hold for "spam and other network
abuse issues" rarely, if ever, in .com/.net.  (But note that putting a
domain on hold for that reason would have to be initiated by the
registrar.)

I took issue with your ascribing fault to the registrars and the
registries for the glue remaining in the zone.  This issue is out of
control of the registrars, who would be unable to remove the name
servers of a domain on hold because of another business rule: a name
server can't be removed if it is associated with any domains, i.e.,
has a non-zero reference count.  So it's not realistic to expect that
registrars could ensure no authoritative glue remained of on-hold
domains.

From the registry perspective, it's not a clear-cut issue: there is a
good case to be made either way for promoting name servers (A/AAAA
RRs) of on-hold domains to authoritative data (or not).  I think the
current .com/.net behavior of promotion is reasonable, but I also
think DNSSEC is a good justification for changing the behavior.

The dwindling DNS protocol content in this thread probably puts it out
of scope soon (if not already)...

Matt

---

From: bert hubert <[email-masked]>
Date: Mon, 10 Aug 2009 19:58:56 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

    Bert

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Aug 2009 07:48:22 +1000

In message <[email-masked]>, Matt Larson writes
:
> > In message <[email-masked]>, Matt Larson =
> writes
> > > >=20
> > >=20
> >=20
> =46rom the registry perspective, it's not a clear-cut issue: there is a

	Yep.  It doesn't really matter why, just acknowledging that it
	occurs is enough for this answering the original question.

	Mark