Subject: [dnsext] Size of DNSsec NXDOMAIN response

From: William Allen Simpson <[email-masked]>
Date: Mon, 17 Aug 2009 08:28:09 -0400

I'm having trouble counting the number of actual likely bytes in
NXDOMAIN with DNSsec.  It seems to me that the result will never
fit within 512 bytes?  (Assuming SOA, NS, glue, etc.)  I'm currently
getting 1022 bytes with SOA alone, but there's several RRSIGs.

Testing:

   dig www.123.456.powerdnssecc.org @D0.ORG.AFILIAS-NST.org. +dnssec +all

Are there simplifications that I'm missing?

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Aug 2009 10:26:03 +1000

> Are there simplifications that I'm missing?

It all depend apon which DNSKEYS are in use and which NSEC/NSEC3
records that need to be returned.  Yes it can fit in 512 bytes (see
below) though it usually will exceed 512 bytes as in general you
need two NSEC (or 3 NSEC3) records.

Mark

; <<>> DiG 9.3.6-P1 <<>> *.isc.org +dnssec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43355
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;*.isc.org.			IN	A

;; AUTHORITY SECTION:
isc.org.		3572	IN	SOA	ns-int.isc.org. hostmaster.isc.org. 2009081700 7200 3600 24796800 3600
isc.org.		3572	IN	RRSIG	SOA 5 2 43200 20090916175637 20090817175637 48684 isc.org. S2htTDPXDS2r2j/+Kkut0rpi10ENns944xPuv3oJZGtXXHKsdaiavV1Z FbcrXgxhlrvLmOgpnUR/NCu7EfJTE76QWKnQ0rU0/tGd+TnStKR5dLJK AFKmI++ejX5eyGV0cbH4/gq6TsVU8Dky+Xrp38DhTho0CqV8sU5AM37s nrI=
isc.org.		3572	IN	RRSIG	NSEC 5 2 3600 20090916175637 20090817175637 48684 isc.org. LI6RNTUTmsM8PGyIPhOm9Gil3iqiQ2mEgi8DJhiOJ8V9Gafy3XXAUSZs j2uO6VmqQUsg+begGuSgvq8NLf/k0GUnCPgN6cnWEKlnYfdi7/I429Iq uvmGwvMi4L7i6sr+Lpdftp55NADqxAFPsLM9DX7vJ0jvNkrUYW3xWpTc z0U=
isc.org.		3572	IN	NSEC	_kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR RRSIG NSEC DNSKEY TYPE99

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 18 10:19:34 2009
;; MSG SIZE  rcvd: 472

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

---

From: bert hubert <[email-masked]>
Date: Tue, 18 Aug 2009 12:43:56 +0200

> getting 1022 bytes with SOA alone, but there's several RRSIGs.

This is the sad NSEC3 truth, even with 1024 bit keys, SHA-1 DS and
SHA-1 signatures. There are 3 NSEC3's needed mostly, and they all have
an RRSIG. And they are not getting any smaller.

    Bert

---

From: Florian Weimer <[email-masked]>
Date: Tue, 18 Aug 2009 11:35:28 +0000

* William Allen Simpson:

> fit within 512 bytes?

512 bytes seems to be possible to reach with online signing only,
unfortunately.

-- 
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: William Allen Simpson <[email-masked]>
Date: Tue, 18 Aug 2009 08:33:17 -0400

> an RRSIG. And they are not getting any smaller.
OK.  I'm especially concerned for NXDOMAIN, as the last measurements I've
seen say they're likely a minimum of 12% of the queries.

Add key rollover to larger signatures (2 sets of RRSIGs), and we're always
looking at more than 1024 bytes, maybe more than 1400 bytes.  Anybody have
exact data?

---

From: bert hubert <[email-masked]>
Date: Tue, 18 Aug 2009 15:20:01 +0200

> 512 bytes seems to be possible to reach with online signing only,

Or, perhaps, using 32 byte ECC-based signatures.

   Bert

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Aug 2009 00:52:29 +1000

> looking at more than 1024 bytes, maybe more than 1400 bytes.  Anybody have
 
You need to learn how to manage keys so there isn't two sets of
signatures.  The DNSKEY response will have multiple signature but
the rest of the responses don't need them.

Basically you add a new DNSKEY to the DNSKEY RRset before you start
signing with it.  Wait until the on DNSKEY RRset has timed out of
caches.  You then stop signing changes with the old key and start
signing changes with the new key.  Once all the data signed with
the old DNSKEY has timed out of caches you can remove the old DNSKEY.

Mark

---

From: bert hubert <[email-masked]>
Date: Tue, 18 Aug 2009 17:36:51 +0200

> the rest of the responses don't need them.

The DNSKEY DO=1 query still needs to happen though. And it is 'the hugeness'.
It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1.
Could save some bytes.

But in general, without fragmentation working reliably or allowing
('blessing') TCP, there is a problem.

    Bert

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Aug 2009 12:23:09 -0400 (EDT)

> It might be feasible to do two queries, DNSKEY DO=0 and RRSIG DO=1.

That sounds horrible. Where do you put the DNSKEY while doing the RRSIG?
It can't go into the cache yet....

> ('blessing') TCP, there is a problem.

Yeah, people just will have to update their cisco firewall policies :P

Paul

---

From: bert hubert <[email-masked]>
Date: Tue, 18 Aug 2009 18:27:47 +0200

> It can't go into the cache yet....

I suggest the stack.

> Yeah, people just will have to update their cisco firewall policies :P

In general, people will change zilch for DNSSEC (or worse, they can't
change it). It is up to the DNSSEC community to become deployable, and
not to ask the internet to become suitable for DNSSEC deployment.

  Bert

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Aug 2009 08:20:14 +1000

In message <[email-masked]>, bert 
> not to ask the internet to become suitable for DNSSEC deployment.

They will for plain DNS.  Just put 256 byte MTU link, for DNS UDP
packets, between the roots and the rest of the Internet and the
problem will be gone within a week.  It will approximtely double
the DNS UDP packet count.  All IPv4 devices are supposed to be able
to resassemble UDP datagrams used.  That is why the 512 limit was
choosen for DNS in the first place.  So that DNS didn't exceed the
miminmum reassembly buffer size.

Firewalls are about "Can I get way with doing this?".  You just
need to make the answer "No" and the configuration/implementation
will change.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 19 Aug 2009 09:13:12 +1000

In message <[email-masked]>, bert 
> ('blessing') TCP, there is a problem.

Nobody has said no TCP, just that most queries should be resolveable
with just UDP.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Aug 2009 00:59:25 +0000

> From: Mark Andrews <[email-masked]>
> Date: Wed, 19 Aug 2009 08:20:14 +1000
> 
> > In general, people will change zilch for DNSSEC ...
> 
> problem will be gone within a week.  ...

"first, do no harm."
 
> need to make the answer "No" and the configuration/implementation

alas, whoever deploys a sloppy implementation earliest and most widely, has
the high ground on saying "it's not my fault" when someone comes along
later doing the right thing and fails to interoperate.

i am reminded of the microsoft NT 3.51 resource kit which had an early
version of their DNS software that had a correct implementation of AXFR
that BIND4 failed to synch up with due to code bugs on the BIND4 side.  we
fixed it but we couldn't make the fix the default at first, and though we
apologized all over the place, microsoft still took undeserved heat for it.
had ISC failed to fix it and failed to apologize, microsoft would have had
to break their AXFR code to become compatible with BIND4's broken AXFR code.

stupid firewalls who presume datagram atomicity and have gotten away with
it for all the years before EDNS0, can thus get away with claiming that the
new problem (of not handling fragmented UDP/53) is not their bug.

---

From: Olaf Kolkman <[email-masked]>
Date: Wed, 19 Aug 2009 09:31:08 +0200

On 18 aug 2009, at 17:36, bert hubert wrote:

> [reduce size by a query for] RRSIG DO=1

Except that you get all the RRSIGS, for each RR type, that live with  
that owner name.

When querying for the RRSIGs at the owner name of the  DNSKEY that is  
likely to be the RRSIG over the DNSKEY, the NSEC, the SOA, the NS, and  
possibly A and AAAA.

--Olaf

---

From: [email-masked]
Date: Wed, 19 Aug 2009 17:30:26 +0000

> the rest of the responses don't need them.

	surely this is a policy choice, not a protocol choice.

> the old DNSKEY has timed out of caches you can remove the old DNSKEY.

	thats a fine way to manage a scheduled keyrollover.
	not sure that will work for an unscheduled keyroll.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Aug 2009 10:19:51 +1000

> 	surely this is a policy choice, not a protocol choice.

Yep.  The protocol will work fine with multiple signature.  The
messages however will be bigger than ethernet mtu and if you add
enough sets of keys in parallel then you will exceed what can be
carried of EDNS/UDP.  Eventually you will exceed EDNS/TCP as well.

> 	not sure that will work for an unscheduled keyroll.

A "unscheduled" key rollover just saves a DNSKEY TTL period at the
potential expence of more TCP traffic to get the new DNSKEY signatures
out there sooner if you don't want to break validation.

e.g.
* Add new key and sign zone with it and compromised key.
* Start timer for compromised key removal (max ttl of zone).
* Wait DNSKEY ttl.
* Remove RRSIGs from compromised key.
* Wait for compromised key timer to expire.
* Remove compromised key.

Scheduled:
* Add new key to DNSKEY RRset
* Wait DNSKEY ttl.
* Re-sign the zone with the new key.  Remove the signatures from
  the old key from zone data (not DNSKEY RRset).

  This can be done incrementally but one needs to keep a running
  timer (max(timer remaining, ttl of just signed)) of when you can
  remove the old DNSKEY or just wait the max ttl of the zone excluding
  the DNSKEY's ttl.

* Wait the max ttl of the zone, excluding the DNSKEY's ttl.
* Remove the old DNSKEY.

---

From: David Conrad <[email-masked]>
Date: Wed, 19 Aug 2009 15:24:56 -1000

Mark,

On Aug 18, 2009, at 12:20 PM, Mark Andrews wrote:
> problem will be gone within a week.

More likely, the root server operators stupid enough to do this would  
be gone within a week.

The Internet isn't a toy or research tool anymore. Really. Breaking it  
for a non-trivial portion of its users is just not an option.

> Firewalls are about "Can I get way with doing this?".

Err, no. For most folks on the Internet today, firewalls (or more  
generally, CPE devices) are very fragile magical black boxes with  
demons inside that you hire an expensive consultant to chant  
incantations at when they stop working and all else (typically  
unplugging the box and plugging it back in) fails. Expecting the  
owners of those boxes to have even the slightest idea of how to  
configure them to allow larger UDP packets is equivalent to expecting  
a car owner to understand how to adjust fuel injectors.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Aug 2009 11:44:18 +1000

In message <[email-masked]>, David Conrad
> for a non-trivial portion of its users is just not an option.

I didn't think anyone would take that seriously.  Note the root
operator would NOT be breaking the Internet.  It's the firewall
vendors/operators that are breaking things.  Fragmentation has been
part of the Internet since day one.  There is no excuse for any
device, including firewalls, to not handle this.
 
> a car owner to understand how to adjust fuel injectors.

I don't care if it is the operator or the vendor.  It's still "Can
I get way with doing this?"  If they didn't feel they could get
away with this we wouldn't be having this discussion.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 20 Aug 2009 03:59:11 +0000

> Date: Thu, 20 Aug 2009 11:44:18 +1000
> 
> I didn't think anyone would take that seriously.  Note the root operator
> would NOT be breaking the Internet.  It's the firewall vendors/operators
> that are breaking things.  Fragmentation has been part of the Internet
> since day one.  There is no excuse for any device, including firewalls,
> to not handle this.

since mark works for ISC let me be perfectly clear about ISC's position.

1. we would never break something intentionally in this way.
2. the person who makes the triggering change or who knew what the effect
would be is the one at fault, regardless of how screwed up everything was
before that triggering change.  therefore, see #1.