I've read draft-muks-dnsop-dns-opportunistic-refresh-00. In short my current impression is: "interesting but not yet very convincing idea".
High-level comments: It's an interesting idea. However, depending on its main motivation I'm not sure how effective it is. As it's listed in the dnsop agenda https://datatracker.ietf.org/meeting/99/agenda/dnsop/ with draft-tale-dnsop-serve-stale, it may mainly intend to be a mitigation in case the authoritative server of a popular name becomes unreachable. But, for this proposal to be effective in that case, the resolver would have to query other names in the same zone periodically. I'm not sure if we can generally assume that in cases where it matters (for example, for the "twitter.com" zone the resolver may only query for "twitter.com"). Also, the target zone needs to be generally stable, so for example it's not very effective if the zone is quite frequently updated. I can imagine some popular zones are frequently updated, e.g., for load balancing purposes. For example, in my quick experiments the SOA serial of the facebook.com zone changes quite rapidly. On the other hand I wonder some other popular zones may not rely on SOA serials to keep its authoritative servers up to date (i.e., they may not use the standard zone transfer mechanism to distribute the latest version of zones to secondaries). I can also think of a corner case where this approach doesn't work well: assume a zone that changes very frequently and its serial can wrap quite quickly. unlike secondary authoritative servers that are supposed to be notified reasonably timely via NOTIFY, a resolver may not be able to notice intermediate changes quickly enough and incorrectly assumes the zone hasn't changed when the serial has actually wrapped around. It's easy to dismiss such a case as unrealistic, but as a formal protocol I don't think we should ignore these cases too casually. Given these observations, I'd first like to understand specifically for what purpose under which assumptions this proposal is deemed to be useful. At this moment it's not very convincing to me. Some specific comments on the draft text follow: - Section 4.3 Upon receiving a positive response containing an SOA RR and a valid ZONESERIAL EDNS0 option, the resolver SHOULD associate the zone's serial number with the RRs in the answer. I believe the resolver should also associate the zone name. Perhaps that's the intent, but it's not very clear from this description. So it would be better to say so more explicitly. - Section 4.3: what if the response contains a ZONESERIAL option but there's no SOA in the additional (or authority) section? - Section 4.5 o An authoritative server receiving a misconfigured ZONESERIAL option in a query SHOULD return a FORMERR response. o A resolver receiving a misconfigured ZONESERIAL option in a response MUST NOT interpret the serial number in any SOA RR in that response as an indication of zone freshness. It's not clear what "misconfigured" means. It would help if this could be more specific. - Section 5 I'd suggest revising the format diagram as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-------------------------------+-------------------------------+ ! OPTION-CODE ! OPTION-LENGTH ! +-------------+-+---------------+-------------------------------+ | Reserved |R| +-------------+-+ with the following description: Reserved A 7-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. R 1-bit request/acknowledge flag. This bit MUST be clear in requests [...same as the original text] The main motivation for this suggestion is that "Bit 7 of this field" in the original text might sound a bit ambiguous. Even if it can be considered reasonably clear per common sense, I think it'd still be helpful if we specify the position in the diagram. Also, in the suggested text the reserved area is just called "reserved" instead of calling the entire 8 bits "flags". Not a strong opinion, but I think it's better as we might want to use some of the reserved area for non-flag type of data. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
