[dns-operations] Knot and NSD handling names below DNAME incorrectly

[Mukund Sivaraman]

On Sun, Apr 03, 2016 at 12:13:26PM -0300, Anand Buddhdev wrote:
> On 03/04/16 08:23, Matthew Pounsett wrote:
> 
> >> No. If you do that you break what is returned if the DNAME is removed via
> >> IXFR.  Slaves need to transmit the entire zone content as learnt.
> > 
> > Wouldn't that cause the A record to no longer be occluded, and
> > therefore show up in the same IXFR where the DNAME is removed?
> 
> I don't think that's how BIND works. When it loads a zone, it will
> occlude names under DNAMEs or delegation points (NS records) when
> answering queries. The records are all held in memory, but when looking
> them up, they are ignored.
> 
> BIND is being lenient in what it accepts, and conservative in what
> responses it sends out. Since it keeps all the records in memory, it
> will provide these occluded names in an AXFR.

From RFC 5396 section 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.

		Mukund
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160404/a40dd434/attachment.sig>