idnits 2.17.1 draft-barwood-dnsext-dns-transport-signal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 October 2009) is 5293 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNS Extensions Working Group G. Barwood 3 Internet-Draft 4 Intended status: Standards Track 23 October 2009 5 Expires: April 2010 7 DNS Transport Signal 8 draft-barwood-dnsext-dns-transport-signal-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 23, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Describes a DNS resource record that is used to signal support for 47 DNS transport protocols. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 50 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 51 document are to be interpreted as described in [RFC2119]. 53 1. Introduction 55 DNS clients are currently unable to efficiently determine which 56 DNS transport protocols a DNS server supports. 58 DNS clients may try each protocol in turn, but this is an undesirable 59 waste of resources and time, especially as multiple probes have to be 60 sent to take account of packet loss. 62 Even for the current protocols, TCP and UDP, a client may prefer to use 63 TCP for security reasons, but may not be willing to wait for the TCP 64 connection to fail where the server does not support TCP. 66 It is expected that new optional protocols may be added in future, for 67 example SCTP or a new special purpose protocol. 69 Therefore a new resource record type, TPORT is proposed. 71 Note: throughout this document, unless otherwise qualified, "protocol" 72 means "DNS Transport Protocol", that is the means by which DNS messages 73 are conveyed, not the underlying network protocol. [RFC1035] uses the 74 term "transmission channel" when discussing truncation. There may be 75 distinct DNS transport protocols operating over the same underlying 76 protocol, for example over UDP. Typically the first DNS transport 77 protocol using a specific underlying protocol will use the name of the 78 underlying protocol, and subsequent DNS transport protocols over the 79 same underlying protocol wil be given a different name. 81 2. TPORT Resource record format 83 The RDATA wire format is a list of one or more 8-bit numbers that 84 identify DNS transport protocols. 86 The RDATA presentation format is a list of one or more protocol 87 mnenomics. If the mnemonic is not known, the decimal number for the 88 DNS transport protocol may be used instead, as specified in the IANA 89 considerations, section 5. 91 Example: 93 NS1.EXAMPLE.NET. 3600 TPORT UDP TCP 95 3. Protocol 97 The TPORT record for a domain, if it exists, SHOULD be added to the 98 Additional Section of a DNS response whenever an A or AAAA record for 99 the domain is sent. 101 In particular, a parent zone with a glue A or AAAA record may also have 102 a glue TPORT record. If the parent zone does not support the TPORT 103 record, or there is no facility for the domain owner to upload a TPORT 104 record to the parent zone, the method described in Appendix A may be 105 used instead. 107 The TPORT, A and AAAA records SHOULD have the same TTL, and can be 108 considered to form a single logical, consistent RRset that is divided 109 into distinct RRtypes for historical reasons. 111 DNS clients SHOULD use the TPORT information to select the most suitable 112 protocol to use. Clients MAY fall back to another protocol if an 113 advertised protocol fails, but SHOULD take account of the security 114 implications, if the fallback protocol is less secure. 116 The absence of a protocol indicates that clients SHOULD NOT use a 117 protocol for that name server, however if no TPORT record is available, 118 no inferences can be made. 120 The order in which the protocols are listed has no significance. 122 To avoid inter-operability problems with old non-conformant 123 resolvers, when the DNS transport protocol is UDP (without EDNS), or 124 according to similar criteria determined by operational experience, 125 TPORT records MAY be omitted unless explicitly requested. 127 4. Security Considerations 129 Until server support for a new DNS transport protocol is universal, 130 there is a risk that a server may be downgraded after a protocol has 131 been advertised, resulting in a lame server. The risk is higher where 132 in-zone secondary servers are used that are not under the direct control 133 of the domain owner, and no reliable change notification mechanism is in 134 place. Domain owners may avoid this risk by using out-of-zone name 135 server names where they do not have direct control of the servers, 136 however this is not desirable in some cases. Domain owners should 137 carefully weigh the advantages of a new protocol against this risk. 138 Domain owners may conduct regular checks for lameness to mitigate the 139 risk. 141 New transport protocols may have different or unforseen security risks. 142 Otherwise, this specification is not believed to directly cause any 143 new security problems. 145 5. IANA Considerations 147 IANA is requested to allocate the TPORT resource record type, and a 148 sub-registry for DNS transport protocols, initialized to 150 TCP 1 [RFC1035] 151 UDP 2 [RFC1035] 153 Numbers 240 to 250 are reserved for private use. 155 6. Acknowledgments 157 Thanks to Alex Bligh, Matthew Dempsky, Alfred Hoenes, Shane Kerr, 158 Olaf Kolkman and Paul Vixie for their comments. 160 7. Normative References 162 [RFC1035] Mockapetris, P., "Domain names - implementation and 163 specification", STD 13, RFC 1035, November 1987. 165 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels", BCP 14, RFC 2119, March 1997. 168 Appendix A. Name server name encoding 170 It may take some time for the TPORT record to be universally supported. 171 In the interim period, TPORT information may be encoded into a name 172 server name. 174 The convention is that the name server name contains a label starting 175 with 'TPORT-', followed by a list of one or more protocol mnemomics 176 separated by '-'. 178 For example 180 EXAMPLE.COM. 3600 NS A.TPORT-TCP-UDP.EXAMPLE.NET. 182 indicates that the name server for EXAMPLE.COM has support for 183 TCP and UDP. 185 This method is far from ideal, and is intended mainly for early adopters 186 to experiment with this technology. It does however offer the potential 187 for better security. Operators are reminded that correct procedures need 188 to be followed when changing the name servers for a domain. 190 Author's Address 192 George Barwood 193 33 Sandpiper Close 194 Gloucester 195 GL2 4LZ 196 United Kingdom 198 Phone: +44 452 722670 199 EMail: george.barwood@blueyonder.co.uk 201 Barwood Expires April 2010 [Page 4]