Subject: [DNSOP] Authoritative servers announcing capabilities

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Sep 2020 20:37:38 +0000

Greetings. Puneet and I have an new draft, <https://tools.ietf.org/html/draft-pp-dnsop-authinfo>, that we would like DNSOP to consider. From the abstract:
  This document defines a new DNS RRtype, AUTHINFO, that is used by
  authoritative servers to publish information about themselves.  This
  information can be useful because a recursive resolver can determine
  an authoritative server's capabilities, such as whether an
  authoritative server supports the EDNS(0) client subnet extension.

The responses will be signed if the zone for which the server is authoritative is signed, meaning that validating resolvers can get authenticated information about the server if that would influence how they treat responses from the server.

As you might expect from from the authors of the RESINFO draft, the response is a JSON blob that can be extended to carry other information in the future as resolver operators and vendors think of additional information that would be useful to them.

We would like DNSOP to adopt this, and of course we are open to suggestions on how to improve the protocol.

--Paul Hoffman

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 11 Sep 2020 18:24:52 -0500

>    This document defines a new DNS RRtype, AUTHINFO, that is used by

[..]

> We would like DNSOP to adopt this, and of course we are open to suggestions on how to improve the protocol.

I know it is unrelated, but EPP uses authInfo term extensively (for 
authentication purposes and in practice basically as synonym of 
"password"), so I really recommend using another name for this record 
type, because otherwise I am pretty sure somewhere somehow someone will 
confuse both things.

Plus, why couldn't this be extended in the future to recursive 
nameservers as well? In which case, the name should be resolver genre 
agnostic.

Maybe something like "CAPABILITIES" or "ABILITIES"?
(or shorter version)

-- 
Patrick Mevzek

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Sep 2020 23:39:43 +0000

On Sep 11, 2020, at 4:24 PM, Patrick Mevzek <[email-masked]> wrote:
>> Greetings. Puneet and I have an new draft, <https://urldefense.com/v3/__https://tools.ietf.org/html/draft-pp-dnsop-authinfo__;!!PtGJab4!tA3Rg8zYWrkxVj0XhVFgOSw3njnqVfZ1lZb89fZi40rNWqnTDHsqJvazW8HMMZej0qCL5X79cg$ >, that we would like DNSOP to consider. From the abstract:
> I know it is unrelated, but EPP uses authInfo term extensively (for authentication purposes and in practice basically as synonym of "password"), so I really recommend using another name for this record type, because otherwise I am pretty sure somewhere somehow someone will confuse both things.

The name can be bikeshedded, but "authinfo" is used in multiple protocols because it is quite descriptive.

> Plus, why couldn't this be extended in the future to recursive nameservers as well? In which case, the name should be resolver genre agnostic.

There is already a draft for RESINFO. The difference is important, because a single host might be both a resolver and an authoritative server.

> Maybe something like "CAPABILITIES" or "ABILITIES"?

And you're thinking those aren't used in other protocols? :-)

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Sep 2020 09:40:11 +1000

and why is it a RR type at all.  An EDNS option or a opcode is better suited for this sort of thing.

> On 12 Sep 2020, at 09:24, Patrick Mevzek <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 11 Sep 2020 18:44:23 -0500

> There is already a draft for RESINFO. The difference is important, because a single host might be both a resolver and an authoritative server.

I don't believe two separate types are needed. As you return formatted 
data, information on the type (recursive vs authoritative) can certainly 
be in the data and there should probably be enough space in that data to 
store both cases, as needed.

> And you're thinking those aren't used in other protocols? :-)

The difference probably being on the fact that EPP is also very tied to 
the same area, aka domain names.
So the idea is not just to use a unique name across the whole word, but 
at least not a name already extensively used in another protocol in the 
same "world" of domain names.

That was just my suggestion (do not reuse authinfo name), feel free to 
ignore.

(but your email triggered that reflex in me as I have seen, in the realm 
of just EPP, so much abuse or misunderstanding of the authInfo term, 
that I wanted to convey the idea that even more confusion could be a curse).

-- 
Patrick Mevzek

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Sep 2020 00:16:25 +0000

On Sep 11, 2020, at 4:40 PM, Mark Andrews <[email-masked]> wrote:
> 
> and why is it a RR type at all.

So that the answer can be signed and thus validated.

> An EDNS option or a opcode is better suited for this sort of thing.

What advantages do those have that make the loss of validation worth it? It would be trivial for us to change the document to EDNS or and opcode if the WG wanted to lose the validation capability.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Fri, 11 Sep 2020 17:42:01 -0700

On Fri, Sep 11, 2020 at 5:16 PM Paul Hoffman <[email-masked]> wrote:

> What advantages do those have that make the loss of validation worth it?
> It would be trivial for us to change the document to EDNS or and opcode if
> the WG wanted to lose the validation capability.
>

If it isn't an RR, it can't be cached, and can only be obtained directly
("from the horse's mouth" as it were).
Given the context (recursive to authoritative), that's (IMHO) a reasonable
assumption/requirement, for how to obtain the answer, and ensure the
"liveness" of it.

If you want to go down the JSON blob path, I'm pretty sure the JSON itself
could be signed, although I am not sure on the answer of "signed with
what", or "validated how"?

It does clarify things as far as general context, though.
It would always be the server itself speaking on its own behalf, regardless
of the name(s) it is known by.

I think that actually ensures that the obtained "capabilities" map to the
server with no room for misinterpretation or zone vs server semantic errors.

This is all essentially metadata.

Yes, it could be provisioned in DNS. That doesn't necessarily make DNS the
best place for it.

Brian

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Sep 2020 00:47:47 +0000

> and why is it a RR type at all.  An EDNS option or a opcode is better suited

+1.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Fri, 11 Sep 2020 21:04:02 -0400

>> and why is it a RR type at all.  An EDNS option or a opcode is better suited

An RR type can be signed and distributed differently and allow for preloading of (distributed) caches which enhanced the decentralization of recursive DNS servers.

Paul

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 11 Sep 2020 21:29:35 -0400

> The responses will be signed if the zone for which the server is authoritative is signed, meaning that validating resolvers can get authenticated information about the server if that would influenc…

How does the zone signer know the capabilities of the nameservers that
will serve the zone and what does it do if the capabilities of those
servers differ? It sounds like this is incompatible with offline
signing.

Must a primary nameserver exclude AUTHINFO RR's from outgoing AXFRs to
secondary nameservers? Must secondary nameservers fail, filter, or
replace an incoming AXFR if it contains an AUTHINFO RR? By making this
an RR it seems like it would be easy to inadvertently serve an incorrect
AUTHINFO RR.

I think this should be an EDNS option rather than an RR and if integrity
protection beyond that of plain DNS is needed, it can be combined with
COOKIE, SIG(0), TSIG, DoT, etc.

-- 
Robert Edmonds

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 11 Sep 2020 21:34:02 -0400

> An RR type can be signed and distributed differently and allow for preloading of (distributed) caches which enhanced the decentralization of recursive DNS servers.

As described in -00, a cached and re-distributed AUTHINFO RR is useless
unless you know what nameserver address it applies to, and if an
AUTHINFO RR isn't trustworthy unless it's signed then the AUTHINFO RR
would need to embed the nameserver address that it applies to so that
that information can be signed and validated as well.

-- 
Robert Edmonds

---

From: Paul Vixie <[email-masked]>
Date: Sat, 12 Sep 2020 01:40:26 +0000

On Fri, Sep 11, 2020 at 09:04:02PM -0400, Paul Wouters wrote:
> > ???On Sat, Sep 12, 2020 at 09:40:11AM +1000, Mark Andrews wrote:
> An RR type can be signed and distributed differently and allow for
> preloading of (distributed) caches which enhanced the decentralization of
> recursive DNS servers.

an authority server's capabilities are with respect to a zone. for example,
dnssec availability, dnssec details like algs, maximum message sizes, 
truncation policy, willingness to do persistent TCP (or QUIC) sessions.

our community seems hell bent on gradually evolving the system toward the
needs that micro-leasing would address, without actually understanding that
or getting there. _it's never about the server_.

-- 
Paul Vixie

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2020 02:23:40 -0000

In article <[email-masked]>,
>So that the answer can be signed and thus validated.

It looks to me like all of the servers for a particular zone would
have to return the same AUTHINFO, which seems like a bad idea since
they don't necessarily all have the same features.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Sep 2020 02:24:27 +0000

On Sep 11, 2020, at 6:29 PM, Robert Edmonds <[email-masked]> wrote:
> servers differ?

Because the zone owner wrote an AUTHINFO RR into the zone. This is no different than any other record.

> It sounds like this is incompatible with offline
> signing.

Not at all. Offline signing works on RRs.

> secondary nameservers?

No.

> Must secondary nameservers fail, filter, or
> replace an incoming AXFR if it contains an AUTHINFO RR?

No.

> By making this

In what case would a secondary have different information than the primary?

> COOKIE, SIG(0), TSIG, DoT, etc.

Again, we're fine with using an EDNS option if people don't want the information signed or cached. This seems like a steep limitation for benefits I still don't see (as shown above), but if that's what the WG wants, it's an easy change to make.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 12 Sep 2020 02:26:18 +0000

> they don't necessarily all have the same features.

At this point, the only information we defined in the draft is for doing client subnet. If there are server sets for a single zone where some do client subnet, and others don't, then your concern is valid. Changing this to an uncacheable, unverifiable EDNS option is easy.

--Paul Hoffman

---

From: Robert Edmonds <[email-masked]>
Date: Fri, 11 Sep 2020 22:39:56 -0400

> At this point, the only information we defined in the draft is for doing client subnet. If there are server sets for a single zone where some do client subnet, and others don't, then your concern i…

The draft is not limited to ECS. It creates an IANA registry and allows
arbitrary "local use" values to be defined. It can already be used to
specify different capabilities for each nameserver for a zone, because
the draft also allows:

   Most zone typically have multiple authoritative servers.  Thus, the
   AUTHINFO Rdata returned from different authoritative servers for the
   same zone might differ.

If that's not correct, and all the nameservers must return the same
AUTHINFO RR, then perhaps a better name would be "ZONEINFO", all the
references to "server" changed to "zone", etc.

-- 
Robert Edmonds

---

From: Paul Wouters <[email-masked]>
Date: Sat, 12 Sep 2020 00:19:40 -0400

> that information can be signed and validated as well.

Put the RR at each NS name, eg _encdns.ns0.nohats.ca. 

Paul

---

From: Joe Abley <[email-masked]>
Date: Sat, 12 Sep 2020 12:57:28 +0200

>> and why is it a RR type at all.  An EDNS option or a opcode is better suited

Plus lots. See below for TL;DR.

Operational reality is that there are often a different set of nameservers authoritative for the zone than are anticipated by whomever is responsible for the zone contents. Examples are mismatches between NS RRSets above and below the zone cut, and people opportunistically serving zones from from their own authoritative servers for their own local reasons (e.g. RFC 8806).

It's not reasonable to assume that all authoritative servers for any particular zone have the same server characteristics. Almost by definition, different servers live in different places with different local conditions in all layers up to and beyond 9, operated by different people with no existing requirement to centralise operational changes with the people responsible for zone data. To address the example given in the draft, it's ok some authoritative servers for a zone support ECS and others do not; some will give ECS-specific answers and some will not. Clients will still get answers. More generally, if the goal is a general mechanism that might be used to describe as-yet-unknown characteristics about a server, it ought to allow individual servers to be described.

It's not reasonable to assume that an individual hostname as exposed in a single NS RR corresponds to a single server. Authoritative servers are routinely provisioned as clusters or anycast clouds, and the details of what individual server might look like can change between successive queries.

It's always possible to imagine a very simple set of authoritative servers for a particular zone which would not run into these kinds of problems. However, such a mechanism would fail in exciting ways for pretty much any zone you can imagine that sees any real traffic. High-traffic zones with twitchy end-users are not usually provisioned in onto static, simple sets of authoritative servers.

If there is to be a general mechanism that describes the characteristic of an individual authoritative server, it ought to be one that embeds information in a specific response in such a way that it will never normally be cached.

Whether there is a convincing use-case for such a mechanism is a separate question. The example given in the draft does not seem very convincing, simply because there is an existing mechanism to achieve the same thing (see RFC 7871 section 7.2.1).

Joe

---

From: "John Levine" <[email-masked]>
Date: 12 Sep 2020 19:39:01 -0000

In article <[email-masked]>,
>Put the RR at each NS name, eg _encdns.ns0.nohats.ca. 

Same problem, the server may offer different features in different zones.

I'm not seeing a workable alternative to EDNS0 here.  I realize there's no way
to sign them, but perhaps we can address that by merging this discussion with
the one about authenticated DoWhatever.

---

From: Peter van Dijk <[email-masked]>
Date: Mon, 14 Sep 2020 11:33:33 +0200

Hello Paul, Puneet,

On Fri, 2020-09-11 at 20:37 +0000, Paul Hoffman wrote:
> Greetings. Puneet and I have an new draft, <https://tools.ietf.org/html/draft-pp-dnsop-authinfo>;, that we would like DNSOP to consider. From the abstract:

Thank you for writing this down.

I'm not sure I'm a fan yet (ECS does not need this, and the DoT-usecase that builds upon this in DPRIVE is troublesome at least until the disconnect described below is resolved), but for now I have some comments that should improve the document.

In general, this document appears to suffer from a disconnect between 'information published by an auth about itself' and 'information published in a zone'. Elsewhere in the thread this appears to be leading to 'perhaps it should be EDNS instead', but I feel that that is a premature conclusion. Deciding on that would make more sense once this disconnect is resolved.

'Thus, the AUTHINFO Rdata returned from different authoritative servers for the same zone might differ.' (section 2) and 'The values in the AUTHINFO response will be protected by DNSSEC signature if the zone in which the record resides is signed.' (section 6) appear to be fundamentally incompatible claims (unless all auths for a domain are live-signing).

Similarly, 'Because the record with this information can be signed with DNSSEC, it can be used to help a recursive resolver know whether to expect particular EDNS(0) [RFC6891] options in responses.' in section 1 appears to conflate EDNS protocol abilities with zone contents.

'For example, if an authoritative server is authoritative for example.com, the query could be example.com/IN/AUTHINFO, or the QNAME could be any other name for which the server is authoritative.' (section 2): 'could be any other name' feels underspecified. What other names would make sense? Please be specific. (Non-exhaustive suggestions, each with their own problems: the NS name. A special name [_authinfo.arpa].) My personal preference would be that a singular choice is made here. Anything more than that would amount to more probing code in resolvers, and resolvers do not have time for that.

Expanding section '4.1 Example' to be explicit about the zone, its NSes, and the related AUTHINFO queries and responses would presumably resolve these ambiguities/incompatibilities.

Other comments:

'If the QNAME in the request is for a zone for which the authoritative server is not authoritative, the response MUST be an NXDOMAIN response.' (section 2) is wrong - NXDOMAIN is an authoritative answer, so it cannot be the answer given if the server is not authoritative. REFUSED is the usual response, but I am unsure this has been codified in any document.

The document does not specify when the AUTHINFO query is issued. Is this before any other conversation with the server, or can it be done opportunistically so that the information eventually appears in the cache? (The related dprive document hints at answers for this but does not provide enough rope either.)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: "libor.peltan" <[email-masked]>
Date: Mon, 14 Sep 2020 16:32:52 +0200

Let me leave some personal opnion/comments on this AUTHINFO idea, 
although I don't know the background here.

There are multiple kinds of "capabilities" of an authoritative server.

Some of them are properties of the zone, some are properties of the DNS 
server implementation, some are properties of the operational policy. 
For examples: DNS algorithm, EDNS version, network MTU, respectively.

While it seems reasonable to disclose some properties of the zone by an 
extra zone RR (although it would probably require extra query!), the 
properties of DNS server will often vary since implementation diversity 
is a general recommendation.

I don't know the foreseeable use-cases for this or similar kinds of 
properties signalization. The listed examples are already signalized 
another way (EDNS buf size), or useless (DNSSEC presence and DNSKEY 
algorithm).

By the way, the operators tend to hide properties of their server 
implementations, rather than disclose it. See version.server. CH TXT ...

BR,

Libor

PS: i'm very sorry for the previous e-mails. My client got somehow mad 
and sent the e-mail while I was typing it!

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 14 Sep 2020 16:07:28 +0000

On Sep 14, 2020, at 2:33 AM, Peter van Dijk <[email-masked]> wrote:
> In general, this document appears to suffer from a disconnect between 'information published by an auth about itself' and 'information published in a zone'.

You and others here are completely correct about this, and it is definitely something that needs to be resolved before this idea moves forward.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Mon, 14 Sep 2020 17:34:23 +0100

> On 14 Sep 2020, at 17:07, Paul Hoffman <[email-masked]> wrote:
> 

I think more clarity is needed on what problem this draft solves. Is it to help resolving servers select the authoritative server to query? How are resolving servers expected/required to use this information? Publishing this sort of info as a JSON blob or whatever purely for informational purposes seems fine. I’m not so sure it’s a good idea if it will complicate resolver behaviour or leads to operational difficulties: eg send all queries to the only name server for some zone (on the other side of the planet) which does/doesn’t do (say) ECS.

Could this I-D lead on to something ickier, like stub resolvers signalling to resolving servers that they want their queries to be resolved with/without QNAME minimisation, ECS, some flavour of encrypted transport, etc, etc?

---

From: Paul Vixie <[email-masked]>
Date: Mon, 14 Sep 2020 19:16:49 +0000

On Mon, Sep 14, 2020 at 04:32:52PM +0200, libor.peltan wrote:
> ...
> properties of DNS server will often vary since implementation diversity is a
> general recommendation.

+1.

> properties signalization. ...

in _structured requirements definition_ (1982), author ken orr puts forth a
strong argument that "data which is not used will be wrong" (among other
strong arguments).

https://www.amazon.com/gp/offer-listing/B002V1CES2/ref=tmm_pap_used_olp_0?ie=UTF8&condition=used

> implementations, rather than disclose it. See version.server. CH TXT ...

also +1.

-- 
Paul Vixie

---

From: Ray Bellis <[email-masked]>
Date: Sat, 19 Sep 2020 10:51:10 +0100

> is a general recommendation.

The initial drafts of what became DNS Stateful Operations (RFC 8490) 
included something akin to a server capabilities exchange / negotiation.

Personally I think EDNS is the wrong place for negotiating server 
properties because unless you're using TCP there's no guarantee that the 
server whose properties you've cached is going to be the one that 
answers the next query you send to that address.

The flip side is that RFC 8490 support is currently rare, and is perhaps 
one of those server capabilities one wants to find out about :p

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 21 Sep 2020 00:45:59 +0100

Paul Hoffman <[email-masked]> wrote:
>
> At this point, the only information we defined in the draft is for doing client subnet.

Why can't you just send client-subnet in a request and look at the answer?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Selsey Bill to Lyme Regis: Northeast 3 or 4, becoming variable 3 or less.
Slight or moderate, becoming smooth or slight. Fair. Good.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 21 Sep 2020 09:52:40 -0400

> On Sep 19, 2020, at 5:51 AM, Ray Bellis <[email-masked]> wrote:
> 
> 
> 
>> Let me leave some personal opnion/comments on this AUTHINFO idea, although I don't know the background here.
>> Some of them are properties of the zone, some are properties of the DNS server implementation, some are properties of the operational policy. For examples: DNS algorithm, EDNS version, network MTU, respectively.
>> While it seems reasonable to disclose some properties of the zone by an extra zone RR (although it would probably require extra query!), the properties of DNS server will often vary since implementation diversity is a general recommendation.
> 
> The initial drafts of what became DNS Stateful Operations (RFC 8490) included something akin to a server capabilities exchange / negotiation.
> 
> Personally I think EDNS is the wrong place for negotiating server properties because unless you're using TCP there's no guarantee that the server whose properties you've cached is going to be the one that answers the next query you send to that address.
> 
> The flip side is that RFC 8490 support is currently rare, and is perhaps one of those server capabilities one wants to find out about :p
> 
> Ray

This has been discussed on this list before but the reason we removed capabilities negotiation was that there’s no real benefit, only perceived. The capabilities flags add potential delay and another vector for additional bugs but a client still has to try the feature to see if it works as advertised.

The client should just try the feature directly. This potentially reduces delay and code.

Tom

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Sep 2020 15:28:47 +0000

> Why can't you just send client-subnet in a request and look at the answer?

That assumes that an attacker in the middle has not removed the answer. The indicator that we used as an initial idea for the capability would be signed, meaning that the resolver would expect a client subnet response and could act if it didn't get one. This is one of the reasons we chose using an RRtype over using EDNS0 for the capabilities (also: it is cacheable). Others seem to not want those features for capabilities.

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Sep 2020 14:03:01 +0100

Paul Hoffman <[email-masked]> wrote:
> That assumes that an attacker in the middle has not removed the answer.
> The indicator that we used as an initial idea for the capability would
> be signed, meaning that the resolver would expect a client subnet
> response and could act if it didn't get one.

OK, but how would the resolver's reaction differ? I.e. what problem is
caused by resolvers lacking prior knowledge of client-subnet support?

The more general solution for fixing traffic corruption is authenticated
DoT, so it doesn't seem worth the effort to introduce a special mechanism
to protect one EDNS option when DoT can do the job.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Foreland to Selsey Bill: Southwesterly 3, increasing 4 or 5, then 6 or 7
later. Smooth becoming slight, then moderate later. Rain or showers later.
Moderate or good.