On Jun 30, 2019, at 1:08 AM, Ralf Weber <[email protected]> wrote: > On 30 Jun 2019, at 1:01, Paul Hoffman wrote: >>> - The draft offers two methods of retrieving the object but says nothing >>> about which is mandatory (Me being a lazy DNS geek will certainly not put a >>> web server on my DNS server so won’t implement 3). Will it still work? Why? >> >> Neither is mandatory: both are optional. That is, we cannot force a resolver >> to give information about itself, nor can we force it to do something >> abnormal for a resolver (be authoritative for a new type of query or run a >> web server). > Sure you can not, but as we have seen with RFC8484 deplopyment where browser > vendors can say, oh if you don’t speak this (our language) we will just go > around you and talk to someone else. I want to avoid that situation in > discovery. So we have to give the client of such a protocol clear guidance on > what to do. IMHO try both ways and only if none work go back to your fallback > scenario. That is missing in the draft.
I don't see the parallel with RFC 8484. We cannot force resolver vendors to care enough about announcing information about themselves to use either protocol. And we certainly cannot tell applications how to search for information. We can, however, offer options that either can use. >> The name doesn't need to be in the config of the DNS part of the resolver: >> it would only appear in the TLS part, just as it does in every web server >> that supports TLS. > That does make no sense. Where does a client of discovery get the name from? > All stub resolvers I know only have the IP configured and not a name. Can you > explain where the name for such a call would come from? Current DHCP only offers information on resolvers by IP address, but that doesn't mean that no future version of resolver discover would not, particularly in situations where an OS or application already has one resolver and wants to get to a different one. That is, there is no reason not to add this as a potential for the future. >>> - The biggest issue IMHO are RFC1918 and IPv6 link local addresses as these >>> are mostly used in homes for DNS resolver addresses. This means that the >>> CPE - who usually is a DNS Forwarder has to answer (and understand) this >>> query and either forward or answer by himself. DNS Proxies might not >>> implement RFC3597. >> >> If a resolver of any type can't be configured to give the information here, >> it just won't. > Again the problem are the consequences when it doesn’t. Which might happen > because even though the ISP resolver has configured the RESINFO record it > simply might not get the query if it is ignored by the proxy on the CPE the > customer has bought, because of type. Are there words we could add to make this clearer? I ask because I still don't see how your concern can be dealt with in the protocol. >>> Should there be a fallback (TXT)? >> >> I'm not sure how that would help if it can't be configured due to address >> issues. > DNS proxies can forward stuff and you could put wildcard answers on the link > local/RFC1918 addresses. So you could actually make it work. But the > likelihood of being able to forward TXT are bigger then the likelihood of > being able to forward RESINFO, thus my question for fallback. This surprises me. There are forwarders that only forward requests and responses based on the RRtype? > In general I don’t like the idea of traversing the reverse tree for that as > we can not validate it in a lot of use cases anyway and the information we > want is rather static and does not necessarily appear in the global DNS as it > is first line resolver specific. Understood, but people objected earlier to our use of a special-use domain name that could not have DNSSEC signing. If we want DNSSEC signing, we have to use the DNS reverse tree for the names, even though only a tiny percent of that tree will be signed. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
