At Thu, 27 Jun 2019 18:44:09 +0000,
Paul Hoffman <[email protected]> wrote:
> Greetings. We have again updated draft-sah-resolver-information
> based on comments from this mailing list. We think that this is
> ready for adoption by the WG so that the initial use of the protocol
> (to be able to determine the URI template of the DoH server
> preferred by your current resolver) can move forward as well.
I don't have a strong opinion on the adoption, but I'm willing to
review it. My comments on 02 follow:
- I think the RESINFO RDATA specification (at least its wire format,
and preferably also the presentation format) should be more clearly
specified. At least to me it was not very clear, and I'm afraid
this can lead to interoperability problems.
- It was not clear to me how the RESINFO is supported or not supported
by authoritative servers.
Section 1 states:
[...] Authoritative
servers MUST NOT answer queries that are defined in this protocol.
But Section 2 states:
[...] 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.
This sounds like an "authoritative server" may answer those queries
(perhaps Section 1 means "real" authoritative servers, and
authoritative only servers in particular, while Section 2 intends to
mean "local zone" features often available in recursive server
implementations. But that's not really clear from the text.)
And Section 6 states:
[...] or unless the
<reverse-ip>.{in-addr,ip6}.arpa zone is signed with DNSSEC, the
response is susceptible to forgery.
This seems to implicate that RESINFO under a
<reverse-ip>.{in-addr,ip6}.arpa zone could be signed and answered by
its authoritative server.
I think the draft needs to clarify the expected role or limitation
of authoritative servers regarding the proposed protocol.
- (Somewhat related to the previous point) Section 2 states
Any query for the RESINFO RRtype that is not in <reverse-ip>.{in-
addr,ip6}.arpa/IN or a subdomain of <reverse-ip>.{in-addr,ip6}.arpa/
IN is meaningless and MUST result in a NODATA or NXDOMAIN response.
Resolvers would not need any special code to meet this requirement;
[...]
How can we enforce (with a MUST) the result of NODATA or NXDOMAIN,
especially if the resolver doesn't do anything special for such a
case? If it means the resolver could just try to resolve it with
authoritative servers and we require authoritative servers return
NODATA or NXDOMAIN, can we always assume that? What if the zone's
administrator configure a zone including the RESINFO? (And in any
case, wouldn't it contradict the MUST NOT in Section 1?)
- The last sentence of Section 2 doesn't make sense to me:
they only need code to handle the RESINFO RRtype that is not in
<reverse-ip>.{in-addr,ip6}.arpa/IN or a subdomain of <reverse-
ip>.{in-addr,ip6}.arpa/IN .
Should it actually be "that is in" instead of "that is not in"? If
it's really "not in", I don't know how to interpret this in this
context...
--
JINMEI, Tatuya
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
