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

Erik Kline <> Wed, 30 October 2019 01:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34B61120128 for <>; Tue, 29 Oct 2019 18:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 q5xZf6BLnXdH for <>; Tue, 29 Oct 2019 18:32:55 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3E4D912003E for <>; Tue, 29 Oct 2019 18:32:55 -0700 (PDT)
Received: by with SMTP id y8so422796edu.5 for <>; Tue, 29 Oct 2019 18:32:55 -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=UVnm8Xgb/EcEfwK201dSdNytvyy3bjOlapGG0dupL7I=; b=DLzaRy9SHvJga+ZYNqK6ft3vjfa4oZlpif/BqucoY5IhUbNdXPrW2grjBlIUFXXpA4 /HaqmasEhoW0xcLCksfSwKWJtpIAJ70eMWklc1qATCvR8ku6mAtCtv9duzOBXoj7zBQ6 O2Zsxyabb5St43rJXXAxkVLG6F5G/4IkaHWUW97iTrnNKvtHYKn2xVdq+AeSoAZFA7HV CbGlepTonZhvlmEViURvSzuRfqKbBW+pIR8qziALe+XL0L49nvybJFyUfJ8lZWMuwO6g 23WxQizxqfJK7rrX6g8ffz+dTX4/rs44H3sPF6N+y0IxvXm2eljUJvpnp/sKK8WetPfp OCQQ==
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=UVnm8Xgb/EcEfwK201dSdNytvyy3bjOlapGG0dupL7I=; b=RAuFPTLnbkfQRJLeovp+Jz41rJKUVBXFxY/9fqf5kqd8M8g7+lJhXiLk3jYs1DsUkD 1arJrCBy5FN1xkuAvZ/FObkgvbC1LAeNqDOdBRncneh/FYcD8ca0nGzn6g91MqQ8h0Bu pkgcEiyNR4kaw4TVZVloPgDndiXytryEVjTcl1SVIxZ7N6RxTK7jpXb7GrKLEOuYhP9X NWBPBUGt27GqXxZMf2fHAz+RDlLIvM8iQg6FsPwLP+spcNSVmUD0hx3voS7i8M+z0+bs FWCHotXV/oB+z2XZdRF9MUj5m6DsC4neWGdosj2EHEyqKcdE+jwWfMguv4VSrSJKQvJq Pwyw==
X-Gm-Message-State: APjAAAX3g0dAJEnCZZ9kK6IER2V26hT1JpHdfvQmlLl/ohglxYvhdZjh SZz5Z0CiFlpa2xw9q1YcNt2/RX7EGIpWO32Z7N0=
X-Google-Smtp-Source: APXvYqxsQgvdMRjdMYbSdxbllRYHzaCw4bkBiKlkQCF5D2ZNDWliHwbGjvCe2Mwbh2vAG+tVzxL3Y4nKwN+TDbMTmN8=
X-Received: by 2002:a17:906:118d:: with SMTP id n13mr6290091eja.229.1572399173825; Tue, 29 Oct 2019 18:32:53 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Erik Kline <>
Date: Tue, 29 Oct 2019 18:32:42 -0700
Message-ID: <>
To: Ben Schwartz <>
Cc: Paul Wouters <>, Neil Cook <>, dnsop <>
Content-Type: multipart/alternative; boundary="0000000000003377e4059616b61f"
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 01:32:57 -0000

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.

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