Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt

[Erik Kline <[e-mail]>]

On Tue, Oct 29, 2019 at 6:10 PM Ben Schwartz <[e-mail]> wrote:

>
>
> On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters <[e-mail]> 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?
>

But this sounds more like you want to lookup RESINFO for resinfo.arpa with
some DNS hop count decrementing and get back a CNAME to the rev-addr
RESINFO record.

I don't know how we do DNS hop count decrementing, but it could be done by
convention (i.e. "0.resinfo.arpa", "1.resinfo.arpa", "2.resinfo.arpa",
...).  (But still, it just sounds like want you want is somewhat orthogonal
to/separable from what's discussed in this draft.)