<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jul 30, 2013, at 16:55, Anand Buddhdev wrote:</div><blockquote type="cite"><div><br></div><div>What do you all think is the correct behaviour? Or are both correct?<br></div></blockquote></div><div><br></div>There's some unwritten history here.<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I've sided our implementation with that view, retaining occluded records.<br><div><br></div><div>"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.)</div><div><br></div><div>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.)</div><div><br></div><div><pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: pre-wrap; ">RFC 5936 DNS Zone Transfer Protocol (AXFR) June 2010
</pre><pre style="color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; white-space: pre-wrap; ">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.
</pre><div><br></div><div apple-content-edited="true">
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span></span>-=-=-=-<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Edward Lewis <span></span> <br>NeuStar <span></span> You can leave a voice message at +1-571-434-5468<br><br>There are no answers - just tradeoffs, decisions, and responses.</div></div></div></span>
</div>
<br></div></div></body></html>