On Tue, Oct 29, 2019 at 7:04 PM 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. >
The concern here is not "simplicity" as such. The main concern is the large fraction of devices whose configured DNS server is actually a forwarder (usually with an RFC 1918 address). Even if the actual recursive implements RESINFO support, these devices will not be able to retrieve the information, because they won't be querying the reverse address that the recursive resolver thinks it owns. This can be solved if the forwarder implements some sort of RESINFO query rewriting, but it certainly won't work for the existing install base. I think this is the crux: should the upstream RESINFO be available through a naive forwarder, or only through a forwarder that actively works to support RESINFO? I prefer the former, because I think serving the existing install base is worthwhile. I don't see significant value in DNSSEC for this application, because an adversary who can forge DNS responses (the DNSSEC adversary) can also forge DNS configuration messages (DHCP or RA). What good does it do me to prove that 1.2.0.192.in-addr.arpa is authentically publishing this RESINFO, if the attacker forged the DNS configuration message that said 192.0.2.1? > Paul >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
