Subject: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt

From: [email-masked]
Date: Tue, 11 Feb 2020 18:23:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : DNS Resolver Information Self-publication
        Authors         : Puneet Sood
                          Roy Arends
                          Paul Hoffman
	Filename        : draft-ietf-dnsop-resolver-information-01.txt
	Pages           : 9
	Date            : 2020-02-11

Abstract:
   This document describes methods for DNS resolvers to self-publish
   information about themselves, such as whether they perform DNSSEC
   validation or are available over transports other than what is
   defined in RFC 1035.  The information is returned as a JSON object.
   The names in this object are defined in an IANA registry that allows
   for light-weight registration.  Applications and operating systems
   can use the methods defined here to get the information from
   resolvers in order to make choices about how to send future queries
   to those resolvers.

   There is a GitHub repo for this draft where pull requests can be
   issued: https://github.com/DNSOP/draft-ietf-dnsop-resolver-
   information However, starting issues on the WG mailing list is
   preferred.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-information-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Robert Mortimer" <[email-masked]>
Date: Wed, 12 Feb 2020 09:59:04 +0000

I may be missing something obvious but this draft seems to contradict it self as it says in the introduction:

"Authoritative servers MUST NOT answer queries that are defined in this protocol."

and then goes onto say in section 2:

"if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for the addresses on which it responds."

I also wonder what the correct behavior is for a server which is both recursive and authoritative - is it prohibited from supporting this protocol by that first "MUST NOT"? 

-- 
RobM
On 12/02/2020 02:25:52, [email-masked] <[email-masked]> wrote:

Abstract:

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Feb 2020 16:48:52 +0000

> I also wonder what the correct behavior is for a server which is both recursive and authoritative - is it prohibited from supporting this protocol by that first "MUST NOT"? 

Good call. Would it make both parts clearer if the introduction instead said:

   Because the information returned in this protocol only applies to recursive
   resolvers, servers that are acting as both authoritative servers and recursive
   resolvers MUST only answer queries that are intended for the recursive
   resolver portion of the server. Servers that are only authoritative servers
   MUST NOT answer queries that are defined in this protocol.

--Paul Hoffman

---

From: "Robert Mortimer" <[email-masked]>
Date: Thu, 13 Feb 2020 09:39:25 +0000

That would be clearer or possibly just change that first "MUST NOT" to 
"Authoritative only servers MUST NOT answer queries that are defined in this protocol."

As the advice that: 

Surely means that it is answering a query made to the authoritative part so would again be contradicted by saying:
"MUST only answer queries that are intended for the recursive resolver portion of the server."

Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbird&amp;utm_medium=email&amp;utm_campaign=sent-from-mailbird]
On 12/02/2020 16:50:16, Paul Hoffman <[email-masked]> wrote:

--Paul Hoffman_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 17 Feb 2020 11:41:53 +0000

>    MUST NOT answer queries that are defined in this protocol.

It seems strange to me that this significant restriction is mentioned 
only in the Introduction.

I think that a clearer expression of the first case might be

   any server that can act as both an authoritative server and a 
recursive
   resolver MUST NOT answer queries that are defined in this protocol
   whenever it is acting as an authoritative server.

If this still seems to leave a contradiction, it may be worthwhile to 
view
the distinction as a property of the transaction, rather than of the 
"portion
of the server".  The server, if it receives a query for which it 
determines
that an authoritative answer is appropriate, must not answer as if it 
were
a recursive resolver.

Would it be useful to extend the protocol to include a signal for 
"Sorry: authoritative here"?

I hope some of this helps.

/Niall

---

From: Tony Finch <[email-masked]>
Date: Mon, 17 Feb 2020 14:31:54 +0000

Niall O'Reilly <[email-masked]> wrote:
>   any server that can act as both an authoritative server and a recursive
> view the distinction as a property of the transaction, rather than of
> the "portion of the server".  The server, if it receives a query for
> which it determines that an authoritative answer is appropriate, must
> not answer as if it were a recursive resolver.

The conditions for special recursive-only answers are queries with RD=1
that get responses with RA=1. (You might be able to allow queries with
RD=0 but I don't know if iterative clients that happen to be allowed RA=1
are likely to be confused by these answers.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
partnership and community in all areas of life