On Jul 30, 2013, at 16:55, Anand Buddhdev wrote: > > What do you all think is the correct behaviour? Or are both correct?
There's some unwritten history here. First, these aren't "bad records" in the sense that they are malformed (at least I think this is what you are talking about). I.e., no 128 bit A records. ;) The word we have used in talking about these is "occluded" like when the moon passes "in front" of the sun. These are records that might have once been in zone but then a delegation point is added and they fall below the cut. From words I recall hearing from Mark Andrews, BIND took this path because sometimes people make mistakes. An operator of a complex zone might add an NS record that occludes many lower names. Then they "undo" the work. If the occluded records have been expunged from the AXFR's, they need to be re-inserted. Mark chose to leave them there and let the "algorithm" of DNS take care of the occlusion. I've sided our implementation with that view, retaining occluded records. "Correct" - that doesn't matter so much as interoperable - and in this case, what's more useful to an operator. (MTTR is an operational consideration, not a protocol engineering one.) PS - I then thought to check the RFC's. This says BIND is "right." (Self-fulfilling though, we wrote it that way because of Mark's reasoning.) RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010 3.5. Occluded Names Dynamic Update [RFC2136] operations, and in particular their interaction with DNAME [RFC2672], can have a side effect of occluding names in a zone. The addition of a delegation point via dynamic update will render all subordinate domain names to be in a limbo, still part of the zone but not available to the lookup process. The addition of a DNAME resource record has the same impact. The subordinate names are said to be "occluded". Occluded names MUST be included in AXFR responses. An AXFR client MUST be able to identify and handle occluded names. The rationale for this action is based on a speedy recovery if the dynamic update operation was in error and is to be undone. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses.
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
