Subject: DNSKEY size calculator and implementation question

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Nov 2005 10:20:10 -0800

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.

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/

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Nov 2005 15:48:40 -0800

On Nov 3, 2005, at 14:19 , Mark Andrews wrote:

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

Let me rephrase: To my understanding this is not required by the RFCs?

Is the need you describe above documented somewhere?
If this behavior is so important should it be standardized?

--Olaf

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Nov 2005 11:14:42 +1100

> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --Apple-Mail-2-283181776
> Content-Transfer-Encoding: 7bit
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> 

	Yes.  You really need to make sure the NS RRset is returned
	by the auth servers so DNSSEC aware caches can set AD on
	their replies.

	Mark
 
--
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: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 3 Nov 2005 17:27:37 -0800

> 	by the auth servers so DNSSEC aware caches can set AD on

So let me try to construct the reasoning here.  I do not want to put  
words into your mouth Mark. I want to try and understand the need for  
this data and see if we need clarifying documentation. And if not for  
that then for my own understanding and piece of mind.

So we look at what happens in caching name servers:

1034 sect 4.2.3 Step 4 tells us:
       If there was no delegation from authoritative data, look for  
the best one from the cache,
       and put it in the authority section.  Go to step 6.

4035 sect 3.1.6
     A security-aware name server MUST NOT set the AD bit in a response
    unless the name server considers all RRsets in the Answer and
    Authority sections of the response to be authentic.

Clearly this means that if a caching forwarder does not have a  
forwarding name server RR set in its cache it cannot set the AD bit  
for such a response.

You seem to turn this reasoning into the following requirement; In  
order to be able to set the AD bit a forwarding name server needs to  
have validated NS RR sets in its cache.

In order to fulfill this requirement a signed NS RR set needs to be  
provided to the forwarding name server. Hence authoritative servers  
need to add a signed NS RR set in the authority section.

So far so good?

--Olaf

[1] See http://www.ripe.net/ripe/docs/ripe-352/img4.png

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Nov 2005 12:34:39 +1100

> --Apple-Mail-5-289119466
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
> >

	Yep.
 
> --Apple-Mail-5-289119466
> content-type: application/pgp-signature; x-mac-type=70674453;
> 	name=PGP.sig
> content-description: This is a digitally signed message part
> content-disposition: inline; filename=PGP.sig
> content-transfer-encoding: 7bit
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
> Comment: This message is locally signed.
> 
> iD8DBQFDarkKtN/ca3YJIocRAs0FAJ0b1ICM835CZ4cjxg33PsHd6T4hBgCeN21Z
> qKfjwpk0qZVngZ7ok3xOcwI=
> =zi6v
> -----END PGP SIGNATURE-----
> 
> --Apple-Mail-5-289119466--

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 10 Nov 2005 07:38:15 -0800

[Howard, you are explicitly CC-ed, there is a requirement for  
keyrollover buried in here]

>> need to add a signed NS RR set in the authority section.

One could argue that the above requirement could be fulfilled by  
requiring the resolver to do an authoritative query for the NS RR set  
at one of the servers that it was referred to by the parent. I think  
that is more appropriate but for now, let us not go there.

The reason why this discussion started was that I wanted to know if  
the TC bit needed to be set when an authoritative NS server would  
drop the NS RR set from the authority section.  I think a liberal  
interpretation is allowed and needed in this case.  The need comes  
from a requirement that I want to set for key-rollover mechanisms.

A key-rollover mechanism should not _require_ packets that cause  
truncation and queries to authoritative servers over TCP.
      - One could strike the word authoritative in this requirement,  
caching forwarding servers are not eager for TCP.
      - With EDNS0 it is hard to say what size is 'advertised' by the  
client. (Data point: One sees EDNS0 packets with sizes 1280 (none of  
those with the DO bit), 2048 and 4096 in the wild.)
     - One also wants to avoid UDP fragmentation. I am not sure what  
would be the appropriate size to recommend.

Note that a caching forwarder server will need to set the TC bit, for  
a caching forwarding server the requirement for  inclusion of the NS  
RR set is unambiguous.

--Olaf