ietf-mailsig
[Top] [All Lists]

Re: the DNS issue

2004-10-06 16:16:57

So for those of us who weren't around when Marid slogged throgh this,
can somebody give a short synopsis of the deployment issues?

One minor issue is that few DNS servers make it easy to add new record
types, e.g., in djbdns which I use, you have to use octal escapes to
create records that aren't in the small list of record types that the
data file compiler understands.

The largest set of major issues are specific to Microsoft software.
One is that their DNS server apparently can't do new record types even
with something like octal escapes, so the only way to get them into
the server is to axfr or cache copies from a more capable server.  The
real killer is that someone designed the DNS services behind their
firewall with a separate RPC for each record type, and a server on the
firewall that translates the RPC requests from behind the firewall
into normal DNS requests outside.  The firewall doesn't pass normal
DNS traffic at all.  To handle a new record type you have both to
upgrade the firewall server to handle the new record type with a new
RPC, and you have to upgrade the client machines behind the firewall
to call the new RPC.  You don't have to tell me that this isn't how
you would have done it, but it's how MS did it.

Another set of issues relates to response sizes.  If all the records
in an RRSET don't fit in 512 bytes, the server truncates the request
and the client falls back to TCP unless they both implement EDNS0
which is not widely deployed (although it's wider than I would have
expected, particularly in MS-land.)  Nobody has large scale experience
with TCP queries, so there may be unknown performance problems, due
both to the packet traffic and the way that servers handle TCP
connections rather than UDP packets.  Another issue noted by someone
who runs big DNS server farms is that some common versions of the Unix
resolver library fail in an unpleasant way if a TCP response doesn't
fit in a single packet.  This is a plain old, bug, but its symptom is
that the client retries at top speed indefinitely, so it's one that
could be an operational problem.

I agree that neither of the first two rule out new RR types,
particularly on services that are likely to be used on gateway servers
more than on user clients, and of course the third makes new RR types
more desirable to keep response sizes down.

Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
http://www.taugh.com


<Prev in Thread] Current Thread [Next in Thread>