On 4/30/15, 10:35, "Andrew Sullivan" <a...@anvilwalrusden.com> wrote:
>> Vice versa, once the parent removes >> the NS set, the delegation is removed regardless of what the child >> "thinks." > >Well, effectively maybe not. If a resolver "sticks" on the child, >then the delegation won't move regardless. The context here is the definition of the term "delegation". In operations, it's expected that a parent could remove a delegation (in the policy sense) and because of TTL's, the child's presence sticks in the cache. This is a legitimate outcome of the use of caching. (It can be abused, of course, but I'm just trying to stick to definitions of terms, not operational issues.) In my personal judgement, the mere fact that there is a transitional state of a half-baked delegation is not significant. Perhaps there's a need to "name" this state (I can see trying to explain this to a customer). But to me that doesn't mean the definition of delegation has to take this into account. In "policy time" the delegation ends when the parent's zone serial is incremented and the cut point is gone. In "real time" the delegation ends in the eyes of a resolver when it discovers there is no cut point. Yes, these are different, but to define "delegation" I would stick to the perspective of the parent because it is the one legitimately holding the cards.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
