Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-xpf-00.txt

[Ray Bellis <[e-mail]>]

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