> On 29 Oct 2019, at 23:04, Paul Wouters <[email protected]> wrote:
>
> On Tue, 29 Oct 2019, Neil Cook wrote:
>
>> FWIW, I've previously stated a preference for dropping the use of
>> ".well-known" entirely, and using draft-00's "resolver-info.arpa" name
>> instead of reverse-IP, in order to improve support for
>> passive forwarders. I understand this was changed in the hope of
>> offering some kind of security here with DNSSEC, but I think it's unlikely
>> to work in practice, and we're better off keeping
>> things simple.
>> I completely agree. I’d much rather see something like "resolver-info.arpa"
>> instead of reverse-IP.
>
> Throwing DNSSEC under the bus for a "simpler" name seems rather
> excessive. I for one would like to see DNSSEC in the reverse
> support when possible. For a future where not everything is
> chained to a single all-powerful LetsEncrypt root CA.
>
I’m certainly not against DNSSEC per-se. I do question what it’s actually being
used for in this situation and if it could actually work the way it is
currently specified. I’ve included my original comments on this below:
- For the DNS method, given that a resolver never knows if DNS proxies are
being used (in CPEs or elsewhere) or indeed what IP addresses are being used
behind those proxies, I would imagine that at a minimum it would need to answer
RESINFO queries for *all* RFC1918 addresses. This does then lead to the
question, why include the IP address in the query at all? I assume the answer
is “DNSSEC”, but see below for some more questions/comments on that.
- There is an acknowledgement "Erik Kline suggested using
"<reverse-ip>.{in-addr,ip6}.arpa" as the
domain name to allow for the possibility of DNSSEC-signed responses.”
I think it’s worth noting that RESINFO queries for private IP addresses will
never be able to generate DNSSEC-signed responses. Also given the restriction
"Authoritative servers MUST NOT answer queries that are defined in this
protocol.” it seems unlikely that many resolvers would be capable of generating
DNSSEC-signed responses, especially given that resolvers and authoritative
servers tend to be completely separate entities these days.
This also begs the question, why create that restriction at all? Why must
Authoritative Servers not answer those queries? The draft also states that "if
the resolver can be configured to also be authoritative for some zones, it can
use that configuration to actually be authoritative for the addresses on which
it responds.” Which seems to contradict the previous MUST NOT - surely this is
an implementation detail that should not be mentioned in an IETF draft?
Neil
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
