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

Ben Schwartz <> Wed, 30 October 2019 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C70D12009E for <>; Tue, 29 Oct 2019 19:01:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.499
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I395Zonjx32v for <>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22BD9120059 for <>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
Received: by with SMTP id t5so684732ilh.10 for <>; Tue, 29 Oct 2019 19:01:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 29 Oct 2019 22:01:26 -0400
Message-ID: <>
To: Erik Kline <>
Cc: Paul Wouters <>, Neil Cook <>, dnsop <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000001d3f30596171de9"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Oct 2019 02:01:42 -0000

On Tue, Oct 29, 2019 at 9:32 PM Erik Kline <> wrote:

> On Tue, Oct 29, 2019 at 6:10 PM Ben Schwartz <> wrote:
>> On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters <> 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 "" 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
>>> "" 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 is authentically publishing this RESINFO, if
>> the attacker forged the DNS configuration message that said
> But this sounds more like you want to lookup RESINFO for 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

I don't know how we do DNS hop count decrementing, but it could be done by
> convention (i.e. "", "", "",
> ...).  (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
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 ""
is about as good as we're likely to do.