> On Jan 6, 2017, at 6:49 AM, Ray Bellis <r...@isc.org> 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

Reply via email to