Willem/Shumon/Paul, Here’s some comments on draft-ietf-dnsop-ns-revalidation-08.txt
> Resolvers should also periodically revalidate the > child delegation by re-querying the parent zone at the expiration of > the TTL of the parent side NS RRset. The TTL for delegation revalidation is the minimum of the parent and child, right? Later in the draft it says "If the corresponding child zone's apex NS RRset TTL is smaller than the delegating NS RRset TTL, revalidation MUST happen at that interval instead. > a validation > query SHOULD be sent in parallel with the resolution of the > triggering query, The term “triggering query” is used a number of times. Should it be defined as a term, or does everyone just know what it means? > Positive responses to this > validation query will be cached with an authoritative data ranking. The draft uses “will” many times. Maybe these should be MUST, given its a standards track doc. > A No Data response (see Section 2.2 of [RFC2308]) for the validating > NS query should be treated the same as a failed validating NS query. Maybe there is something to say about not retrying failed failed queries too aggressively ala RFC 5920. > Additional validation queries for the "glue" address RRs of referral > responses (if not already authoritatively present in cache) SHOULD be I found this a little confusing at this place given that the next section is Upgrading A and AAAA RRset Credibility. Maybe Updating Glue Credibility should be a separate section. > Positive > responses will be cached authoritatively and replace the non > authoritative "glue" entries. > > A resolver > MAY choose to keep the non-authoritative value for the "glue" next to > the preferred authoritative value for fallback purposes. I was surprised to first read that non-authoritative glue will (MUST?) be replaced because it doesnt account for the case you describe later, when all authoritative names are not reachable. Maybe this could be reordered or rewritten. > In cases where the delegated > nameservers respond incorrectly to an NS query Could you be specific about what constitutes an incorrect response to an NS query? > Additional addresses in authoritative NS RRset responses SHOULD be > validated if they are not already authoritatively in cache. Only > when such additional addresses are DNSSEC verifiable, (because the > complete RRset is included, including a verifiable signature for the > RRset), such additional addresses can be cached authoritatively > immediately without additional validation queries. DNSSEC validation > is enough validation in those cases. Otherwise, the addresses cannot > be assumed to be complete or even authoritatively present in the same > zone, and additional validation queries SHOULD be made for these > addresses. I suggest rewriting this to talk about the DNSSEC verifiable case first (no address validation needed) and then say to do the address validation. As written I find it sort of mixed up, like: "do address validation. except sometimes you dont have to. otherwise you have to" > Note that there may be outstanding address validation queries for the > names of the authoritative NS RRset (from referral address validation > queries). I don’t think “referral address validation query” is a term previously used or defined. > 4.1. Strictly revalidating referral and authoritative NS RRset > responses > This subsection feels out of place to me, and maybe a little redundant with the second-to-last paragraph of section 3. > 7. Security and Privacy Considerations I think there should be a discussion of revalidation in the context of the NXNS or other types of excessive work attacks. I dont think the draft currently gives any advice about limiting the amount of revalidation. Even in non-attack situations, it seems that delegation revalidation could have very significant traffic impacts. Willem and his colleagues performed a study for ICANN, looking at consequences of having signed root name server data. One of their conclusions was that revalidation would provide better security than a signed root priming response. The tradeoff is more traffic. If every root priming query today resulted in an additional 1 NS query and 26 more A/AAAA queries (worst case), total root zone traffic would grow by 30%. Of course not all zones have that property, but some do, and it should probably be documented. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
