At Thu, 27 Jun 2019 18:44:09 +0000, Paul Hoffman <paul.hoff...@icann.org> 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop