Subject: Re: [DNSOP] DNSOP Digest, Vol 122, Issue 9

From: Richard Gibson <[email-masked]>
Date: Fri, 6 Jan 2017 17:20:20 -0500

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

> It can be rev'd in the same document that introduces a DNS address RR
> for that address family :-)
>

Why not use Address Family
<http://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml>
 like EDNS Client Subnet <https://tools.ietf.org/html/rfc7871#section-6>?
But for that matter...

On Fri, 6 Jan 2017 18:43:30 +0000, "Wessels, Duane" <[email-masked]
> 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.
>

Why *wouldn't* ECS work for this? If the idea is to expose
everything obscured by a proxy (e.g., for backend logging), then the option
data should include quite a bit more than an address—at minimum, a protocol
number
<http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml> for
differentiating UDP/TCP, the original OPT CLASS (UDP payload size) and
flags (including DO), and a flag indicating presence or absence of an OPT
record in the original query. You might also want to include the port and
id from the original query (for direct response) and/or allow arbitrary
data after the address (for communicating installation-specific metadata).

---

From: "Wessels, Duane" <[email-masked]>
Date: Fri, 6 Jan 2017 22:38:50 +0000

> On Jan 6, 2017, at 2:20 PM, Richard Gibson <[email-masked]> wrote:
> 
> Why wouldn't ECS work for this? 

I think because you might have a "backend" server that wants to know both the recursive server IP (XPF) and the stub client address (ECS).

DW

---

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

On 06/01/2017 22:20, Richard Gibson wrote:

> Why not use Address Family like EDNS Client Subnet

Robert Edmonds and I already had that discussion off-list :)

This option isn't intended to carry transport addresses that a DNS
server couldn't already handle for itself.

As it is, ECS only allows two possible values in its *16 bit* Family
field, those being of course the values designating IPv4 and IPv6.  If
I'd been paying more attention to ECS I would have objected to this
pointless over-specification.

> Why /wouldn't/ ECS work for this? If the idea is to expose everything
> obscured by a proxy (e.g., for backend logging), then the option data
> should include quite a bit more than an address—at minimum, a
> protocol number for differentiating UDP/TCP, the original OPT CLASS
> (UDP payload size) and flags (including DO), and a flag indicating
> presence or absence of an OPT record in the original query. You might
> also want to include the port and id from the original query (for
> direct response) and/or allow arbitrary data after the address (for
> communicating installation-specific metadata).

The intent isn't to expose *everything*.  It's to expose specifically
the one value that (most) servers care about because it's used by things
like ACLs, and views, and rate limiting - the client source IP.

kind regards,

Ray