Thanks for the review!
On Jun 28, 2019, at 1:06 PM, 神明達哉 <[email protected]> wrote:
> 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 is a JSON object. What beyond that description would help?
> - 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.
Good catch! We will make this clearer in the next draft by sahing that, even if
the server is also an authoritative server, the responses only pertain to the
recursive side.
> - (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?)
Hrm, this is a good point. A recursive resolver might have cached a RESINFO
response from some other server that it queried. We will remove the restriction.
>
> - 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...
The whole sentence is confusing, and we can remove it. Thus, that whole
paragraph can go away.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
