Subject: Re: DNSKEY size calculator and implementation question

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Nov 2005 09:19:07 +1100

> Colleagues,
> 
> One of the questions that one may ask oneself is how much DNSKEYs can  
> I put into a keyset before truncation happens.
> 
> In order to calculate the amount of truncation my co-worker Jelte  
> Jansen whipped up a small script at http://www.nlnetlabs.nl/dnssec/ 
> packetsize.html.
> 
> The script calculates the packet size for a response to  (QNAME="."  
> QTYPE=DNSKEY) query at one of the root servers. Given a distribution  
> of EDNS0 sizes it calculates the fraction replies to "DNSSEC" queries  
> that are truncated. The default distribution is taken from a recent  
> query trace from k.root-servers.net (See RIPE 352).
> 
> I think this comes in handy in the discussions of key-rollover, hence  
> the plug. If you have any suggestions to improve this very trivial  
> tool we'd welcome them off-band.
> 
> Now for the implementation question.
> 
> BIND has been returning an NS RR set in the authority section for  
> positive answers from authoritative servers. To my understanding this  
> is not needed.

	It is actually.  There are configurations where caches can't
	learn the set of servers they should be querying without it.
	They end up only querying the parent servers which may or
	may not be the complete set of servers for the zone.
 
> If one follows the algorithm from  1034 section 4.3.2 for  
> authoritative data  one finds that, when resolving an existing  
> name,type combination one hits 3.a and continues to step 6, which is  
> adding material to the additional section. For authoritative only  
> servers one never hits step 4 which is the step that adds data from  
> the authority section. Step 4 is only 'hit' when you have no  
> authoritative answer available.
> 
> No I do understand that there are reasons to include the NS RRset in  
> the authority section anyway but as far as I know these reasons have  
> never been documented. My first question is: are these reasons  
> documented?
> 
> The assumption we made in the calculator above is that the NS RR set  
> can be removed from the authority section _without_ setting the TC  
> bit because we think that there is no requirement to have that NS set  
> there in the first place (for authoritative servers).
> 
> My second question is: Is this a valid assumption if not what are we  
> missing, where is the behavior specified?
> 
> No hats,
> 
> --Olaf
> 
> -----------------------------------------------------------
> Olaf M. Kolkman
> NLnet Labs
> http://www.nlnetlabs.nl/
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Simon Josefsson <[email-masked]>
Date: Fri, 04 Nov 2005 14:55:02 +0100

> Jansen whipped up a small script at http://www.nlnetlabs.nl/dnssec/

I believe you shouldn't even consider 512 bit keys.  In 1995, the
minimum recommended RSA key size was 768 bits for _end users_ keys.
Things have changed in ten years.  A conservative key size discussion
from 2003 can be found in:

http://www.rsasecurity.com/rsalabs/node.asp?id=2004

Things have changed since 2003 too, but I can't find a good summary
that include key size recommendations.  Perhaps someone else know a
good link?

Depending on your threat model, 1024 bit keys are questionable.  The
1995 recommendation for root keys was 2048 bits.  If this WG can solve
the root key roll-over issue, DNSSEC root keys could have a shorter
life length than typical X.509 root keys. If so, 2048 bit keys may be
sufficient for the root.  However, considering that there is only one
DNSSEC root, it become a much more interesting attack vector.

Thanks,
Simon