I've read the draft and have the following comments. - Section 5
o SOURCE NETMASK, unsigned octet representing the length of the netmask pertaining to the query. In replies, it mirrors the same value as in the requests. It can be set to 0 to disable client- based lookups, in which case the ADDRESS field MUST be absent. I suspect the term "NETMASK" could be misleading or at least inaccurate. Technically, a netmask can be an arbitrary bit pattern to represent a "mask", so its "length" may not always be well-defined. Also, IPv6 doesn't support the concept of non-contiguous "netmask". This definition seems to implicitly assume contiguous netmasks, and define the term "NETMASK" as the prefix length of an address. I'm fine with the assumption as non-contiguous IPv4 netmasks can be reasonably considered a thing of past. But in that case I'd suggest using the term "PREFIX-LENGTH", noting that this specification does not support non-contiguous IPv4 netmasks. Same for SCOPE NETMASK. - Section 5 o SCOPE NETMASK, unsigned octet representing the length of the [...] It might or might not match SOURCE NETMASK; it could be shorter or longer. "match" sounds awkward since the "SOURCE NETMASK" is defined as a length of bits (again, I'd suggest renaming it "SOURCE PREFIX-LENGTH"). I suggest: s/match/be equal to/ (and perhaps s/shorter or longer/smaller or larger/) - Section 6.1 A Stub Resolver MAY generate DNS queries with an edns-client-subnet option with SOURCE NETMASK set to 0 (i.e. 0.0.0.0/0) to indicate that I'd suggest: s/i.e./e.g./ since this may also be an IPv6 address (in which case FAMILY is set to 2) - Section 6.3 fields, as detailed below. Note that the additional and authority sections from a DNS response message are specifically excluded here. Any information cached from these sections MUST NOT be tied to a network. What if the "optimized" reply is a negative one for some specific client addresses (while it's positive for some other addresses)? The authoritative server would (or might) return an SOA in the authority section, expecting the Recursive Resolver to use it for negative cache specific to the corresponding client address. Or are we simply excluding the support for negative optimized replies? (If so, I think it would be worth noting explicitly). - Section 6.3 If the address of the client is within any of the networks in the cache, then the cached response MUST be returned as usual. If the address of the client matches multiple networks in the cache, the entry with the longest SCOPE NETMASK value MUST be returned, as with most route-matching algorithms. If I understand this (and Section 6.3 in general), the following "suboptimal" scenario could happen: - The Authoritative Server is configured with two prefixes for optimized responses: 2001:db8::/32 and 2001:db8:2::/48 - The Recursive Server sends a query with SOURCE of 2001:db8:1::/48 - The Authoritative Server finds the best matching prefix for the SOURCE is 2001:db8::/32 and returns a response corresponding to it, setting SCOPE NETMASK to 32 - The Recursive Server receives the response and caches it - The Recursive Server receives a query from 2001:db8:2::1, and finds it has a matching cache (with prefix being 2001:db8::/32) and uses the cached response to answer the query, even if it could get the specifically optimized response for 2001:db8:2::/48 from the Authoritative Server. Is my understanding correct? If so, is this a problem to resolve or something we need to accept? - Section 6.3: likewise, what about the following scenario? - The Authoritative Server is configured with two prefixes for optimized responses: 2001:db8::1/48 and 2001:db8:2::/48 - The Recursive Server receives a query from 2001:db8:3::1 and sends its own query to the Authoritative Server with SOURCE=2001:db8::/32, SCOPE NETMASK=48 - The Authoritative Server finds the two /48 prefixes match the source, and returns a response using one of them. - The Recursive Server receives the response and caches it. - The Recursive Server receives a query from 2001:db8:3::1 again. It doesn't match the cached SCOPED address, so it sends its own query to the authoritative server again. - This will be always the case for 2001:db8:3::1, and the cached information is effectively useless, making the Recursive Server busier. - Section 6.3 Any reply containing an edns-client-subnet option considered invalid should be treated as if no edns-client-subnet option was specified at all. What specifically does "considered invalid" mean? And, depending on that, shouldn't the reply rather be discarded in such a case? - Section 8 The presence or absence of an [RFC6891] EDNS0 OPT resource record containing an edns-client-subnet option in a DNS query does not change the usage of the resource records and mechanisms used to provide data origin authentication and data integrity to the DNS, as described in [RFC4033], [RFC4034] and [RFC4035]. OPT records are not signed. While what's described in this section is not incorrect, I suspect it's not really fair not to mention that intended deployments (i.e., CDN-like ones) with this option are not really friendly with DNSSEC at best; even if it's not impossible to provide a valid signature for every "optimized" response in theory, it would involve many non-trivial technical challenges such as on-the-fly signing. If these challenges make CDN-like operators unwilling to deploy DNSSEC and this option makes the optimization even more attractive, then this option could help hinder wider deployment of DNSSEC. I'm not saying this option is evil and should be banned just because of this, but I'd expect this kind of consideration for this section to be more helpful and fair. - Section 10.1 Users who wish their full IP address to be hidden can include an edns-client-subnet option specifying the wildcard address 0.0.0.0/0 (i.e. FAMILY set to 1 (IPv4), SOURCE NETMASK to 0 and no ADDRESS). What if the user (stub resolver)'s address is IPv6? Should it still set FAMILY to 1? - Section 10.2 With multiple queries for the same name in flight, the attacker has a higher chance of success in sending a matching response (with the address 0.0.0.0/0 to get it cached for many hosts). Another IPv4-centric description. This should probably be, e.g. "with the SCOPE NETMASK being 0, meaning an empty prefix". - Section 12 1. A stub resolver SR with IP address 192.0.2.37 tries to resolve www.example.com, by forwarding the query to the Recursive Resolver R from IP address IP, asking for recursion. I guess the intent was: s/Resolver R/Resolver RNS/. And some other "R"s in the section will also have to be changed to "RNS". - Section 12 * ADDRESS, set to 0xC0 0x00 0x02 0xE0, copied from the request. This is not a verbatim copy from the request, so I suggest: "extended from the request". Editorial nits - Section 3: A very minor point, but this draft seems to always use the term "Section" to refer to a numbered portion of RFCs/drafts, such as "Section 5" or "Section 6.1", so to be consistent "chapter" would better be "Section". Authoritative Nameserver: A nameserver that has authority over one or more DNS zones. These are normally not contacted by clients directly but by Recursive Resolvers. Described in [RFC1035] chapter 6. - Section 6.3: s/.././ to queries originating from the network covered by the ADDRESS and SCOPE NETMASK.. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop