Moin!
On 4 Jul 2019, at 2:40, Paul Hoffman wrote:
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.
Of course we can. If we define a discovery protocol for secure DNS we
can define what a discovery client has to do. If we don’t do this it
will cause problems. Say if from the draft resolver vendor N implements
section 2 and browser vendor M implements section 3, both have
implemented the protocol still it won’t work together.
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.
Hmm a name as entry point for a name resolution protocol - ok maybe some
future engineers come up with something but until we should say that
current protocols don’t support it explicit and not implicit as it
will confuse people.
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.
The fallback to TXT or some other way to get to the resolver IP to ask.
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?
Well I saw this in the early days of DNSSEC deployment where a proxy
(which is a forwarder, but dumber) did forward A, AAAA, MX, TXT, NS,
etc. but not DNSKEY or any query type he did know nothing about. As we
are defining a new query type this problem might surface again, thus the
proposed fallback to txt or some other mechanism to work around the CPE
at the customer site. I liked the idea of the earlier draft where there
was a special name to get to the IP of the resolver.
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.
Well DNSSEC signing might work with the proper resolver signing reverse
for RFC1918 which is a very common case will not work.
SO long
-Ralf
—--
Ralf Weber
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
