[Yeti DNS Discuss] A weird behavior of Knot

Carsten Strotmann carsten at strotmann.de
Tue Aug 18 06:21:12 UTC 2015


Hello Paul,

Paul Vixie wrote:
>> some additional information: the Knot-DNS version running at the time
>> was 2.0.0-r1. It has since been updated to 2.0.0 (the release version).
>> The weird behavior seen might have been an artifact of the
>> release-candidate version.
> 
> it's also worth testing online child zone removal in the new version. in
> bind4, a server that was authoritative for both dec.com and pa.dec.com
> would serve a damaged dec.com after the pa.dec.com zone was removed
> online (by "ndc reconfig"). the fix we used was ugly-- we just reloaded
> all parent zones of any removed zones.
> 
> knot may have similar problems. it's worth a specific test in the
> release version, even if yeti does not anticipate any more zone removals
> (since we only have one zone left.)
> 

the server instance was never authoritative for the ARPA child zone.

As far as I understand, there was a delegation for ARAPA from the
yeti-version of the root zone to the same NS set used to host the
yeti-dns version of the root-zone.

The knot DNS-server was only configured to be a slave for "." (and one
other zone, "dnsworkshop.org"), but never for ARPA, even though the
delegation for ARPA might have pointed to it (lame delegation).

After the delegation was fixed in the yeti DM, the new zone was
transferred, but from the information I was able to gather (and Kevin
had send), the dns server had somehow incompletely updated the zone. The
SOA serial was at the latest version, but the server was still
responding with old delegation information from a previous version of
the yeti-root zone.

The knot-dns process was in a hung state, it was not possible to remote
control it via "knotc" (the Knot-DNS equivalent of "rndc"), nor was it
responding to SIGHUP.

At the time the slave zone for "." on the server was configured to not
write the zone content to disk, so I was not able to inspect the backup
copy.

I had limited time to troubleshoot, I forgot to try AXFR from the
server, it might have worked. Will do it next time.

Since then I've also changed to configuration so that the zone content
is now written to disk.

I will run some test with the release version of Knot-DNS 2.0.0 in a
closed lab environment, see if I can recreate the situation. Once I find
something, I will report.

Best regards

Carsten

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 883 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20150818/dcf04f47/attachment.bin>


More information about the discuss mailing list