> On Aug 2, 2019, at 8:35 PM, Martin Thomson <m...@lowentropy.net> wrote:
>
> On Sat, Aug 3, 2019, at 01:04, Tim Wicinski wrote:
>> This starts a Call for Adoption for draft-sah-resolver-information
>
> 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.
> If this is information about the operation of a participant in the DNS
> protocol, then I think that this needs to use the DNS protocol.
Agree. See above.
> 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.
> This also bakes in the notion that a DNS resolver is identified by IP
> address.
Not at all: the resolver must have an IP address, but can also have a domain
name. In the case of an application that is doing it's own stub resolution, the
stub could use the OS's stub to get the address of the resolver's domain name.
Such an application-based-stub could then use all of its own HTTPS-based
security policies to get the resolver's information.
> The domain name part is probably OK, but I don't know which trust anchors to
> use. I think that the document is assuming that we'll use the Web PKI, but
> it doesn't say that (nor does RFC 8310, as far as I can tell).
The TLS and HTTP2 documentes also don't say which trust anchors to use. :-)
> If you can answer the question "why not DANE?" then you might start to
> understand my concerns here.
Allowing the use of a domain name in an environment where DANE is used is
exactly one intended use case.
> 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?
> I realize that there are no good solutions here, but it would be good if
> there were a little more clarity on the constraints this group thought
> applied to the design.
Sure.
> The inventory thing is fairly irregular. The names of fields are right there
> already, why insist on repeating them in an array?
The document says that the response does not need to include all the name-value
pairs that a resolver knows. The use case is that someone might define a
name-value pair that they only want to emit if asked for, such as if the data
is large.
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.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
