Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
On 06/01/2017 18:43, Wessels, Duane wrote: > Hi Ray, > > The idea of "X-Forwarded-For" for DNS makes me nervous, but it is > probably inevitable. > > It is of course quite similar to EDNS client subnet, except that > there is no masking and the client cannot opt-out. Might be worth > saying in your document why EDNS client subnet wouldn't work for this > purpose. I believe that dnsdist / PowerDNS is already (ab)using the ECS option for this purpose. The intent in part is to provide a separate option so that "real" ECS can pass unhindered. [ not that I think ECS is a good idea, but some folks want it, c'est la vie ] > Since you use the term proxy throughout I wondered if proxy was > defined in our terminology document. Looks like it is not. > terminology-bis-03 says: > > [RFC5625] does not give a specific definition for forwarding, but > describes in detail what features a system that forwards need to > support. Systems that forward are sometimes called "DNS proxies", > but that term has not yet been defined (even in [RFC5625]). > > I think we should define proxy in the terminology doc, or use some > other well-defined terms in your XPF doc. I should probably define "proxy". I specifically avoided the term "forwarding" (c.f. X-Forwarded-For in HTTP) because in our terminology a forwarder is usually something on the "outbound" side of a resolver, whereas this is on the "inbound" side. > Despite when you say "it is not intended for use on proxy / forwarder > devices that sit on the client-side of a DNS request" and "only > intended for use on server-side proxy devices that are under the same > administrative control" I fully expect XPF will be implemented and > used in all sorts of places. For example, some clients will include > the option in queries to authoritative servers, which will go > unnoticed for a while. Then it will be noticed by servers and > they'll take advantage of it somehow (logging, treating it like ECS, > etc). To hopefully prevent that I might propose something like: > > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. That's a very good idea. I should probably also include even more explicit text explaining that this is for "internal use" only, and MUST NOT be sent from a stub to a resolver, nor from an recursor to an authority server. It's only intended to be injected by server-side DNS equipment that's a front-end onto local DNS servers that would already know the client source IP if the proxy wasn't there. thanks! Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
On Fri, Jan 06, 2017 at 06:43:30PM +, Wessels, Duane wrote: > When a server receives the option from a non-whitelisted client, it > MUST return a FORMERR response. +1 -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
For folk wondering what Ray is referring to below, I posted this to the DPRIVE (dns-privacy@) list last night. I was originally going to CC dnsop@ but cross-posting leads to many "your message could not be delivered, you aren't subscribed" errors. The obvious, bestest solution would just be for everyone in dnsop to subscribe to dns-privacy@ -- we're a friendly bunch, and are always looking for more victims for reviews^w^w^w participants... :-) Original DPRIVE email: - Hi all, I have created a Docker container for easily deploying a DPRIVE RFC7858 (DNS over TLS) server. This is implemented by putting a TLS proxy (NGINX) in front of a recursive nameserver (BIND). It can be found here: https://github.com/wkumari/dprive-nginx-bind This repo contains the Dockerfile, some rudimentary documentation and supporting files, including NGINX and BIND configs, and some Google Container Engine configs for starting and running the container / service. Most of the credit goes to Sara / Sinodun for documenting how to run BIND behind NGINX as a TLS proxy. I just wrapped this up in a container. Please let me know what you think, open issues, send pull requests, etc. Thanks. W On Fri, Jan 6, 2017 at 9:49 AM Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf > > Ray > > Forwarded Message > Subject: New Version Notification for draft-bellis-dnsop-xpf-00.txt > Date: Fri, 06 Jan 2017 06:18:40 -0800 > From: internet-dra...@ietf.org > To: Ray Bellis > > > A new version of I-D, draft-bellis-dnsop-xpf-00.txt > has been successfully submitted by Ray Bellis and posted to the > IETF repository. > > Name: draft-bellis-dnsop-xpf > Revision: 00 > Title: EDNS X-Proxied-For > Document date: 2017-01-06 > Group: Individual Submission > Pages: 6 > URL: > https://www.ietf.org/internet-drafts/draft-bellis-dnsop-xpf-00.txt > Status: https://datatracker.ietf.org/doc/draft-bellis-dnsop-xpf/ > Htmlized: https://tools.ietf.org/html/draft-bellis-dnsop-xpf-00 > > > Abstract: >It is becoming more commonplace to install front end proxy devices in >front of DNS servers to provide (for example) load balancing or to >perform transport layer conversions. > >This document defines an option within the EDNS(0) Extension >Mechanism for DNS that allows a DNS server to receive the original >client source IP address when supplied by trusted proxies. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
> On Jan 6, 2017, at 6:49 AM, Ray Bellis wrote: > > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Hi Ray, The idea of "X-Forwarded-For" for DNS makes me nervous, but it is probably inevitable. It is of course quite similar to EDNS client subnet, except that there is no masking and the client cannot opt-out. Might be worth saying in your document why EDNS client subnet wouldn't work for this purpose. Since you use the term proxy throughout I wondered if proxy was defined in our terminology document. Looks like it is not. terminology-bis-03 says: [RFC5625] does not give a specific definition for forwarding, but describes in detail what features a system that forwards need to support. Systems that forward are sometimes called "DNS proxies", but that term has not yet been defined (even in [RFC5625]). I think we should define proxy in the terminology doc, or use some other well-defined terms in your XPF doc. Despite when you say "it is not intended for use on proxy / forwarder devices that sit on the client-side of a DNS request" and "only intended for use on server-side proxy devices that are under the same administrative control" I fully expect XPF will be implemented and used in all sorts of places. For example, some clients will include the option in queries to authoritative servers, which will go unnoticed for a while. Then it will be noticed by servers and they'll take advantage of it somehow (logging, treating it like ECS, etc). To hopefully prevent that I might propose something like: When a server receives the option from a non-whitelisted client, it MUST return a FORMERR response. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
On 06/01/2017 18:01, Robert Edmonds wrote: > It can be rev'd in the same document that introduces a DNS address RR > for that address family :-) Fair enough! I'll rely on you to remind me when the time comes ;-) Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
Ray Bellis wrote: > Yes, that seems like a reasonable suggestion, although it would be a > shame to have to rev the doc if another IP version should even happen to > be introduced in the future... It can be rev'd in the same document that introduces a DNS address RR for that address family :-) -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
On 06/01/2017 17:28, Robert Edmonds wrote: > Hi, Ray: > > The values used by the "IP Version" field should be specified: > >IP Version: The IP protocol version number used by the client. > > Since the field is 4 bits long I would guess this field happens to be > the same as the version field in the IP header [0], maybe with the > restriction that the field can only take on the values 4 and 6? > > [0] http://www.iana.org/assignments/version-numbers/version-numbers.xhtml Robert, Yes, that seems like a reasonable suggestion, although it would be a shame to have to rev the doc if another IP version should even happen to be introduced in the future... I'd rather leave the question of permitted values open, perhaps with guidance about what to do if the value is not recognised by the server (REFUSED, perhaps?) Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt
Ray Bellis wrote: > Spurred on by Warren's announcement of a Docker image that uses NGINX to > proxy TLS connections into DNS servers that don't natively support TLS, > I've just written up this short draft describing an EDNS0 option that > allows smart proxies to tell the backend server what the original client > IP address was. > > The master doc is at https://github.com/raybellis/draft-bellis-dnsop-xpf Hi, Ray: The values used by the "IP Version" field should be specified: IP Version: The IP protocol version number used by the client. Since the field is 4 bits long I would guess this field happens to be the same as the version field in the IP header [0], maybe with the restriction that the field can only take on the values 4 and 6? [0] http://www.iana.org/assignments/version-numbers/version-numbers.xhtml -- Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
