idnits 2.17.1
draft-bellis-dnsop-xpf-03.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 (October 30, 2017) is 2363 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: May 3, 2018 October 30, 2017
9 DNS X-Proxied-For
10 draft-bellis-dnsop-xpf-03
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 May 3, 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. Client Handling . . . . . . . . . . . . . . . . . . . . . 3
60 3.2. Request Handling . . . . . . . . . . . . . . . . . . . . 3
61 3.3. Proxy Handling . . . . . . . . . . . . . . . . . . . . . 4
62 3.4. Server Handling . . . . . . . . . . . . . . . . . . . . . 4
63 3.5. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4
64 3.6. Presentation Format . . . . . . . . . . . . . . . . . . . 6
65 3.7. Signed DNS Requests . . . . . . . . . . . . . . . . . . . 6
66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
67 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7
68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7
72 8.2. Informative References . . . . . . . . . . . . . . . . . 8
73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
75 1. Introduction
77 It is becoming more commonplace to install front end proxy devices in
78 front of DNS servers [RFC1035] to provide load balancing or to
79 perform transport layer conversions (e.g. to add DNS over TLS
80 [RFC7858] to a DNS server that lacks native support).
82 This has the unfortunate side effect of hiding the clients' source IP
83 addresses from the server, making it harder to employ server-side
84 technologies that rely on knowing those addresses (e.g. ACLs, DNS
85 Response Rate Limiting, etc).
87 This document defines the XPF meta resource record (RR) that allows a
88 DNS server to receive information about the client's original
89 transport protocol parameters when supplied by trusted proxies.
91 Whilst in some circumstances it would be possible to re-use the
92 Client Subnet EDNS Option [RFC7871] to carry a subset of this
93 information, a new RR is defined to allow both this feature and the
94 Client Subnet Option to co-exist in the same packet.
96 2. Terminology
98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
100 "OPTIONAL" in this document are to be interpreted as described in BCP
101 14 [RFC2119] [RFC8174] when, and only when, they appear in all
102 capitals, as shown here.
104 The XPF RR is analogous to the HTTP "X-Forwarded-For" header, but in
105 DNS the term "forwarder" is usually understood to describe a network
106 component that sits on the outbound query path of a resolver.
108 Instead we use the term "proxy", which in this document means a
109 network component that sits on the inbound query path in front of a
110 recursive or authoritative DNS server, receiving DNS queries from
111 clients and dispatching them to local servers.
113 3. Description
115 The XPF RR contains the entire 6-tuple (IP version, Layer 4 protocol,
116 source address, destination address, source port and destination
117 port) of the packet received from the client by the proxy.
119 The presence of the source address supports use of ACLs based on the
120 client's IP address.
122 The source port allows for ACLs to support Carrier Grade NAT whereby
123 different end-users might share a single IP address.
125 The destination address supports scenarios where the server behaviour
126 depends upon the packet destination (e.g. BIND view's "match-
127 destinations" option)
129 The protocol and destination port fields allow server behaviour to
130 vary depending on whether DNS over TLS [RFC7858] or DNS over DTLS
131 [RFC8094] are in use.
133 3.1. Client Handling
135 Stub resolvers, client-side proxy devices, and recursive resolvers
136 MUST NOT add the XPF RR to DNS requests.
138 3.2. Request Handling
140 The rules in this section apply to processing of the XPF RR whether
141 by a proxy device or a DNS server.
143 If this RR is received from a non-white-listed client the server MUST
144 return a REFUSED response.
146 If a server finds this RR anywhere other than in the Additional
147 Section of a request it MUST return a REFUSED response.
149 If the value of the RR's IP version field is not understood by the
150 server it MUST return a REFUSED response.
152 If the length of the IP addresses contained in the RR are not
153 consistent with that expected for the given IP version then the
154 server MUST return a FORMERR response.
156 Servers MUST NOT send this RR in DNS responses.
158 3.3. Proxy Handling
160 For each request received, proxies MUST generate an XPF RR containing
161 the 6-tuple representing the client's Layer 3 and Layer 4 headers and
162 append it to the Additional Section of the request (updating the
163 ARCOUNT field accordingly) before sending it to the intended DNS
164 server.
166 If a valid XPF RR is received from a white-listed client the original
167 XPF RR MUST be preserved instead.
169 3.4. Server Handling
171 When this RR is received from a white-listed client the DNS server
172 SHOULD use the transport information contained therein in preference
173 to the packet's own transport information for any data processing
174 logic (e.g. ACLs) that would otherwise depend on the latter.
176 3.5. Wire Format
178 The XPF RR is formatted like any standard RR, but none of the fields
179 except RDLENGTH and RDATA have any meaning in this specification.
180 All multi-octet fields are transmitted in network order (i.e. big-
181 endian).
183 The required values of the RR header fields are as follows:
185 NAME: MUST contain a single 0 octet (i.e. the root domain).
187 TYPE: MUST contain TBD1 (XPF).
189 CLASS: MUST contain 1 (IN).
191 TTL: MUST contain 0 (zero).
193 RDLENGTH: specifies the length in octets of the RDATA field.
195 The RDATA of the XPF RR is as follows:
197 +0 (MSB) +1 (LSB)
198 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
199 0: | Unused | IP Version | Protocol |
200 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
201 2: | Source Address Octet 0 | ... |
202 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
203 | ... /// |
204 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
205 | Destination Address Octet 0 | ... |
206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
207 | ... /// |
208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
209 | Source Port |
210 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
211 | Destination Port |
212 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
214 Unused: Currently reserved. These bits MUST be zero unless redefined
215 in a subsequent specification.
217 IP Version: The IP protocol version number used by the client, as
218 defined in the IANA IP Version Number Registry [IANA-IP].
219 Implementations MUST support IPv4 (4) and IPv6 (6).
221 Protocol: The Layer 4 protocol number (e.g. UDP or TCP) as defined
222 in the IANA Protocol Number Registry [IANA-PROTO].
224 Source Address: The source IP address of the client.
226 Destination Address: The destination IP address of the request, i.e.
227 the IP address of the proxy on which the request was received.
229 Source Port: The source port used by the client.
231 Destination Port: The destination port of the request.
233 The length of the Source Address and Destination Address fields will
234 be variable depending on the IP Version used by the client.
236 3.6. Presentation Format
238 XPF is a meta RR that cannot appear in master format zone files, but
239 a standardised presentation format is defined here for use by
240 debugging utilities that might need to display the contents of an XPF
241 RR.
243 The Unused bits and the IP Version field are treated as a single
244 octet and presented as an unsigned decimal integer with range 0 ..
245 255.
247 The Protocol field is presented as an unsigned decimal integer with
248 range 0 .. 255.
250 The Source and Destination Address fields are presented either as
251 IPv4 or IPv6 addresses according to the IP Version field. In the
252 case of IPv6 the recommendations from [RFC5952] SHOULD be followed.
254 The Source and Destination Port fields are presented as unsigned
255 decimal integers with range 0 .. 65535.
257 3.7. Signed DNS Requests
259 Any XPF RRs found in a packet MUST be ignored for the purposes of
260 calculating or verifying any signatures used for Secret Key
261 Transaction Authentication for DNS [RFC2845] or DNS Request and
262 Transaction Signatures (SIG(0)) [RFC2931].
264 Typically it is expected that proxies will append the XPF RR to the
265 packet after any existing TSIG or SIG(0) RRs, and that servers will
266 remove the XPF RR from the packet prior to verification of the
267 original signature, with the ARCOUNT field updated as appropriate.
269 If either TSIG or SIG(0) are configured between the proxy and server
270 then any XPF RRs MUST be ignored when the proxy calculates the packet
271 signature.
273 4. Security Considerations
275 If the white-list of trusted proxies is implemented as a list of IP
276 addresses, the server administrator MUST have the ability to
277 selectively disable this feature for any transport where there is a
278 possibility of the proxy's source address being spoofed.
280 This does not mean to imply that use over UDP is impossible - if for
281 example the network architecture keeps all proxy-to-server traffic on
282 a dedicated network and clients have no direct access to the servers
283 then the proxies' source addresses can be considered unspoofable.
285 5. Privacy Considerations
287 Used incorrectly, this RR could expose internal network information,
288 however it is not intended for use on proxy / forwarder devices that
289 sit on the client-side of a DNS request.
291 This specification is only intended for use on server-side proxy
292 devices that are under the same administrative control as the DNS
293 servers themselves. As such there is no change in the scope within
294 which any private information might be shared.
296 Use other than as described above would be contrary to the principles
297 of [RFC6973].
299 6. IANA Considerations
301 << a copy of the RFC 6895 IANA RR TYPE application template will
302 appear here >>
304 7. Acknowledgements
306 Mark Andrews, Robert Edmonds, Duane Wessels
308 8. References
310 8.1. Normative References
312 [IANA-IP] IANA, "IANA IP Version Registry", n.d.,
313 .
315 [IANA-PROTO]
316 IANA, "IANA Protocol Number Registry", n.d.,
317 .
319 [RFC1035] Mockapetris, P., "Domain names - implementation and
320 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
321 November 1987, .
323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
324 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
325 RFC2119, March 1997, .
328 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
329 Wellington, "Secret Key Transaction Authentication for DNS
330 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
331 .
333 [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
334 ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
335 2000, .
337 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
338 Morris, J., Hansen, M., and R. Smith, "Privacy
339 Considerations for Internet Protocols", RFC 6973, DOI
340 10.17487/RFC6973, July 2013, .
343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
345 May 2017, .
347 8.2. Informative References
349 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
350 Address Text Representation", RFC 5952, DOI 10.17487/
351 RFC5952, August 2010, .
354 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
355 and P. Hoffman, "Specification for DNS over Transport
356 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
357 2016, .
359 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
360 Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI
361 10.17487/RFC7871, May 2016, .
364 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram
365 Transport Layer Security (DTLS)", RFC 8094, DOI 10.17487/
366 RFC8094, February 2017, .
369 Authors' Addresses
371 Ray Bellis
372 Internet Systems Consortium, Inc.
373 950 Charter Street
374 Redwood City CA 94063
375 USA
377 Phone: +1 650 423 1200
378 Email: ray@isc.org
379 Peter van Dijk
380 PowerDNS.COM B.V.
381 Den Haag
382 The Netherlands
384 Email: peter.van.dijk@powerdns.com
386 Remi Gacogne
387 PowerDNS.COM B.V.
388 Den Haag
389 The Netherlands
391 Email: remi.gacogne@powerdns.com