Moin!
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.
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?
- 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.
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.
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.
So long
-Ralf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
