Re: [DNSOP] [Ext] Call for Adoption: draft-sah-resolver-information

[Joe Abley <[e-mail]>]

On 4 Aug 2019, at 21:00, Martin Thomson <[e-mail]> wrote:

> On Sun, Aug 4, 2019, at 00:37, Paul Hoffman wrote:
>>> I think that I might have said this before, but I don't think that asking an HTTP server about a DNS server is the right solution.
>> 
>> It is not "the" right solution, but it is one of them. That's why there
>> is also a DNS-based solution in the same document.
> 
> Let me be slightly more pointed then.  I think that documenting a solution that has one protocol speak for another would be a bad idea.  Even if there is a better way to do the same thing in a "better" way.

and

>>> The RESINFO RRtype seems OK, but I have less confidence in my ability to assess that aspect of this.  The only thing that bothers me is the potential for 1.0.0.10.in-addr.arpa and friends to leak and ruin the protocol for everyone.
>> 
>> Please say more here. Who do you think would be publishing at 10.0.0.1?
> 
> A good proportion of the resolvers I talk to operate from 1918 space, how else would they advertise this information?  I don't care if they are merely proxies, and nor should it matter if they are.
> 
> The fact that they are proxies means that my ISP is likely going to be the one fielding RESINFO queries for 10.0.0.1 and friends.

together also trigger discomfort for me. DNS and HTTP requests might generally follow the same gradient as far as network address translation goes (escaping to ever-shallower NAT domains) but it's worth remembering that the gateways between the layers are not always just gateways at the IP layer; some are ALGs. The addresses that services are reachable at can can change between layers, as (in general) do the addresses used for proxy requests in the case of ALGs.

I'm concerned about the cases where:

(a) the data enclosed within a RESINFO response includes embedded IP addresses that may not match the addresses that correspond to the resolver service as viewed from another addressing domain, and

(b) the potential for HTTPS and DNS ALGs to further confuse matters as the system generating the RESINFO response for one retrieval protocol might not be the same as for the other.

I realise it's tempting to imagine that HTTPS is not subject to explicit or implicit handling by ALGs; however, anecdotally at least, SSL-stripping (e.g. with jurisdiction-specific trust anchors installed on clients) is on the rise and not just in enterprise networks. I've also seen networks where traffic is routed by policy in different directions according to transport-layer addresses, e.g. for reasons of available capacity or latency.

So I echo the concern about having one protocol speaking for another. I haven't quite got my head around what I think about RESINFO in general but this particular aspect seems like a more general weakness that is worth highlighting.


Joe