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

["Martin Thomson" <[e-mail]>]

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.
 
> > For connection-oriented interactions, having the information associated with a connection (and not a server identity) would be even better.
> 
> Not sure what you mean by "connection-oriented interactions". DNS is 
> not connection-oriented at all.

Neither is HTTP, but it uses connection-oriented interactions: TCP connections.  There is still a strong desire in HTTP to retain the stateless nature of the protocol, but we have cracked that open slightly.  Building some ability to talk directly to the next hop in a limited fashion, as we are now able to with HTTP/2, has some real benefits.
 
> > 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.

> If the WG finds this to be too much of an edge case, we can certainly 
> eliminate the inventory, but it feels to me that requiring that every 
> response always contain every known name-value pair is onerous.

The sort of filtering you are contemplating isn't supported by the protocol you define.  It's also quite a bit more complicated to specify and build.  If there is a need for subdivision for performance reasons, which would have to be proven, there might be better ways to approach this.