>> However in the child-centric case this can cause problems when the >> NS set held by the parent changes (i.e. the zone is redelegated) but >> the NS set in the old set of servers isn't also updated. Such a >> child-centric resolver may completely fail to notice the >> redelegation. > > Yes, this is the "phantom domains" attack. Let me amend the suggested > definition: > > Child-centric resolver: a DNS resolver which will replace, in its > memory, the NS RRset and glue records obtained from the parent, by > data from the authoritative servers of the zone they belong to. This > is the proper behaviour (but note that a resolver MUST re-check from > the parent at some interval, to avoid "phantom domains").
Hmm. Firstly, isn't this "child-centric resolver" / "parent-centric resolver" simply an euphemism papering over the more distinct "correctly" and "wrongly" implemented resolver? A correctly implemented resolver implements the DNS authority model, and to do that requires that the resolver replaces non-authoritative cached data with more authoritative data whenever it is obtained. The perhaps most prominent example of non-authoritative data is the copy of the NS RRset from the child zone which exists in the parent zone. Secondly, let me re-formulate that other part. I thought this is rather a matter of properly letting the NS RRset expire from the cache, and not use the cached and soon-to-expire NS RRset to re-fetch the child NS RRset, but that instead the NS RRset needs to be re-fetched from the parent zone before subsequently possibly overriding that with new authoritative information from one of the (possibly new) child name servers, since the domain can have been re-delegated in the mean time. This all said without taking DNSSEC into consideration... > And this is the opportunity to define phantom domains: > > Phantom domain: a domain which was delegated but is no more, and is > still "active" in some resolvers because they did not check the > parent yet. Again, I'd simply call a resolver allowing this situation to persist to be "wrong/buggy". Best regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
