[dns-operations] Discarding bad records from an AXFR

[Edward Lewis]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20130731/ae41f467/attachment.html>