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

Paul Hoffman <paul.hoffman@icann.org> Wed, 15 May 2019 21:30 UTC

Return-Path: <paul.hoffman@icann.org>
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 874C11200FD for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 14:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 EN3N3WfK1jhI for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 14:30:02 -0700 (PDT)
Received: from mail.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF6831200D8 for <dnsop@ietf.org>; Wed, 15 May 2019 14:30:01 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 15 May 2019 14:30:00 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Wed, 15 May 2019 14:29:59 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Paul Wouters <paul@nohats.ca>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [Ext] [DNSOP] New draft, seeking comments: draft-sah-resolver-information
Thread-Index: AQHVC2VZMmzxRAq6CkyF8T969C11OA==
Date: Wed, 15 May 2019 21:29:59 +0000
Message-ID: <C3668C33-E3DB-4267-AF5B-FDC46262CC8F@icann.org>
References: <3BCCE28D-17C6-4367-A9C3-D0DCF56AB03A@icann.org> <alpine.LRH.2.21.1905151256480.22294@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1905151256480.22294@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <EB57A88C15376A419C09F899984B8998@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zcTHTbjCkwWA8tY1VLWnpYbBi70>
Subject: Re: [DNSOP] [Ext] New draft, seeking comments: draft-sah-resolver-information
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, 15 May 2019 21:30:04 -0000

On May 15, 2019, at 1:23 PM, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Tue, 30 Apr 2019, Paul Hoffman wrote:
> 
>> 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.
> 
> I don't understand why you create a specific RRtype with "information to
> be filled in by other documents", yet feel the need to have one for
> resolvers, maybe another one for authoritative servers,

See above. If a stub asks a question for its resolver, it should get answers for that resolver or an NXDOMAIN. The stub should not need to use heuristics to determine if the answer was actually from the root zone, or from the .arpa zone.

> and kind of
> combine "resolvers that could offer signed responses in their
> forward zone" together with "random unknown resolvers that cannot
> offer signed responses about their capabilities".

Because we cannot force anyone to sign their zones.

> I would prefer a generic "DNSINFO" that can be used in the forward and
> the reverse, and can contain resolver and authoritative properties.

Wouldn't that inherently be more complicated than two different RRtypes, each of which has precise semantics?

>   if the resolver can be configured
>   to also be authoritative for some zones, it can use that
>   configuration to actually be authoritative for "resolver-info.arpa".
> 
> This is misleading. No one but AS112 or the arpa. TLD nameservers could be
> really answer "authoritative".  Others would just pretend to be and lie.
> And really, you would want google to put this info into in a forward zone
> "dns.google.com" and not limit RESINFO (or DNSINFO) to the reverse zone.

Agree. There was a suggestion that we instead use <reversed-address>.in-addr.arpa, and that sounds like a better suggestion.

>   For example, if the stub knows that it
>   wants information whose name is "temp-field2", it would send the
>   query temp-field2.resolver-info.arpa/IN/RESINFO.
> 
> I can see why you might want this, to allow for smaller return answers
> when the stub only cares about one of many pieces of resolver infomation
> that might be available, but it oddly puts DNS naming constrains in that
> information ?

Yes, exactly.

> It also opens up pandora's box of IDN support.

Good point. We will restrict the names in the name-value pairs to be LDH characters.

> 
>   Any query for the RESINFO RRtype that is not in resolver-info.arpa/IN
>   or a subdomain of resolver-info.arpa/IN is meaningless and MUST
>   result in a NODATA or NXDOMAIN response.
> 
> Do you expect this policing to be enforced in code? I think that's
> naive. Anyone who is not implementing this will treat is as a generic
> record and just relay it back. So it is bound to be violated. I wouldn't
> bother trying to police this. Also, I think there are valid use cases
> for RESINFO in the forward, eg if I have dns.nohats.ca on my owned IP
> as the resolver, so I can give you DNSSEC authenticatied answers.

Yep. This reinforces the proposal for <reversed-address>.in-addr.arpa.

> 
> 	3.  Retrieving Resolver Information by Well-Known URI
> 
> You offer a non-DNS method that can deliver (channel) authenticated
> answers, but you don't allow DNSSEC (data origin) authenticated answers?

Agree. Thus, the change to <reversed-address>.in-addr.arpa.

> 
>   A resolver that uses this protocol to publish its information SHOULD,
>   if possible, have a TLS certificate whose subject identifiers are any
>   IP address that the resolver is available on
> 
> Again lifting TLS over DNSSEC ?

Agree. Thus, the change to <reversed-address>.in-addr.arpa.

>   If the request was over DNS using a subdomain under resolver-
>   info.arpa, the resolver SHOULD return an object that contains a name-
>   value pair with that name if the resolver has that information.  If
>   the resolver does not have information for that name, it MUST NOT
>   returen the name in the object.
> 
> So what should it return? The options are 1) nothing or 2) all and the
> document should clearly specify which of the two is allowed and which is
> prefered.

The answer is in the body of the document: whatever it wants, as long as the returned object contains "inventory".

> 
>   If the request was over HTTPS, the resolver SHOULD return an object
>   with all known name-value pairs for which it has information.
> 
> It is a little unclear whether this is part of the "a specific name was
> requested" case.

The design has no defined way to use an HTTPS request to request a specific name-value pair. This is to make the URI definition easier.

> And if the rules above for DNS/subdomains apply here. I
> think the authors are implying that HTTPS is so expensive in overhead
> and has no packet size issues, you might as well always return
> everything. If so, just state that more clearly.

It was not about expensive, it was about expressiveness.

> 
>   All names in the returned object MUST be defined in the IANA registry
>   or begin with the substring "temp-".
> 
> IETF tradition is to use a x- or X- prefix for this kind of thing. Why
> now use "temp-" ?

See BCP 178 (RFC 6648).

>      "inventory": [ "inventory", "temp-field1", "temp-field2" ]
> 
> I'm not sure how useful "inventory" is. It cannot be trusted anyway, so
> I think if I would write code for this, I would just completely gnore it
> anyway.

What do you mean by "trusted"?

>   The specification that is required for registration can be either an
>   Internet-Draft or an RFC.
> 
> I'm a little uneasy with this. If the draft is moving forward and we do
> an Early Code Point, that is fine. If it is a batshit crazy draft that
> will never get RFC status, it should not. You can see the Expert will
> handle with this, but sadly this text is followed by:
> 
>   The reviewer for this registry is
>   instructed to generally be liberal in what they accept into the
>   registry: as long as the specification that comes with the
>   registration request is reasonably understandable, the registration
>   should be accepted.

Proposed text for an alternative that is still liberal would be great.

> Also, for those who would like to use DNS queries, size does matter.
> 
> What to do if the inventory is too large for a DNS reply.

DNS replies can be arbitrarily large.

> What are the
> rules for choosing which content to include or not? Or are you expecting
> a truncated response and a TCP retry? There should be text about this.

This is normal DNS response handling.

> 
> 	6.  Security Considerations
> 
> It does not talk about putting this information in the forward zone
> of a named resolver (eg dns.nohats.ca) that can use DNSSEC to protect
> this information.

Agree. This will be handled better in the next draft.

--Paul Hoffman