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

Ben Schwartz <bemasc@google.com> Wed, 30 October 2019 02:01 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C70D12009E for <dnsop@ietfa.amsl.com>; Tue, 29 Oct 2019 19:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I395Zonjx32v for <dnsop@ietfa.amsl.com>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BD9120059 for <dnsop@ietf.org>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
Received: by mail-il1-x130.google.com with SMTP id t5so684732ilh.10 for <dnsop@ietf.org>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d9xzSBjGl9WmZmu94qYKHjeP6QP2Z9HoCkfijPJH6Mk=; b=OOyzs000ayaP9vO6siQKKOWdT8WFnshcKbCvVVqV3Mcc/mbGXMsUuA2MY0bKgKtrRm D3U/MxU1odDBoMpzQDyoV4VxCU7ONJEvum/+HWCE6qWN/N9H3Wrm3BPHZui4d5um7Hh8 Oc+i+pgg9BK4F3RzBtQcKbZB8HZ1iXzOKPaPcTsD2hYL3q+K0cCObSIlojbxysxHjHVL 2+66kGJBlkAqBcCKARfgpNTx1fRs7/coEyq+W64UvKXmXxF0FIORcQ3B1y7PWA62FokM nVTwDLkHoAPo2YsJffW/Sq+ms8YY7qjWzen5Da84du2zibO6gcWM4tQzu/WRSUFW7CGi /EVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d9xzSBjGl9WmZmu94qYKHjeP6QP2Z9HoCkfijPJH6Mk=; b=Pqf67iX6vN1Dv1anXhQCv/GRenyeGykpJg/9Iym05HhbSJVeRJPd/0iQYvU9WEklyQ +MzlZEn9GY4jUX6DZSMZjJQ6CsYEotwc8oxHe649Vyo8363MyR0ytmfoF+pD0xQacDFs iGRMRUKMDoL3P06Qt2ZpOUOL4puNlNdlJXSo2lLE4HM8RbSfInfbpmvJyl9RscmDh6il YzBs2KEXFNCKqK6gLQEpsay2Cv4RC0FG2vFHX0n2FWW7hcSv3oh52LoPb3NI+JWBm4lN +PxKuGmn+Em3uT+9LcFg+yaCwg7AYX5iMGmrcl0qJdqDtRjli7WMl1GKvfqIBCfQJl4g ZQEg==
X-Gm-Message-State: APjAAAU8kOBIssEgOshdTM9+r2hdI3+WkNeIr7GHO15fXclcN2+Ck+4z q2UiRrls8rKcBzF2jk+KyQsEq1Zy7DT+qYfA6SbJmQ==
X-Google-Smtp-Source: APXvYqyQYEE5cCwIP+NWbo9j7EBB4VPtHLNP7+tqmVPKTGnYqS84Jfk27/7Z4Fg4OJZY+5q8kOj6kt2fBtcnCWEHmAo=
X-Received: by 2002:a92:4a06:: with SMTP id m6mr26418385ilf.153.1572400898065; Tue, 29 Oct 2019 19:01:38 -0700 (PDT)
MIME-Version: 1.0
References: <156624288737.19884.5252170663574668911@ietfa.amsl.com> <A8482079-FC91-414D-B0EF-E016606E9093@noware.co.uk> <34CACD4F-554A-4736-BD53-36D980B5A5A5@noware.co.uk> <CAMGpriWD_dOADk4=OKFzVZn8KT9RC_A1v3jQDq6oDLuRB3K9yg@mail.gmail.com> <CAHbrMsCng7tG=qNjDv23xzRU+_-_QD-4a_NvKzGDAHmGO4PA5Q@mail.gmail.com> <54A6311E-E688-4357-AC14-8A9ACBC1D6FF@noware.co.uk> <alpine.LRH.2.21.1910291903230.1249@bofh.nohats.ca> <CAHbrMsD3mpb_DbMm1s9J=fp1u_YEoJfiQRDM5LugAKu-9ph7bg@mail.gmail.com> <CAMGpriWDj9RkdL_5-i_6syqdY2xgwEDLQBgkPX=Y_Ke0Ghbi4g@mail.gmail.com>
In-Reply-To: <CAMGpriWDj9RkdL_5-i_6syqdY2xgwEDLQBgkPX=Y_Ke0Ghbi4g@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 29 Oct 2019 22:01:26 -0400
Message-ID: <CAHbrMsCaUd2mxbarrUatZKgeF+2Tn8C_8gH=vk+TbqG+1SHwaA@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
Cc: Paul Wouters <paul@nohats.ca>, Neil Cook <neil.cook@noware.co.uk>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000001d3f30596171de9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ru7PMthiV7hhHtPS3KHlezTU-rY>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 02:01:42 -0000

On Tue, Oct 29, 2019 at 9:32 PM Erik Kline <ek.ietf@gmail.com> wrote:

>
>
> On Tue, Oct 29, 2019 at 6:10 PM Ben Schwartz <bemasc@google.com> wrote:
>
>>
>>
>> On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters <paul@nohats.ca> 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.