Subject: DNSSEC explanation, comments?

From: bert hubert <[email-masked]>
Date: Sat, 1 Oct 2005 14:55:14 +0200

Hi everybody,

After talking to people at the DENIC Technical Meeting this week I've
decided to take another look at DNSSEC(-bis) for possible inclusion in
PowerDNS.

For me the way to understand things is to document them somewhat and to this
end I've written 

                           http://ds9a.nl/dnssec/

  (source: http://ds9a.nl/dnssec/dnssec.xml should you be inclined to send
                                  patches)

I'm fully aware I know little about DNSSEC so there are bound to be
technical mistakes in the document above, and I'm interested in hearing
about them.

If after a while it turns out that the page above has become technically
correct, I can give it some wider dissemination. I think it makes good
prior-reading material for Olaf's HOWTO.

I'd also like to request that we do not turn this into a discussion on my
personal ideas about DNSSEC (which are that I'm not sure if it is useful),
if at all possible.

Thanks!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
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: Samuel Weiler <[email-masked]>
Date: Thu, 13 Oct 2005 16:02:30 -0400 (EDT)

>                            http://ds9a.nl/dnssec/

It's nice to have an outside perspective once and a while.  Thank you
for sharing this.  And thank you for praising the working group's
collective intelligence.  :-)

This is an interesting evaluation.  I found it frustrating to not know
where the doc was going from the beginning, but I did agree with the
final conclusion's "biggest worry".  I don't see packet amplification
as a big problem, though it's good to call out that potential threat,
too.

Some minor corrections and suggestions:

a.z.w.example: the second time is the RRSIG inception time, not the
signing time.  The label count is correct (see the sample zone in
4035).

The DS section has bad (or, at least, very confusing) examples: DS and
DNSKEY are at the zone-cut (DS on parent side, DNSKEY on child side),
not a subdomain of the zone.

It's worth noting that KSK/ZSK separation is OPTIONAL -- a zone may
choose to have a SINGLE key or may choose not to use the SEP (KSK)
flag.  The validation process ignores it -- it's there only as a hint
for key management tools and operators.

Add a version and/or date, so it's easy to tell if the version I
downloaded to read on a plane a week ago is still current.

You might want to point readers to the working examples of .se and
ripe.net, as signed zones running in the wild.

-- Sam

---

From: bert hubert <[email-masked]>
Date: Thu, 13 Oct 2005 23:32:33 +0200

> signing time.  The label count is correct (see the sample zone in

Thanks, will investigate & rectify, same goes for your other suggestions.
Much appreciated. I am happy that most (or all) suggestions so far have not
been for fundamental problems - though they are important.

> ripe.net, as signed zones running in the wild.

I've queried for real .se delegations but short of asking here or bothering
the .se administrators nobody could point me to a real DS record 'in the
wild'. But I'm very interested.

My current feeling is that PowerDNS will start offering basic DNSSEC
serving, but NSEC3 may be too different to fit in our database model.

Thanks!

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 14 Oct 2005 00:04:34 +0200

> wild'. But I'm very interested.

Walking both zones doesn't produce any DS records, so I don't believe
there are any.

Cheers,
Simon

---

From: David Blacka <[email-masked]>
Date: Thu, 13 Oct 2005 18:14:41 -0400

> serving, but NSEC3 may be too different to fit in our database model.

bert, could you elaborate?  Specifically, what about NSEC3 or your  
database model would make NSEC3 difficult?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 07:56:24 +0200

> database model would make NSEC3 difficult?

Thinking out loud here, it appears DNSSEC and specifically NSEC requires us
to add a way to ask the database 'get next canonical record' 'get previous
canonical record'. PowerDNS can operate in modes in which it does not have
access to the entire zone, except through well-defined queries.

For NSEC3, if I understand things correctly, this does not work:

	The ownername for the NSEC3 RR is the base32 encoding of the hashed
	ownername.

Which, if I understand things correctly, would mean that we have to track
some other way which NSEC3 records to send.

But I'm not as smart as Ben, Roy & al so I may not be understanding
correctly :-)

If I have one suggestion for draft-ietf-dnsext-nsec3 it would be spelling
out:

1) an example zone
2) the steps an authoritative nameserver has to take 

Thanks.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 09:47:46 +0100

> some other way which NSEC3 records to send.

I recently realised that base32 encoding plus our rule that NSEC3 
records are ordered by their raw binary values means that they _aren't_ 
in canonical order. I suspect this is a mistake and should be fixed.

> If I have one suggestion for draft-ietf-dnsext-nsec3 it would be spelling

It has several examples!

> 2) the steps an authoritative nameserver has to take 

I thought it did this, too - what is deficient?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 11:26:27 +0100

--On 14 October 2005 07:56 +0200 bert hubert <[email-masked]> 
wrote:

> Thinking out loud here, it appears DNSSEC and specifically NSEC requires
> us to add a way to ask the database 'get next canonical record' 'get
> previous canonical record'. PowerDNS can operate in modes in which it
> does not have access to the entire zone, except through well-defined
> queries.

That's an interesting take on it, and indeed how I read it when I first
looked at it. However, the underlying assumption is that "something else"
generates the zone, complete with all the NSEC (or NSEC3) records. After
all, each record has got to be signed, and the signing key may not be on
your server (you might be a secondary). You then can have limited access to
/that/ (the complete signed copy).

What is interesting about what you are saying is you see PowerDNS as being
the thing that creates the zone, including the NSEC records, and presumably
signs them?

Alex

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 12:30:22 +0200

> It has several examples!

Oops - I'll remind myself not to post before coffee.  Apologies.

> I thought it did this, too - what is deficient?

How do I go from a record to its associated NSEC3 record? Is that the one
'above' in the physical zone layout on disk?

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 12:37:31 +0200

> /that/ (the complete signed copy).

Indeed. But for non-existence I need to query the database for the NSEC
record that covers the non-existent record, and that requires me to ask the
database for the next canonical and previous canonical records.

> the thing that creates the zone, including the NSEC records, and presumably

We're still pondering deeply on how (and *if*) to implement DNSSEC-bis. One
way would be to do online lazy signing. This would obviously only be useful
for small zones.

We're also pondering online-remote signing where a different machine signs
remotely.

But offline signing is also considered.

Thanks.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 11:43:48 +0100

> 'above' in the physical zone layout on disk?

Well, there are up to three associated records, and how you find them is 
explained in the I-D.

Cheers,

Ben.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 11:45:47 +0100

--On 14 October 2005 12:37 +0200 bert hubert <[email-masked]> 
wrote:

> record that covers the non-existent record, and that requires me to ask
> the database for the next canonical and previous canonical records.

Oh I see. Out of interest, why is that hard (either for NSEC or NSEC-3)?
I am presuming it's to do with the data structures you are using at the
moment only being suitable for a single ordering.

Alex

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 13:02:04 +0200

> moment only being suitable for a single ordering.

It is not hard for NSEC.

For NSEC3 however the hashed owner-name can't be predicted so the nameserver
needs to *know* which NSEC3 records belong to which unhashed name, which
means additional complexity.

Which was the root of my original message yesterday: NSEC3 might make things
more complex for us, much more so than DNSSEC-bis.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 12:09:37 +0100

--On 14 October 2005 13:02 +0200 bert hubert <[email-masked]> 
wrote:

> For NSEC3 however the hashed owner-name can't be predicted so the
> nameserver needs to *know* which NSEC3 records belong to which unhashed
> name, which means additional complexity.

I may be being very dumb here.

I am assuming that you store the hashed value of each name in the database,
and that you also maintain an index to the database (indexed by that hash),
of course in addition to the normal name based index. Then when you
get a requirement to prove non-existence, you hash that name, and it
is then trivial to find the name whose hash is immediately before and/or
after it.

This requires that at some stage someone has gone and hashed all the
RRs, and they've created an ordering by hash value to make
an index, but I'm not sure why that's any harder than (say) signing
unless there is an inherent difficulty in maintaining orderings by
two distinct indices.

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 12:31:22 +0100

> means additional complexity.

No, you just need to hash the name before you do the lookup.

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 13:36:21 +0200

> No, you just need to hash the name before you do the lookup.

Ok - I had disregarded that possibility because that means that an entire
zone can have only 1 hash size, salt, iteration count and algorithm
configured.

I'll update http://ds9a.nl/dnssec with remarks made here earlier and with
NSEC3.

Thanks.

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 14 Oct 2005 07:54:53 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of bert hubert
ortant.
> wild'. But I'm very interested.

It isn't really "in the wild", but there is an example signed subzone to our
signed zone:

valid.antd.nist.gov.  is signed (and has a DS RR) in antd.nist.gov.  zone.
Both are served from the same server to see it, do a dig @129.6.100.251 for
valid.antd.nist.gov DS

There isn't much to that zone, it's just used for demos.

Scott

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 12:56:50 +0100

> zone can have only 1 hash size, salt, iteration count and algorithm

Its a requirement! Otherwise you cannot deny the existence of arbitrary 
domains.

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 13:05:33 +0100

> Its a requirement! Otherwise you cannot deny the existence of arbitrary

Well, speaking theoretically rather in respect of the particular
implementation, the requirement is surely that the server has access to a
zone file where there is AT LEAST ONE 4-tuple of {hash-size, salt,
iteration count, and algorithm} which is present for each label. The
presence of others hanging around shouldn't actually prevent denial
of existence of arbitrary names (though might have other effects).

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 13:12:01 +0100

> of existence of arbitrary names (though might have other effects).

Correct, and this is what the I-D says.

---

From: Roy Arends <[email-masked]>
Date: Fri, 14 Oct 2005 14:08:08 +0200 (CEST)

> zone can have only 1 hash size, salt, iteration count and algorithm

Almost,

There must be at least one complete <alg,salt,iter> for the entire zone. 
Complete means that every ownername must have a NSEC3 associated that has 
the same value for the entire zone.

The <alg,salt,iter> defines a hash namespace (hash length is a property of 
the hash function used). Rolling this namespace (i.e. changing any 
parameter) required the whole zone to be rehashed and resigned at once.

To be able to do a slow roll, gradually introducing the new (rolled) 
hashed namespace, while maintaining the current hashed namespace, we're 
thinking of using the apex' NSEC3 to indicate the namespace. Since the 
ownername of that record is hashed as well, there is a circular 
dependency. (When you want to find the current <alg,salt,iter>, hash the 
apex using <alg,salt,iter>.....). So, a way to locate the apex' NSEC3 is 
to keep track of that one NSEC3 record which has the SOA bit set.

All in all, there can be multiple hashed namespaces, but only the complete 
ones must include the apex.

Authoritative servers can use this method to know what <alg,salt,iter> to 
use when it needs to include (and thus find) an NSEC3 in the response. It 
is not possible to indicate the current namespace out of band (via 
configuration or otherwise), since the namespace needs to be signalled to 
secondary servers as well, in-band.

Hope this helps,

Roy

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 13:16:25 +0100

> Correct, and this is what the I-D says.

So it isn't a requirement that an entire zone "can have only 1 hash size,
salt, iteration count and algorithm configured". The requirement is
that it has *at least* one consistent hash size, salt (etc.).

Alex

---

From: Alex Bligh <[email-masked]>
Date: Fri, 14 Oct 2005 13:20:15 +0100

> the same value for the entire zone.
...
> thinking of using the apex' NSEC3 to indicate the namespace.

and hence having a <alg,salt,iter> tuple for the apex will necessarily
imply that that <alg,salt,iter> is complete (i.e. present everywhere
else too)?

Alex

---

From: Ben Laurie <[email-masked]>
Date: Fri, 14 Oct 2005 13:22:06 +0100

> that it has *at least* one consistent hash size, salt (etc.).

Yes.

---

From: Roy Arends <[email-masked]>
Date: Fri, 14 Oct 2005 14:24:17 +0200 (CEST)

Yes.

Roy

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 14:28:33 +0200

> that it has *at least* one consistent hash size, salt (etc.).

And, practically, that the authoritative nameserver knows about them. One
may wonder how a caching nameserver would know - it probably wouldn't.

But I'm way out of my depth here.

---

From: Roy Arends <[email-masked]>
Date: Fri, 14 Oct 2005 14:44:16 +0200 (CEST)

> may wonder how a caching nameserver would know - it probably wouldn't.

Indeed, the caching nameserver wouldn't have to know.

It would simply take the <alg,salt,iter> parameters from the NSEC3 
included in the response, and hash the qname (or whatever it needs to 
check), and match the result with the NSEC3 interval.

Roy

---

From: bert hubert <[email-masked]>
Date: Fri, 14 Oct 2005 17:02:38 +0200

> Indeed, the caching nameserver wouldn't have to know.

It would have to learn if it were to be able to figure out the proper NSEC3
to send from its cache with a NO ERROR for example. To this end it would
also need to maintain a list of zone cuts just to be sure it has the
parameters of 'x.w.example.com' and not just of 'w.example.com'.

> check), and match the result with the NSEC3 interval.

I love how you use the word 'simply'. NSEC3 is an explosion of complexity,
almost impossible to debug as well. 

Imagine having to brute force your domain list just to figure out where a
possible outdated NSEC3 record came from.

DNSSEC is hard enough as it is.

---

From: David Blacka <[email-masked]>
Date: Fri, 14 Oct 2005 13:19:13 -0400

> parameters of 'x.w.example.com' and not just of 'w.example.com'.

How does the caching nameserver discover which NSEC records to return  
for a cached NAME ERROR response?

One of the things envisioned by DNSSEC is that caches should not be  
searching for which NSEC records go with which response -- it should  
*know*, because it cached that data along with response.

So, I'm having a hard time understanding why a cache would need to  
track zone cuts and the like.  It just sounds like the wrong approach  
to me.

> almost impossible to debug as well.

Er, how so?

> possible outdated NSEC3 record came from.

Um, what?  I just don't understand the scenario here.

---

From: bert hubert <[email-masked]>
Date: Sun, 16 Oct 2005 12:01:20 +0200

> *know*, because it cached that data along with response.

Ah ok. DNSSEC probably means that resolvers too have to enter the 64-bit
era, most big caches hover around the 1G mark already.

> >I love how you use the word 'simply'. NSEC3 is an explosion of
> >complexity, almost impossible to debug as well.
> 
> Er, how so?

If you have an NSEC3 record being returned it is rather hard work
figuring out which record it corresponds to, especially if you don't have
access to the zone - which appears likely given the choice to use NSEC3.

My current thinking is for NSEC we can add a call to retrieve the NSEC
record straddling the one queried for, which will be fast for all our
backends.

For NSEC3 things are trickier as we need to first figure out a record in
front of the one queried for, and then one after. Then we need to hash both,
and see if there is an NSEC3 record that matches that.

I haven't thought about wildcards yet..

---

From: David Blacka <[email-masked]>
Date: Sun, 16 Oct 2005 09:59:31 -0400

> era, most big caches hover around the 1G mark already.

I don't follow.  While it is clear that DNSSEC (w/ or w/o NSEC3) will  
increase the amount of data that is cached, it is unclear that it  
would, by itself, grow the cache by a factor of more than 4 (to reach  
the 32-bit ceiling of 4GB). Nor is it clear that they would need to  
grow at all -- they could just cache fewer things.

> access to the zone - which appears likely given the choice to use  

Ok, I agree that given an NSEC3 record it is difficult to find out  
what rrset generated it (which is the point of NSEC3, after all).   
But why would you want to?

> and see if there is an NSEC3 record that matches that.

Ok, if you can find the NSEC that "straddles" your qname efficiently,  
how is finding an NSEC3 that straddles the hash of your qname not  
efficient?

Note that the order of the NSEC3 records is unrelated to the order of  
the  records that they were generated from.  So it is not important  
that you find the name that precedes or follows qname.

> I haven't thought about wildcards yet..

You *will* need to know the closest encloser of the qname.  But  
presumably you find that now when looking for wildcards.  In that  
case you just hash the name of the closest encloser an return the  
NSEC3 that directly matches that, along with the NSEC3 that covers  
*.closest_encloser.  (This is for the rcode=3 case).

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research

---

From: Ben Laurie <[email-masked]>
Date: Sun, 16 Oct 2005 17:06:39 +0100

> and see if there is an NSEC3 record that matches that.

No you don't. You hash the name queried for and find the record that
straddles the hash.

However, caches aren't supposed to invent negative responses anyway.

Cheers,

Ben.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Oct 2005 16:58:56 +0000

# ... DNSSEC probably means that resolvers too have to enter the 64-bit era,

Um... why?

# most big caches hover around the 1G mark already.

Um... not in my experience.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Oct 2005 17:17:28 +0000

# > For NSEC3 things are trickier as we need to first figure out a record in
# > front of the one queried for, and then one after. Then we need to hash
# > both, and see if there is an NSEC3 record that matches that.
# 
# No you don't. You hash the name queried for and find the record that
# straddles the hash.

that's hard if you're an authority server in the eyes of the protocol but
you're only a protocol front-end in the eyes of the data.  powerdns, and
bind9+dlz, and bind9+sdb+sql, and presumably other implementations that
can currently function as protocol front-ends without having access to the
full zone, are going to have a hard time adapting to NSEC3.  hubert was
pointing out that it'll take an API change so that each backend can find
the fast way to do what NSEC3 requires, and i agree.

# However, caches aren't supposed to invent negative responses anyway.

the message you were responding to talked first about caches and then about
authority servers that don't have a priori access to zone content.  i was
about to reply the same way you did until i realized that hubert's comments
about the difficulty of "zone window" protocol front ends in the face of
NSEC3 really is higher than the difficulty with just NSEC or no DNSSEC.

the dnssec protocol, like axfr, thinks in terms of "zone identity".  if you
have a windowing front end that only knows the parts of the zone that it has
been queried for, or perhaps even less if it has no "hotspot cache", then
the identity of the zone isn't known or knowable, and interpretting the rules
of axfr or dnssec or anything else that assumes that zones have identity, is
a variously hard problem.

---

From: bert hubert <[email-masked]>
Date: Sun, 16 Oct 2005 19:26:40 +0200

> No you don't. You hash the name queried for and find the record that

Ahhh - so an NSEC3 says 'there is no record between these two hashes', and
not 'there is no record between the origin of these hashes'? Otherwise your
quote above implies:

	A < B     =>  hash(A) < hash(B)

Which is not true generally.

> However, caches aren't supposed to invent negative responses anyway.

I didn't mean to say that, apologies if it appeared that way. PowerDNS has
both a recursive and an authoritative part.

Thanks.

---

From: bert hubert <[email-masked]>
Date: Sun, 16 Oct 2005 19:38:49 +0200

> # ... DNSSEC probably means that resolvers too have to enter the 64-bit era,

A cached NXDOMAIN is going to be a lot larger as it needs to store an nsec
and an rrssig. An open question is how many nsec's and rrsig's are going to
be shared among non-existence answers. I note a lot of queries resulting in
NXDOMAINS to recursors.

> Um... not in my experience.

Some of them are lots bigger, indeed, but I know of none in production >4G.
But I bet you know lots more installations than I do :-)

It might well be possible to retain current service levels with less memory
though.

Thanks btw to people here for helping me understand DNSSEC and NSEC3, much
appreciated!

---

From: Ben Laurie <[email-masked]>
Date: Sun, 16 Oct 2005 18:44:34 +0100

bert hubert wrote:
> Ahhh - so an NSEC3 says 'there is no record between these two hashes',

There's no record whose hash falls between these two hashes.

> and

Indeed.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Oct 2005 17:48:00 +0000

# > Um... why?
# 
# A cached NXDOMAIN is going to be a lot larger as it needs to store an nsec
# and an rrssig. An open question is how many nsec's and rrsig's are going to
# be shared among non-existence answers. I note a lot of queries resulting in
# NXDOMAINS to recursors.

for whitelies zones, it's a lot of metadata.  for actual signed zones, it's
not very much at all.  and in any case, if the limit is cache size rather than
aggregate ttl, then you'd just end up caching less, and i don't think that
will generally hurt reuse very much.  64-bits isn't the emergency you said.

---

From: Brett Carr <[email-masked]>
Date: Tue, 18 Oct 2005 22:27:25 +0200 (CEST)

> wild'. But I'm very interested.

We should have some DS records in the in-addr.arpa tree in the next few
weeks, If you still want to see some then feel free to e-mail me back
again the middle of next month and I'll point you in the right direction.

Brett

--
Brett Carr                              Ripe Network Coordination Centre
System Engineer -- Operations Group     Singel 258 Amsterdam NL
http://www.ripe.net                     +31 627 546046
GPG Key fingerprint = F20D B2A7 C91D E370 44CF  F244 B6A1 EF48 E743 F7D8