In message <20150225.150348.396032001...@uninett.no>, Havard Eidnes writes: > >> 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?
No. This can only happen if changes in nameservers are mis-manged. All nameserver for a zone are supposed to serve the same content "new" and "old" with differences only while the zone is waiting to be transfered. Just because lots of people just change the NS RRset without ensuring that the zone content remains consistent doesn't mean that it is right. > 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. There is nothing wrong with refreshing RRsets provided the zone is being properly managed. > 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=E5vard > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
