One document matched: draft-barwood-dnsext-dns-transport-signal-00.txt

DNS Extensions Working Group                                  G. Barwood
Internet-Draft                                                          
Intended status: Standards Track                       20 September 2009
Expires: March 2010


                           DNS Transport Signal
               draft-barwood-dnsext-dns-transport-signal-00

Status of this Memo
  
   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 19, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Describes a DNS resource record that is used to signal support for
   DNS transport protocols.



Barwood                    Expires March 2010                   [Page 1]

Internet-Draft            DNS Transport Signal            September 2009

1.  Introduction

DNS clients are currently unable to efficiently determine which
transport protocols a DNS server supports.

A DNS client may try each protocol in turn, but this is an undesirable
waste of resources and time, especially as multiple probes have to be
sent to take account of packet loss.

Even for the current protocols, TCP and UDP, a client may prefer to use
TCP for security reasons, but may not be willing to wait for the TCP
connection to fail where the server does not support TCP.

It is expected that new optional transport protocols may be added in
future, for example a protocol which combines the best features of
TCP and UDP.

Therefore a new resource record type, TPORT is proposed.

2. TPORT Resource record format

The RDATA wire format is a list of 8-bit numbers that identify DNS 
transport protocols.

The RDATA presentation format is a list of protocol mnenomics. 
If the mnemonic is not known, PROTOCOL<n> may be used where <n> is the
number of the protocol.

Example:

NS1.EXAMPLE.NET.  3600 TPORT UDP TCP

3. Protocol

The TPORT record for a domain is added to the Additional Section of a
DNS response whenever an A or AAAA record for the domain is sent.

In particular, a parent zone with a glue A or AAAA record may also have
a glue TPORT record. If the parent zone does not support the TPORT
record, or there is no facility for the domain owner to upload a TPORT
record to the parent zone, the method described in Appendix A may be
used instead.

4.  Security Considerations

TBD





Barwood                    Expires March 2010                   [Page 2]

Internet-Draft            DNS Transport Signal            September 2009

5.  IANA Considerations

The TPORT resource record type, with a sub-registry for DNS transport 
protocols, initialized to

TCP                1     [RFC1035]
UDP                2     [RFC1035]

6.  Acknowledgments

TBD

7.  Normative References

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

Appendix A. Name server name encoding

It may take some time for the TPORT record to be universally supported.
In the interim period, TPORT information may be encoded into a name
server name.

The convention is that the name server name contains a label starting
with 'TPORT-', followed by a list of one or more protocol mnemomics
separated by '-'.  

For example

EXAMPLE.COM 3600 NS TPORT-TCP-UDP.NS1.EXAMPLE.NET.

indicates that the name server for EXAMPLE.COM has support for
TCP and UDP.

Author's Address

   George Barwood
   33 Sandpiper Close
   Gloucester
   GL2 4LZ
   United Kingdom

   Phone: +44 452 722670
   EMail: george.barwood@blueyonder.co.uk







Barwood                       Expires March 2010               [Page  3]