Protocol Action: 'DNS Transport over TCP - Implementation Requirements' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:

- 'DNS Transport over TCP - Implementation Requirements '
   <draft-ietf-dnsext-dns-tcp-requirements-03.txt> as a Proposed Standard


This document is the product of the DNS Extensions Working Group. 

The IESG contact persons are Ralph Droms and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns-tcp-requirements-03.txt

Technical Summary

  This document expresses in clearly that general purpose DNS software
  needs to be able to to perform DNS queries over TCP.

Working Group Summary

  The discussion in the working centered on following issues:
  * Is TCP required for some queries: Answer in general yes
  * How should TCP connections be handled: The document states that
    DNS servers can terminate open TCP connections when they want/need
    to. 
  * Is the document requiring DNS operators to provide TCP query
    service: No. Such specification is outside the working group's
    scope and it is a decision for each DNS Operator.

Document Quality

  The document is well written and expresses the issues clearly.  The
  actions are clearly marked and the text that is being updated is
  quoted.

Personnel

   Olafur Gudmundsson (ogud@ogud.com) is the document shepherd.  Ralph
   Droms <rdroms.ietf@gmail.com> is the responsible AD.

RFC Editor Note

Changes to be made before publication:

Section 1:

OLD:

   Most DNS [RFC1035] transactions take place over UDP [RFC0768].  TCP

NEW:

   Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP

Section 4:

OLD:

   o  Authoritative server implementations MUST support TCP so that they
      do not limit the size of responses.
   o  Recursive resolver (or forwarder) implementations MUST support TCP
      so that the do not prevent large responses from a TCP-capable
      server from reaching its TCP-capable clients.
   o  Stub resolver implementations (e.g. an operating system's DNS
      resolution library) MUST support TCP since to do otherwise would
      limit their interoperability with their own clients and with
      upstream servers.

   An exception may be made for proprietary stub resolver
   implementations.  These MAY omit support for TCP if operating in an
   environment where truncation can never occur, or where DNS lookup
   failure is acceptable should truncation occur.

   Regarding the choice of when to use UDP or TCP, RFC 1123 says:

      ... a DNS resolver or server that is sending a non-zone-transfer
      query MUST send a UDP query first.

NEW:

   o  Authoritative server implementations MUST support TCP so that they
      do not limit the size of responses to what fits in a single UDP
      packet.
   o  Recursive server (or forwarder) implementations MUST support TCP
      so that they do not prevent large responses from a TCP-capable
      server from reaching its TCP-capable clients.
   o  Stub resolver implementations (e.g. an operating system's DNS
      resolution library) MUST support TCP since to do otherwise would
      limit their interoperability with their own clients and with
      upstream servers.

   Stub resolver implementations MAY omit support for TCP when
   specifically designed for deployment in restricted environments where
   truncation can never occur or where truncated DNS responses are
   acceptable.

   Regarding the choice of when to use UDP or TCP, Section 6.1.3.2 of
   RFC 1123 also says:

      ... a DNS resolver or server that is sending a non-zone-transfer
      query MUST send a UDP query first.

Section 5:

OLD:

   This document therefore RECOMMENDS that the default application-level
   idle period should be of the order of seconds, but does not specify
   any particular value.  In practise the idle period may vary
   dynamically, and servers MAY allow dormant connections to remain open
   for longer periods as resources permit.

NEW:

   It is therefore RECOMMENDED that the default application-level idle
   period should be of the order of seconds, but no particular value is
   specified.  In practise the idle period may vary dynamically, and
   servers MAY allow dormant connections to remain open for longer
   periods as resources permit.

Section 9:

OLD:

   The author would like to thank the document reviewers from the DNSEXT
   Working Group, and in particular George Barwood, Alex Bligh, Alfred
   Hoenes, Fernando Gont, Jim Reid, Paul Vixie and Nicholas Weaver.

NEW:

   The author would like to thank the document reviewers from the DNSEXT
   Working Group, and in particular George Barwood, Alex Bligh, Alfred
   Hoenes, Fernando Gont, Olafur Gudmondsson, Jim Reid, Paul Vixie and
   Nicholas Weaver.

Section 10.1:

OLD:

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

NEW:

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux