Re: [dnsext] draft-ietf-dnsext-dns-tcp-requirements-00 / a way forward

[Alfred Hönes <ah@TR-Sys.de>]

> Dear all,
>
> sorry for answering late, but I was traveling...
> Some comments in-line.
>
> After looking at
> draft-ietf-dnsext-dns-tcp-requirements-00
> I think you want to use an unmodified TCP. So deployment
> of the transport stack is not an issue. Am I right?
>
> More comments in-line.
>
> Best regards
> Michael
>
> ...[snip]...

Michael, Andrew, all,

Focusing on draft-ietf-dnsext-dns-tcp-requirements-00,
I would like to reinforce that I had never proposed to include
discussion of 'other DNS transports' into that document.

My suggestion was to elaborate on TCP properties for several
reasons (see below), and for the WG to obtain support from
transport protocol experts in pursuing its chartered work item
to evaluate existing and consider new transports for DNS.

I admit that the nearby publication of the above draft and
George Barwoods DNS transport related drafts, as well as the
rechartering of the WG may have lead to comments with a
Subject not totally encompassing some ideas contained in the
message that had been cross-fertilized by these (natively
independent) events.

So let's focus on TCP.

I fully support the idea of the draft, as already indicated.

And I fully support Michael in that we want to use "unmodified TCP".

But TCP has a lot of Options, and perhaps all commercial and
open-source TCP stack implementations have a lot of tuning knobs
to adjust parameters, enable/disable options and mechanisms, etc.
-- that's particularly interesting for DNS server/resolver operators.
Furthermore, the TCP (socket) API contains features that allow
programmatic access to particular features, mechanisms and options
of TCP -- how to best make use thereof is highly interesting for
implementers of DNS software.

The main reason for having this draft is the perceived unwillingness
of various parties to implement/support/allow TCP as it was intended,
a mandatory transport for DNS in case UDP does not suffice, in
particular for packet size / fragmentation reasons.

We (or many of us) want to convince those parties posing obstacles
to this use of TCP that their opposition is not justified, and that
IMO cannot be done by a simple normative statement of "MUST" for TCP.
No, we need to provide arguments and show ways to mitigate the raised
concerns!  Exploring the effects of TCP options and parameters and
giving recommendations to implementers and operators of how to use TCP
in the best possible manner seems the right way to achieve this goal.
This should include concrete arguments for implementors and vendors
of middleboxes that DNS over TCP is not evil.

If we can agree on this strategy, the draft has a chance to be
amended and turned into a valuable document that gives enough
concrete guidance to both implementers and operators to actually
overcome the observed reservedness against the TCP support for
DNS transactions as specified in STD 13 and STD 3.

Such exploration and elaboration should also better educate the
WG on aspects of DNS transport, allowing it to perform -- in a
second step then -- a more targeted evaluation of proposals for
alternate DNS transport(s), and eventually make better informed
decisions on how to proceed with new proposals to this end.

N.B.: The priority of dealing with possible signalling of Transport
(and/or other feature) support in DNS servers may very well be made
dependent on the outcome of the first steps above.

Can wee agree on this way forward?


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:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+