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

Paul Wouters <paul@nohats.ca> Thu, 16 May 2019 03:19 UTC

Return-Path: <paul@nohats.ca>
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 2B650120086 for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 20:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 JtEU-P3b9ksK for <dnsop@ietfa.amsl.com>; Wed, 15 May 2019 20:19:11 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4B71200F9 for <dnsop@ietf.org>; Wed, 15 May 2019 20:19:11 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 454GqJ42r0z1c3; Thu, 16 May 2019 05:19:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1557976748; bh=AaUIfJYe9DI+pk8mVkRhElgQ2BBdXZb+MbFQnFAexj4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KzxhCgwErg/bttpwwezTMLUNCvDtDbLCXEtVEKsg5ZOLsVkiBSZF8mgQ1b2v1Dt1j 0ooS5QxRPL/aOtbmzXUUbLhuB5oSZvXjSUADfXuBFOc3DUrexjCaQFBA0e0jyBUfxR Mcgp/IJc+YNocaV4128PuiQ/9WCxqbi+qIcuk6fI=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Hsy1MdEA6dWh; Thu, 16 May 2019 05:19:06 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 16 May 2019 05:19:05 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2873C61D86; Wed, 15 May 2019 23:19:04 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2873C61D86
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1D87A4146EA1; Wed, 15 May 2019 23:19:04 -0400 (EDT)
Date: Wed, 15 May 2019 23:19:04 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Paul Hoffman <paul.hoffman@icann.org>
cc: dnsop <dnsop@ietf.org>
In-Reply-To: <C3668C33-E3DB-4267-AF5B-FDC46262CC8F@icann.org>
Message-ID: <alpine.LRH.2.21.1905152258340.18222@bofh.nohats.ca>
References: <3BCCE28D-17C6-4367-A9C3-D0DCF56AB03A@icann.org> <alpine.LRH.2.21.1905151256480.22294@bofh.nohats.ca> <C3668C33-E3DB-4267-AF5B-FDC46262CC8F@icann.org>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l7Ptd_0R_IQOpcTnew5beEEl5N0>
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: Thu, 16 May 2019 03:19:15 -0000

On Wed, 15 May 2019, Paul Hoffman wrote:

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

But the content of RESINFO and the record of the to-be-done AUTHINFO
would be the same, namely a JSON blob. Why use two different RRtypes?
The JSON needs to be parsed and looked up for useful key words anyway.
So if you want to assist people re-using the RRdata in the forward and
reverse, you might as well pick one RRtype instead of having two.

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

You cannot for people to enable DoT or DoH either? I don't understand
your point.

>> 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?

I don't think so. It's all JSON anyway.

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

Wouldn't that have problems when in RFC1918 space? Where AS112 answers
with DNSSEC validated NXDOMAINs? At the very least the stub would need
to be aware of these special cases.....

You never replied why you are not using x-field2 instead of temp-field,
as is IETF lore?

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

ok.

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

ok.

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

sure, but see above. I think this has issues with RFC1918

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

Okay. Although some text should be added here or in the security
considerations about using DNSSEC.

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

I did not find the answer clear. Pointing me back to the document
doesn't help. Can you quote me the text where it is clear if an
implementer should do 1) or 2) and what the guidance for that is?

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

Wouldn't it make sense that you only describe different ways to get the
same data, and not different ways to get different data? I would prefer
if we keep the protocol the same and independent of the transport
protocol.

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

I don't understand this. Can you rephrase your answer?

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

Okay this is interesting. I never heard of it, but reading it it seems
to be talking about not only the prefix of "x-" but also of the concept
of it, saying:

    Creators of new parameters to be used in the context of application
    protocols:

    1.  SHOULD assume that all parameters they create might become
        standardized, public, commonly deployed, or usable across
        multiple implementations.

    2.  SHOULD employ meaningful parameter names that they have reason to
        believe are currently unused.

    3.  SHOULD NOT prefix their parameter names with "X-" or similar
        constructs.

The "temp-" construct clearly fails 1) and 3)

>>      "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"?

If I read in the JSON, I get a list of keys anyway. Why assume the
keyword "inventory" is telling the truth? From a security point of view
you cannot assume it is. So then I'm actually just not using the
keyword. Since we care about size in the DNS transport case, it is
better left out - it serves no useful purpose.

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

I agree that 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.

It does assume some minimum kind of support you have to know before
querying for all the supported features :)

Anyway, just a note saying if the reply it too large, normal DNS
processing applies and fallback to TCP is expected.

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

Note I did initially think this was more something to be done at the
DHCP level, where you get a list of DNS servers, so it might as well
send the feature set of each, but after some thinking about this, I
agree this method is much better - it can be deployed by updating only
DNS software.

So I'm in favour of WG adoption of this work :)

Paul