> On Jan 6, 2017, at 6:49 AM, Ray Bellis <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
