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

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Jan 2017 14:49:26 +0000

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: [email-masked]
To: Ray Bellis <[email-masked]>

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.

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 6 Jan 2017 12:28:22 -0500

> 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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Jan 2017 17:38:18 +0000

> [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

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 6 Jan 2017 13:01:10 -0500

> 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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Jan 2017 18:04:10 +0000

> for that address family :-)

Fair enough!

I'll rely on you to remind me when the time comes ;-)

Ray

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 6 Jan 2017 18:43:30 +0000

> On Jan 6, 2017, at 6:49 AM, Ray Bellis <[email-masked]> 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.

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 06 Jan 2017 19:58:19 +0000

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 <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Evan Hunt <[email-masked]>
Date: Fri, 6 Jan 2017 20:40:59 +0000

>   MUST return a FORMERR response.

+1

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 6 Jan 2017 22:02:16 +0000

On 06/01/2017 18:43, Wessels, Duane wrote:

> 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:
> 
> 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:
> 

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