Subject: Re: [DNSOP] New draft, seeking comments: draft-sah-resolver-information

From: Puneet Sood <[email-masked]>
Date: Thu, 2 May 2019 10:23:13 -0400

On Tue, Apr 30, 2019 at 5:17 PM Erik Kline <[email-masked]> wrote:
>
> Can I ask why you went with resolver-info.arpa instead of <rev-ip>.{in-addr,ip6}.arpa of the resolver IP to which the query is being issued?  I think the temp-field2.<stuff> trick still works, and maybe we could get DNSSEC validation (IDK about dnssec validation in the rev-ip .arpa space).

It's an interesting idea to get DNSSEC validation for the resolver
responses this way. It is probably impractical because the
resolver-info.arpa zone is a SUDN and resolvers do not necessarily
have support for doing DNSSEC signing themselves or securely
downloading pre-signed records. Others on the list likely have an idea
if this is feasible for some deployments.

-Puneet

>
> On Tue, 30 Apr 2019 at 14:10, Paul Hoffman <[email-masked]> wrote:
>>
>> [[ GAAAAH. The abstract of the draft says it should be discussed on the ADD list. That's wrong, it belongs here. ]]
>>
>> [[ GAAAAH2. I didn't include the draft info.
>>         Title           : DNS Resolver Information Self-publication
>>         Authors         : Puneet Sood
>>                           Roy Arends
>>                           Paul Hoffman
>>         Filename        : draft-sah-resolver-information-00.txt
>>         Pages           : 9
>>         Date            : 2019-04-30  ]]
>>
>> Greetings again. Puneet, Roy and I have just published a -00 with an idea for how to get information about a recursive resolver from the resolver, if it wants to give that information. This is an outgrowth of my earlier work in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on that latter draft in Prague had a couple of people saying "this should be more general than just DoH" and "what about DoT", which sparked the idea for draft-sah-resolver-information.
>>
>> Note as you read this document that we have *not* started filling in the kind of information that a resolver might return; we haven't even specified the DoH stuff. We wanted to be sure that DNSOP folks thought that the direction here might be viable; if so, I'll write an associated draft for a resolver's associated DoH and DoT servers, and some of you might start writing drafts for other ideas.
>>
>> Also note that this is explicitly only for resolvers; we might later do a second protocol for authoritative servers who want to give information about themselves (such as if they do DoT, if that moves forward in DPRIVE). The reason for the split is that a resolver that doesn't know the protocol here might pass the query on to the authoritative servers for the root or .arpa, and the response to the stub would then be ambiguous.
>>
>> We look forward to your bashing and/or support.
>>
>> --Paul Hoffman
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 2 May 2019 16:59:38 -0400

>	Filename        : draft-sah-resolver-information-00.txt

Having now read it, I sympathize with its goals, but it's two separate
things lashed together.  One is sort of the 21st century version of
the old CH version.bind hack, ask the server a special funky question
and it tells you about itself.  The other is a well-known URL on a web
server at the same IP address as the DNS cache.

Both have issues -- the DNS approach is a dns-camel hack and there's
no obvious way to sign or secure it.  The web page is straightforward
give or take practical issues of running a web server on the same IP
as a DNS cache, and that getting a signed SSL certificate for an IP
can be from moderately to extremely painful depending on your budget,
the difficulty of doing an OV validation on your organization, and
your relationship with the RIR contact for your IP address.

I believe that DoT and DoH have the same certificate issues as the web
server.  I suppose you could find your DoH server by name, but if you
can do that, you could equally well find your DoT or .well-known
server by name and define the problem out of existence.

My inclination would be to put this on hold and advance the web server
part if ACME adds a way to do IP address certs.  I don't see any
reason to prefer DoH or DoT over .well-known, since it uses same TLS
channel and has a much simpler encoding of the content.

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 3 May 2019 14:41:38 +0200

> server by name and define the problem out of existence.

I think it's best to verify by name, even if the DNS server is reached
through a hard-configured IP.  That's what we implemented for Knot
Resolver, at least.  On a related note, I'd also expect to send the name
as SNI by default; 8.8.8.8 was not even sending me a certificate unless
I sent SNI (only when using TLS 1.3 though)

--Vladimir

---

From: "John R Levine" <[email-masked]>
Date: 3 May 2019 11:51:33 -0400

> I sent SNI (only when using TLS 1.3 though)

When I said verify by name I meant by DNS name, so the certs can be signed 
by the existing ACME protocol or whatever.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Vladimír Čunát <[email-masked]>
Date: Sat, 4 May 2019 10:52:39 +0200

On 5/3/19 5:51 PM, John R Levine wrote:
> When I said verify by name I meant by DNS name, so the certs can be
> signed by the existing ACME protocol or whatever.

I also meant verification by DNS (host)name in certificate's CN, signed
by some commonly accepted authority.  I don't know where the
misunderstanding is.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Sat, 4 May 2019 15:13:06 +0300

On Wed, May 1, 2019, 12:10 AM Paul Hoffman <[email-masked]> wrote:

> Greetings again. Puneet, Roy and I have just published a -00 with an idea
> for how to get information about a recursive resolver from the resolver, if
> it wants to give that information.
>

The draft assumes that both the recursive resolver and the stub resolver
must be updated to support this. IMO it is safe to go one step further and
just also assume that both updated resolvers also support DoT, and the
concerned stub resolver should then use it to connect to a resolver if the
latter is nowhere to be found in RFC 6890.

Otherwise you would probably have to assume that all the middleboxes are
also updated to support sudden JSON in the RESINFO responses without simply
dropping it as e.g. likely malware-ish, or just suspicious. And then those
middleboxes would also probably want to take part in the game which would
also mess things up.

--
Töma

---

From: "John R Levine" <[email-masked]>
Date: 4 May 2019 12:22:32 -0400

> by some commonly accepted authority.  I don't know where the

Oh, OK, it sounded like you would ask for SNI for an IP.

Google's servers are inconsistent.  When I connect to 8.8.8.8 it's OK with 
no SNI, but 8.8.4.4 wants an SNI host name, not an IP.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 6 May 2019 16:41:22 -0000

In article <[email-masked]>,
>channel and has a much simpler encoding of the content.

Here's a further thought.  After poking at a bunch of public DoT
servers including 1.1.1.1, 8.8.4.4, 8.8.8.8, 9.9.9.9 and lesser
known ones like 89.233.43.71, I find that most of them return
a signed cert for a name that resolves to the appropriate IP.

If you think there is likely to be a critical mass of clients that
find their DoT or DoH server by name, or that have external knowledge
of what the name should be for a server found by IP, it could make
sense to advance the .well-known part, with a security note that
you only get the validation part of TLS if you know the name or
you're in the elite few who can get a signed IP address certificate.

This could still work for servers on private IPs, since it's not hard
to get a signed certificate for a public name that doesn't resolve
to a public IP.  (The public name doesn't even have to be in the DNS
other than for two minutes while the signer checks it.)

I still think that the new RR with funky names is a bad idea, a lot of
complexity that offers the same info that .well-known does.

R's,
John

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly