Subject: Re: Q-03: inclusion of KEY records in additional records section

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 23 Apr 2003 22:06:39 -0400

<DS editor hat on>
After reading all the postings on this it is not clear to me what
the working group wants.

As far as I can tell there are 3 options have been put forward,
to replace the RFC2535 rules (that do not make sense anymore).
It is not clear if anyone of the proposals has a significantly more
following than the other two.
Listed below in order of frequency of inclusion of KEY RRset
in additional section:
	1. Always include covering KEY
	2. Include covering KEY on referral only
	3. Never

Please express preference on which rule to pick, and why.

If rule 1 or 2 is selected we need to set rules about inclusion order.
Current RFC2535 rules say address glue has higher priority than KEY, this
is a good rule. The open issue is do we need to specify in what order
multiple KEY RRsets are included?
	Example: QNAME: com. QTYPE: NS
	Answer section:  NS set signed by com.
	Additional section: glue addresses signed by gtld-servers.net.

Should inability to include one or both of the KEY RRsets cause the
TC bit to be set ? (RFC2535 said no)

	Olafur 

--
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: Thu, 24 Apr 2003 10:17:15 -0400

>	3. Never

There are two reasons not to include the KEY RR.

1) We should return to the basic premise of the DNS protocol - given 
a query for  the Q-trinity (QNAME, QCLASS, QTYPE) you should get back 
a specific response for that.  Whenever we are throwing in more than 
that, we engender "special processing" which is a disease in the DNS 
protocol.

Because of this, let the verifier decide if it needs to ask the 
resolver to get the KEY set.  This moves the smarts outward to the 
edge of the network.  Don't make the server make the determination - 
let the server get dumber.

This is an architectural reason.

2) Including the KEY RR in every message requires the message be 
expanded by that many bytes.  Worse yet, if the KEY RR's failure to 
fit causes a TC bit and TCP retry, we also see more packets and 
latency (round trips).

A side issue of larger and more data transfer is the impact on 
ill-adjusted intrusion detection systems, etc., that overreact (seen 
it).

Since it is not clear that the KEY RR is needed in each answer, 
operationally, this is a poor choice.  However, if we observe a lot 
of queries for the KEY RR, it might be an overall savings to just 
throw them in there.

---

Architecturally, it's a bad idea to include the KEY RR set. 
Operationally, there's a slim chance it would be a helpful 
optimization.

Based on this, I would urge that for now we say "never" (or almost 
never) and look to see if there are excessive KEY RR lookups that 
result from this choice.  If so, then we consider recommending that 
KEY RR's are added.

I would require resolvers to work with or without the KEY RR in the 
answer, so they won't need to be updated if the time comes.  (The 
verifier should drive what's needed, if the set is not in cache, it 
should ask for the KEY RR set over the net.)  I would specify that 
serves are either "RECOMMENDED NOT TO" or "SHOULD NOT" include the 
KEY RR's.  I would avoid a "MUST NOT" here as the inclusion of the 
KEY RR (set) is not likely to cause damage to the protocol or the 
network.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

A compiler-directive person living in an HTML-tagged world.