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: Paul Vixie <[email-masked]>
Date: Thu, 24 Apr 2003 05:44:07 +0000

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

#3.  the time the KEY is needed is the first time a validator sees a SIG
with that keyname.  there is no way for a server to know when that's 
occuring.  including it every time the SIG is exposed (as in #1 above)
would waste resources.  including it only in the case of a referral (#2
above) misses the target since the next key the validator will need is
in the child zone and won't be the one you're including.

> TC bit to be set ? (RFC2535 said no)

no.

---

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.

---

From: David Blacka <[email-masked]>
Date: Thu, 24 Apr 2003 11:27:52 -0400

> in the child zone and won't be the one you're including.

Would choosing option #1 waste resources that are important?  I can see how 
it will make response sizes larger, but so what?  Bandwidth gets cheaper 
over time, and DNS is already a near insignificant portion of overall IP 
traffic.  What other resources does this waste?

Choosing #3 forces more round trips.  Network latency has a fixed upper 
limit.  Of course, more round trips does not ncessarily mean more latency 
on the query as a whole, as clients can do parallel queries.

I'm just trying to make sure that we are optimizing the right thing here.

> > TC bit to be set ? (RFC2535 said no)

If this remains true, then option #1 would effectively be an unenforceable 
recommendation.

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Apr 2003 12:06:08 -0400

>on the query as a whole, as clients can do parallel queries.

I effectively disagreed with this - with the rationale that if we 
start out with the smaller answers we could 1) determine that they 
were sufficent or 2) observer that we need to do option 1.  If we 
start out with the larger answers, we might 1) not realize that 
smaller would be better or 2) not realize we made the right choice.

I also think that switching from #3 to #1 isn't that hard to deploy.

This all assumes that we have no sufficiently large test bed in which 
to try and measure the options.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: David Blacka <[email-masked]>
Date: Thu, 24 Apr 2003 12:46:20 -0400

> smaller would be better or 2) not realize we made the right choice.

Ok, I think I get it.  You are saying that we don't know which approach is 
more efficient and we should be recommending a path that will make it 
apparent which approach is better.

> I also think that switching from #3 to #1 isn't that hard to deploy.

I agree, as long as the specification makes it clear the KEY rrsets MAY be 
included in the additional section of a response and that caches should 
accept, use and cache these RRsets.  If we go so far as to remove all 
additional processing considerations for KEY, then I think it would be 
difficult to switch.  Or maybe just useless to switch.

So, Ed, what I think you are driving toward is allowing servers to include 
KEY rrsets in the additional section (either all the time or just some of 
the time) but recommending that they do not.  Or am I going to far?

I like this, but I think it makes figuring out how to write an efficient 
client sort of harder.  Does the client, when querying a known or 
suspected secure zone for which it does not have a keyset issue a parallel 
query or not?  If we choose option #1 then maybe clients don't have to 
implement parallel queries?

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Apr 2003 13:31:06 -0400

>apparent which approach is better.

That is one of my arguments.  Thinking about it, I would have placed 
the architectural one and the IDS going ape ones first, but what you 
said above is the most important concern.  It might be that #1 is 
better than #3, but I can't see it and sort of feel that if we choose 
#3 now, the answer will be clear.

>... as long as the specification makes it clear the KEY rrsets MAY be

That's a vital point.  I am assuming that clients are agile (liberal 
in what they deal with while the servers are conservative in the 
range of answers they give).

>the time) but recommending that they do not.  Or am I going to far?

That's the right level.  I can't see banning the practice, but I'd 
like to discourage it if only to provide a 'control group' for the 
experiment (to see if #1 or #3 is the right approach).

>implement parallel queries?

My assumption, rightly or wrongly, is that this isn't a problem. 
Keep in mind that I'm one step up from a tourist when it comes to 
writing resolvers, the last one I did was 6 years ago and was just 
dig with a verifier.  I.e., I didn't dabble in parallelism in anyway 
and didn't try to optimize performance.  I do have a faint 
recollection of being shown, by another implementer, that a deadlock 
was possible if parallel queries went awry.

It would be good to get an opinion from someone who's given more 
recent thought to the implications of this on the resolver (as in - 
has cut code).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer