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 _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
