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

[Ben Schwartz <[e-mail]>]

On Tue, Oct 29, 2019 at 9:32 PM Erik Kline <[e-mail]> wrote:

>
>
> 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.
>

That sounds pretty complicated.  What's the benefit over just serving
RESINFO on resolver-info.arpa?

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.)
>

FWIW, I think reverse-IP is just the wrong conceptual model here.  The stub
isn't asking abstract questions about the recursive resolver on some IP
address; it's asking for info about its current resolution setup.  I
mentioned RFC 1918 addresses as one case where this is clear.  For another
case, consider a recursive resolver whose behavior depends on the client IP
(e.g. OpenDNS filtering policy
<https://support.opendns.com/hc/en-us/articles/227988047-Web-Content-Filtering-and-Security>).
If filtering policies were encoded in RESINFO (as has been proposed), I
would expect OpenDNS's RESINFO response to depend on the exact client IP.
If you make this reverse-IP RESINFO query through a recursive resolver,
you'll get the wrong answer.  That's a _really_ weird RR.

Really, the whole concept of a QNAME doesn't apply to RESINFO, but unless
we start a new QCLASS I think hardcoding the QNAME to "resolver-info.arpa."
is about as good as we're likely to do.