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

[Anand Buddhdev]

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.

However, if the zone operator uses dynamic update to remove these DNAME
or NS records, BIND records that change in a journal, and serves up
IXFRs from this journal. The dynamic update will not trigger
re-evaluation of all the other names in the zone, to see if they need to
be occluded or revealed. That would probably cost a lot of computation
for large zones.

In cases where the master and slave are both BIND servers, such names
below DNAMEs and delegation points are not a problem. The problem occurs
when BIND is a master to Knot or NSD. Knot accepts an IXFR to add/remove
DNAMEs, and keeps running, and providing answers for names below the
DNAMEs, but when restarted, fails to load the zone. NSD doesn't ever
appear to care about this, and will keep answering for the name below
the DNAME.

This problem with IXFRs changing DNAMEs and NS records is more difficult
to solve, because it means that name server must recompute the entire
tree of a zone when receiving an IXFR, and this is expensive. I do
sympathise with name server developers here.

Anand