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

[Edward Lewis <edlewis@arin.net>]

At 22:06 -0400 4/23/03, Ólafur Guðmundsson wrote:
> 	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.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>