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
