Subject: Re: [dnsext] Draft: WGLC draft-ietf-dnsext-dns-tcp-requirements

From: Alfred Hönes <[email-masked]>
Date: Wed, 17 Feb 2010 22:18:10 +0100 (MEZ)

At Wed, 17 Feb 2010 12:49:53 -0800, Matthew Dempsky wrote:

> On Wed, Feb 17, 2010 at 12:32 PM, Nicholas Weaver
>  <[email-masked]> wrote:
>> An implementation has no way of knowing that responses will never
>> need to be truncated.
> 
> False.  djbdns includes a dedicated RBL DNS server (rbldns) that uses
> a database consisting of just a bunch of blacklisted CIDR blocks.  It
> only ever returns answers with a single A record and/or a single TXT
> record less than about 100 bytes long.  It knows it will never return
> a truncated response.

Such dedicated, special-purpose servers -- entirely independent of
their particular implementation -- serve a rather small population
of clients specifically configured to consult this authority in order
to frequently get data points needed to make policy decisions, isn't it?

So these clients would perhaps really appreciate using persistent TCP
connections to that server -- they can easily amortize the connection
set-up overhead over thousands of requests and gain the security
benefits of TCP (in particular improved forgery resilience) vs. UDP.

This perspective would make a serious case to implement TCP on such
dedicated servers as well.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 13:57:41 -0800

> to frequently get data points needed to make policy decisions, isn't it?

No, they're used for serving authoritative zones such as
zen.spamhaus.org and dynablock.njabl.org.

> benefits of TCP (in particular improved forgery resilience) vs. UDP.

Which DNS clients are you referring to?  Most stub resolvers still
query these DNS RBLs through a standard DNS recursive resolver (to
benefit from caching), so the protocol those clients use to
communicate has no bearing on what the authoritative server supports.

If you mean the recursive resolver, then are there any recursive
resolver implementations that opt to maintain and use a persistent TCP
connection to pipeline queries rather than just issue multiple UDP
queries in parallel?  If such servers don't exist today, I certainly
don't see a need to mandate that authoritative servers support their
possible existence in the future.

> dedicated servers as well.

I'm not convinced, and even if it were, it's not a serious case to
*require* these dedicated servers to implement TCP.  (Note: none of
the authoritative name servers for zen.spamhaus.org or
dynablock.njabl.org currently support DNS queries over TCP.)

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 18 Feb 2010 13:47:21 +0100 (MEZ)

Matthew Dempsky wrote

> zen.spamhaus.org and dynablock.njabl.org.

Why "No" ?  You confirm that these servers host specialized zones
offering a specific service that has nothing to do with host IP address
and domain name lookup; they use the DNS as a general purpose database,
leveraging the universal support of its query protocol, and of course
they are authoritative for this purpose.
That's legitimate use of the DNS, but *specialized*, and typically
only (medium to large scale) receiving MTA systems will be interested
in querying this service.  That's what I said in a more abstract manner.

>  ... (Note: none of the authoritative name servers for
>  zen.spamhaus.org or dynablock.njabl.org currently support
>  DNS queries over TCP.)

... and you argue that resolvers don't use TCP for these.

Isn't that a typical chicken-and-egg problem?
It is not convincing how you argue in circles this way.

Only long-standing support of TCP in the servers would
have given the 'customers' of these services an opportunity
to evaluate the choice of transport in an unbiased manner.
Your favorite point would start to become credible it these
clients would have had the opportunity to try and nobody were
using TCP after several years.  But that isn't the case.
They did not even have a chance to try.
So your argument remains hypothetical, at best.

Further, to my best knowledge, customers of DNSBL services
prefer operating their own caches (caching end-system resolvers
as originally envisioned by RFC 1034/35, or caching resolvers
co-located whith the clients) -- that's much more efficient,
gives more tight control on caching strategies, and can be
operated under locally controlled security measures as compared
to making use of an untrusted third-party operated recursive
caching resolver; thus I still presume that using persistent TCP
connections would be an attractive option for these DNSBL customers,
*if* the server implementers had not been neglecting the wisdom
spoken 24 years ago in STD 13, as quoted in the subject draft.

Matthew, as others have observed, you are the only one opposing to
simple, straightforward rules in this document.  Nobody will 'urge'
the implementers of the dedicated servers you have quoted to claim
conformance to the RFC-dns-tcp-requirements which I hope we will be
arriving at soon.  But their decision will become more visible,
to the benefit of prospective users.

Stating complicated, vague exceptional rules for a requirement
that can easily be fulfilled by implementations -- according to
evidence provided on this list -- would open the opportunity for
an ongoing endless debate on their exegesis.  The whole point of
this draft is to stop the endless debate we had over many years.
The chartered goal supported by the vast majority of the working
group is to send out an inequivocal, clear and simple message --
MUST implement.  Period.

Kind regards,
  Alfred Hönes.

--