On 2/25/15, 9:03, "Havard Eidnes" <h...@uninett.no> wrote: >Hmm. > >Firstly, isn't this "child-centric resolver" / "parent-centric >resolver" simply an euphemism papering over the more distinct >"correctly" and "wrongly" implemented resolver?
That’s my thought exactly. (But that doesn’t mean the terms needn’t be given definitions.) >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. To put a sharper point on this, this is documented as “trustworthiness” in “Clarifications to the DNS Specification” [RFC 2181] inside section 5.4.1 on “Ranking Data." I’ve seen a case of a resolver that favored the parent NS set over a child NS set (and glue), which led to a cache poisoning event. A delegation that was transferred forgot to remove the glue records in the TLD, an apparently disgruntled employee aware of this left the company, registered a new domain that made use of the glue record. (I’m omitting details to make this quick.) The net result is that the caches following this model quickly favored the stale glue over the fresh authoritative answer, victimizing the registrant. Nevertheless, giving the practice a name will make it easier to explain to someone why it’s a bad idea. > 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. And/or the glue. >>Phantom domain: ... > >Again, I'd simply call a resolver allowing this situation to persist >to be "wrong/buggy". In operations, you have to deal with the bad a lot - in fact, by the very nature of the bad being bad, you deal more with the bad than the good. (The good is hidden under automation.) Giving names to the bad is very helpful for that reason. (Root cause voice call recordings, staff turnover, these are places where common terminology is helpful regardless whether the term describes something good or something bad.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
