idnits 2.17.1 draft-bellis-dnsop-xpf-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2931, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2845, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2845, updated by this document, for RFC5378 checks: 2000-03-02) (Using the creation date from RFC2931, updated by this document, for RFC5378 checks: 2000-03-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 03, 2017) is 2487 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-IP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-PROTO' ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Informational RFC: RFC 6973 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group R. Bellis 3 Internet-Draft ISC 4 Updates: RFC 2845, RFC 2931 (if P. van Dijk 5 approved) (if approved) R. Gacogne 6 Intended status: Standards Track PowerDNS 7 Expires: January 4, 2018 July 03, 2017 9 DNS X-Proxied-For 10 draft-bellis-dnsop-xpf-02 12 Abstract 14 It is becoming more commonplace to install front end proxy devices in 15 front of DNS servers to provide (for example) load balancing or to 16 perform transport layer conversions. 18 This document defines a meta resource record that allows a DNS server 19 to receive information about the client's original transport protocol 20 parameters when supplied by trusted proxies. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 4, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Proxy Processing . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Server Processing . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.4. Presentation Format . . . . . . . . . . . . . . . . . . . 5 63 3.5. Signed DNS Requests . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 8.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 It is becoming more commonplace to install front end proxy devices in 76 front of DNS servers [RFC1035] to provide load balancing or to 77 perform transport layer conversions (e.g. to add DNS over TLS 78 [RFC7858] to a DNS server that lacks native support). 80 This has the unfortunate side effect of hiding the clients' source IP 81 addresses from the server, making it harder to employ server-side 82 technologies that rely on knowing those addresses (e.g. ACLs, DNS 83 Response Rate Limiting, etc). 85 This document defines a DNS meta resource record (RR) that allows a 86 DNS server to receive information about the client's original 87 transport protocol parameters when supplied by trusted proxies. 89 Whilst in some circumstances it would be possible to re-use the 90 Client Subnet EDNS Option [RFC7871] to carry a subset of this 91 information, a new RR is defined to allow both this feature and the 92 Client Subnet Option to co-exist in the same packet. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 The word "proxy" in this document means a network component that sits 103 on the inbound query path in front of a recursive or authoritative 104 DNS server, receiving DNS queries from clients and dispatching them 105 to local servers. This is to distinguish these from a "forwarder" 106 since that term is usually understood to describe a network component 107 that sits on the outbound query path of a client. 109 3. Description 111 The XPF RR contains the entire 5-tuple of (protocol, source address, 112 destination address, source port and destination port) of the packet 113 received from the client by the proxy. 115 The presence of the source address supports use of ACLs based on the 116 client's IP address. 118 The source port allows for ACLs to support Carrier Grade NAT whereby 119 different end-users might share a single IP address. 121 The destination address supports scenarios where the server behaviour 122 depends upon the packet destination (e.g. BIND view's "match- 123 destinations" option) 125 The protocol and destination port fields allow server behaviour to 126 vary depending on whether DNS over TLS [RFC7858] or DNS over DTLS 127 [RFC8094] are in use. 129 3.1. Proxy Processing 131 Proxies MUST append this RR to the Additional Section of each request 132 packet received (and update the ARCOUNT field accordingly) before 133 sending it to the intended DNS server. 135 If this RR is already present in an incoming request it MUST be 136 stripped from the request unless the request was received from an 137 upstream proxy that is itself white-listed by the receiving proxy 138 (i.e. if the proxies are configured in a multi-tier architecture), in 139 which case the original value the RRs MUST be preserved. 141 Where multiple XPF RRs to appear in a request their ordering MUST 142 also be preserved. 144 << TODO: what about truncation on the client -> server path? >> 146 3.2. Server Processing 148 When this RR is received from a white-listed client the DNS server 149 SHOULD use the transport information contained therein in preference 150 to the packet's own transport information for any data processing 151 logic (e.g. ACLs) that would otherwise depend on the latter. 153 If this RR is received from a non-white-listed client the server MUST 154 return a REFUSED response. 156 If a server finds this RR anywhere other than in the Additional 157 Section of a request it MUST return a REFUSED response. 159 If the value of the RR's IP version field is not understood by the 160 server it MUST return a REFUSED response. 162 If the length of the IP addresses contained in the RR are not 163 consistent with that expected for the given IP version then the 164 server MUST return a FORMERR response. 166 Servers MUST NOT send this RR in DNS responses. 168 3.3. Wire Format 170 The XPF RR is formatted like any standard RR, but none of the fields 171 except RDLENGTH and RDATA have any meaning in this specification. 172 All multi-octet fields are transmitted in network order (i.e. big- 173 endian). 175 The required values of the RR header fields are as follows: 177 NAME: MUST contain a single 0 octet (i.e. the root domain). 179 TYPE: MUST contain TBD1 (XPF). 181 CLASS: MUST contain 1 (IN). 183 TTL: MUST contain 0 (zero). 185 RDLENGTH: specifies the length in octets of the RDATA field. 187 The RDATA of the XPF RR is as follows: 189 +0 (MSB) +1 (LSB) 190 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 191 0: | Unused | IP Version | Protocol | 192 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 193 2: | Source Address Octet 0 | ... | 194 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 195 | ... /// | 196 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 | Destination Address Octet 0 | ... | 198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 199 | ... /// | 200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 201 | Source Port | 202 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 203 | Destination Port | 204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 206 Unused: Currently reserved. These bits MUST be zero unless redefined 207 in a subsequent specification. 209 IP Version: The IP protocol version number used by the client, as 210 defined in the IANA IP Version Number Registry [IANA-IP]. 211 Implementations MUST support IPv4 (4) and IPv6 (6). 213 Protocol: The Layer 4 protocol number (e.g. UDP or TCP) as defined 214 in the IANA Protocol Number Registry [IANA-PROTO]. 216 Source Address: The source IP address of the client. 218 Destination Address: The destination IP address of the request, i.e. 219 the IP address of the proxy on which the request was received. 221 Source Port: The source port used by the client. 223 Destination Port: The destination port of the request. 225 The length of the Source Address and Destination Address fields will 226 be variable depending on the IP Version in use. 228 3.4. Presentation Format 230 Since this is a "meta" RR that cannot appear in master format zone 231 files no presentation format is defined. 233 3.5. Signed DNS Requests 235 Any XPF RRs found in a packet MUST be ignored for the purposes of 236 verifying any signatures used for Secret Key Transaction 237 Authentication for DNS [RFC2845] or DNS Request and Transaction 238 Signatures (SIG(0)) [RFC2931]. 240 Similarly, if either TSIG or SIG(0) are configured between the proxy 241 and server then any XPF RRs MUST be ignored when the proxy calculates 242 the packet signature. 244 4. Security Considerations 246 If the white-list of trusted proxies is implemented as a list of IP 247 addresses, the server administrator MUST have the ability to 248 selectively disable this feature for any transport where there is a 249 possibility of the proxy's source address being spoofed. 251 This does not mean to imply that use over UDP is impossible - if for 252 example the network architecture keeps all proxy-to-server traffic on 253 a dedicated network and clients have no direct access to the servers 254 then the proxies' source addresses can be considered unspoofable. 256 5. Privacy Considerations 258 Used incorrectly, this RR could expose internal network information, 259 however it is not intended for use on proxy / forwarder devices that 260 sit on the client-side of a DNS request. 262 This specification is only intended for use on server-side proxy 263 devices that are under the same administrative control as the DNS 264 servers themselves. As such there is no change in the scope within 265 which any private information might be shared. 267 Use other than as described above would be contrary to the principles 268 of [RFC6973]. 270 6. IANA Considerations 272 << a copy of the RFC 6895 IANA RR TYPE application template will 273 appear here >> 275 7. Acknowledgements 277 Mark Andrews, Robert Edmonds, Duane Wessels 279 8. References 281 8.1. Normative References 283 [IANA-IP] IANA, "IANA IP Version Registry", n.d., 284 . 286 [IANA-PROTO] 287 IANA, "IANA Protocol Number Registry", n.d., 288 . 290 [RFC1035] Mockapetris, P., "Domain names - implementation and 291 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 292 November 1987, . 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 296 RFC2119, March 1997, 297 . 299 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 300 Wellington, "Secret Key Transaction Authentication for DNS 301 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 302 . 304 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures 305 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September 306 2000, . 308 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 309 Morris, J., Hansen, M., and R. Smith, "Privacy 310 Considerations for Internet Protocols", RFC 6973, DOI 311 10.17487/RFC6973, July 2013, 312 . 314 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 315 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 316 May 2017, . 318 8.2. Informative References 320 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 321 and P. Hoffman, "Specification for DNS over Transport 322 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 323 2016, . 325 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 326 Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 327 10.17487/RFC7871, May 2016, 328 . 330 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 331 Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/ 332 RFC8094, February 2017, 333 . 335 Authors' Addresses 337 Ray Bellis 338 Internet Systems Consortium, Inc. 339 950 Charter Street 340 Redwood City CA 94063 341 USA 343 Phone: +1 650 423 1200 344 Email: ray@isc.org 346 Peter van Dijk 347 PowerDNS.COM B.V. 348 Den Haag 349 The Netherlands 351 Email: peter.van.dijk@powerdns.com 353 Remi Gacogne 354 PowerDNS.COM B.V. 355 Den Haag 356 The Netherlands 358 Email: remi.gacogne@powerdns.com