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

From: Paul Wouters <[email-masked]>
Date: Wed, 15 May 2019 13:23:48 -0400 (EDT)

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

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

    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.

    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 ? It also opens up pandora's box of IDN support.

    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.

 	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?

    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 ?

    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.

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

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

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

    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.

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

 	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.

Paul
ps: NITS: when announcing drafts for people to read, including a URL is helpful :)

---

From: "John Levine" <[email-masked]>
Date: 15 May 2019 13:47:12 -0400

>answers, but you don't allow DNSSEC (data origin) authenticated answers?

It's information about the resolver.  What's the data origin for info
about the resolver at some random IP address?

If there's some way to get a validated SSL cert for an IP address you
can at least have some confidence that the URI served from the IP
is under the same control as the resolver on that IP.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 May 2019 21:29:59 +0000

On May 15, 2019, at 1:23 PM, Paul Wouters <[email-masked]> wrote:
> 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

Because we cannot force anyone to sign their zones.

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

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

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

> as the resolver, so I can give you DNSSEC authenticatied answers.

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

> answers, but you don't allow DNSSEC (data origin) authenticated answers?

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

> Again lifting TLS over DNSSEC ?

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

> document should clearly specify which of the two is allowed and which is

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

> 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

It was not about expensive, it was about expressiveness.

> IETF tradition is to use a x- or X- prefix for this kind of thing. Why

See BCP 178 (RFC 6648).

> I think if I would write code for this, I would just completely gnore it

What do you mean by "trusted"?

>   registration request is reasonably understandable, the registration

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

> What to do if the inventory is too large for a DNS reply.

DNS replies can be arbitrarily large.

> What are the

This is normal DNS response handling.

> of a named resolver (eg dns.nohats.ca) that can use DNSSEC to protect

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

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 15 May 2019 17:49:02 -0400

>DNS replies can be arbitrarily large.

A single RR can only be 64K since there's a 16 bit length field.

This reinforces my belief that this data belongs in an http or https
response not an ever more complex DNS thing.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 15 May 2019 23:19:04 -0400 (EDT)

> 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 fro…

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.

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

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

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

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

ok.

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

ok.

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

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

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

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

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

> It was not about expensive, it was about expressiveness.

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

>> IETF tradition is to use a x- or X- prefix for this kind of thing. Why

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)

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

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

I agree that would be great :)

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

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 May 2019 22:30:39 +0000

Greetings again. Based on the input from the DNSOP and DOH lists, we revised draft-sah-resolver-information. We also created a new draft, draft-sah-resinfo-doh, to cover the main use case we have for getting information from a resolver, namely to get the DoH URI template and authentication information.

>From the mailing list traffic, it seems like some of y'all only care about getting resolver information from DNS (hopefully DNSSEC-signed), while others are fine to use HTTPS with web PKI authentication, particularly when DNSSEC signing is not possible. We have left both methods in the main draft.

We encourage more input.

--Paul Hoffman

======
       Title           : DNS Resolver Information Self-publication
       Authors         : Puneet Sood
                         Roy Arends
                         Paul Hoffman
	Filename        : draft-sah-resolver-information-01.txt
	Pages           : 9
	Date            : 2019-05-22

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-sah-resolver-information/

======
       Title           : DNS Resolver Information: "doh"
       Authors         : Puneet Sood
                         Roy Arends
                         Paul Hoffman
	Filename        : draft-sah-resinfo-doh-00.txt
	Pages           : 5
	Date            : 2019-05-22

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-sah-resinfo-doh/

---

From: Erik Nygren <[email-masked]>
Date: Wed, 22 May 2019 22:01:31 -0400

Some comments:

* We should define what TLS SNI value gets sent.  Perhaps the first value
of "domain-to-match" when present, but preferably the hostname of the URL
when it's not an IP?

* Should clients consider the templates list to be ordered or unordered?
We may wish to define the behavior for handling multiple entries.  (A
common case might be both an IPv6 and IPv4 address.  Some clients might
only have only one of those, so would need to filter appropriately, and
operators may wish to specify an ordering preference such as
IPv6-preferred.)
* It would be worth a conversation with the people working on PvD in
IntArea to see if there is some alignment (eg, in-terms of JSON practices,
and perhaps even with PvDs being able to include or reference a
resolver-information block).  There might be a path here that could also
help with the split-horizon case.

* With the draft-sah-resolver-information framework, we may wish to also
have an attribute or draft for specifying the DNS64 prefix to allow
client-side DNS64 synthesis.  (On the other hand, there are also drafts to
send this via an RA option as well as some other paths in-addition to other
mechanisms.  So perhaps another mechanism isn't needed.)

      Erik

On Wed, May 22, 2019 at 6:30 PM Paul Hoffman <[email-masked]> wrote:

> Greetings again. Based on the input from the DNSOP and DOH lists, we
> revised draft-sah-resolver-information. We also created a new draft,
> draft-sah-resinfo-doh, to cover the main use case we have for getting
> information from a resolver, namely to get the DoH URI template and
> authentication information.
>
> >From the mailing list traffic, it seems like some of y'all only care
> about getting resolver information from DNS (hopefully DNSSEC-signed),
> while others are fine to use HTTPS with web PKI authentication,
> particularly when DNSSEC signing is not possible. We have left both methods
> in the main draft.
>
> We encourage more input.
>
> --Paul Hoffman
>
> ======
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "John Levine" <[email-masked]>
Date: 22 May 2019 22:21:00 -0400

Hmmn, interesting changes.  Here's a few questions.

As a passive-aggressive DNS manager, I can put RESINFO records
anywhere I want, including in my rDNS zones.  I can even sign them.
If a stub does a RESINFO lookup for a record that actually exists,
what's the cache supposed to do?  How can a stub tell a RESINFO
generated by a RESINFO-aware cache from one passed through a non-aware
cache?  Does it matter?  Presumably if I can put records in the rDNS I
have some connection with whoever is using the address space.

Bonus question: what is the stub supposed to do about DNSSEC?  The
record passed through the non-aware is more likely to have valid
DNSSEC than one inserted by the aware cache.

For the issue of validating the certificate on a DoT or DoH server, how
about this kludge: the client contacts the server by IP address, the
server returns a certificate.  If it has an IP address and it matches,
swell, you're done. If it has a domain name, do a DNSSEC validated A
or AAAA lookup, and if you get an answer with the IP of the server,
it's OK.  If it has multiple domain names, maybe look them all up
or maybe don't do that.

This can work even for servers in RFC 1918 space, since the IP address
isn't used to contact the cache, only to confirm it's the right one.
We Let's Encrypt fans can use DNS validation for the certificate, no
need for the CA to contact the cache either.  This potentially leaks
info about the location of the cache to anyone who can observe the
traffic, but usually if there's an observer. it is in the cache itself
so how much of a problem would that be?

After two minutes of thought I don't see any obvious security holes,
but it's possible I'm missing something.  It works for DoH and DoT on
8.8.8.8 and 8.8.4.4 now.  It almost works on 9.9.9.9 except that the
cert says *.quad9.net and the hostname is dns.quad9.net.

R's,
John

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 23 May 2019 11:48:55 -0400

Instead of "domains-to-match", with IP addresses in the templates, I would
prefer an optional "ip-addresses" field listing some addresses, with domain
names in the templates (unless the server intends to use an IP cert, in
which case it would be an IP in the template).  This would also address
Erik's question about SNI.

On Wed, May 22, 2019 at 10:02 PM Erik Nygren <[email-masked]> wrote:

> On Wed, May 22, 2019 at 6:30 PM Paul Hoffman <[email-masked]
> <paul.hoffman@icann..org>> wrote:
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 May 2019 01:06:56 +0000

On May 22, 2019, at 7:01 PM, Erik Nygren <[email-masked]> wrote:
> 
> Some comments:
> 
> * We should define what TLS SNI value gets sent.  Perhaps the first value of "domain-to-match" when present, but preferably the hostname of the URL when it's not an IP?

The "domain-to-match" values are not known until after the query has been responded to. Thus, it seems like the only likely SNI value would be the domain name of the resolver, if the application knows that. We can include that in a future draft.

> * Should clients consider the templates list to be ordered or unordered?  We may wish to define the behavior for handling multiple entries.  (A common case might be both an IPv6 and IPv4 address.  Some clients might only have only one of those, so would need to filter appropriately, and operators may wish to specify an ordering preference such as IPv6-preferred.)

Our first guess was "unordered". The draft says:
   If the "template" array has more than one string, a client
   can consider them all to be of equal value when finding a
   DoH server associated with the resolver.
My personal view is that suggesting order always complicates processing for very little actual gain. Assume that clients are smart if they want to be smart.

> * It would be worth a conversation with the people working on PvD in IntArea to see if there is some alignment (eg, in-terms of JSON practices, and perhaps even with PvDs being able to include or reference a resolver-information block).  There might be a path here that could also help with the split-horizon case.

The PvD folks are free to do their JSON however they want. It may be premature to try to add DoH information to their document.

> * With the draft-sah-resolver-information framework, we may wish to also have an attribute or draft for specifying the DNS64 prefix to allow client-side DNS64 synthesis.  (On the other hand, there are also drafts to send this via an RA option as well as some other paths in-addition to other mechanisms.  So perhaps another mechanism isn't needed.)

draft-sah-resolver-information framework makes it easy for anyone to suggest new additions to the information.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 May 2019 01:11:05 +0000

On May 22, 2019, at 7:21 PM, John Levine <[email-masked]> wrote:

> what's the cache supposed to do?  

Cache them. They're no different than any other DNS record.

> How can a stub tell a RESINFO
> cache?

They cannot.

>  Does it matter?  

No.

> Presumably if I can put records in the rDNS I

Exactly.

> DNSSEC than one inserted by the aware cache.

A validating stub would, well, validate. Again, these are no different than any other DNS record.

> it's OK.  If it has multiple domain names, maybe look them all up

That is possible, but outside the scope of this document. That is, the same would be true for *any* HTTPS client that gets a certificate with an IP address in the certificate but not a name that it likes.

> so how much of a problem would that be?

Agree.

> cert says *.quad9.net and the hostname is dns.quad9.net.

Those are implementation issues.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 23 May 2019 21:12:49 -0400

> That is possible, but outside the scope of this document. That is, the same would be true for *any* HTTPS client that gets a certificate with an IP address in the certificate but not a name that it…

I was more thinking of it for DoT.  There's too much intertia in https to 
change anything there.

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

---

From: "John R. Levine" <[email-masked]>
Date: 29 May 2019 17:44:45 -0400

>> From the mailing list traffic, it seems like some of y'all only care about getting resolver information from DNS (hopefully DNSSEC-signed), while others are fine to use HTTPS with web PKI authenti…

I see that draft-ietf-acme-ip-06 is now in last call.  It adds IP address 
certificates to the ACME protocol.  The only validation it uses is http 
challenge to a web server on that IP, not DNS.

It says that since SNI only allows host names, if the challenge sends SNI, 
it's the rDNS version of the IP in in-addr.arpa or ip6.arpa.

I still think this draft should stick to retrieval of the JSON blob by 
https to the IP of the resolver and not try to do anything clever in the 
DNS.  It's a lot less to invent.

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