nsd users - Mar 2013 - 'deeper' labels and a covering NS delegation

Hi,

I did something silly in the following form:

8<----------------------------
$TTL 14400
$ORIGIN example.org.

@ IN SOA localhost. dns.example.org. (2013022402 10800 3600 2419200 14400 )
                                NS ns1.example.net.
                                NS ns2.example.net.
                                NS ns3.example.net.

test.very.deep.label.subdomain TXT "Deep Label"

subdomain                       NS ns1.example.net.
                                NS ns2.example.net.
                                NS ns3.example.net.
---------------------------------->8

Fun detail in this silly thing is that we do not provide
subdomain.example.org to nsd, that is we do not configure it.

The 'test.very.deep.label.subdomain' apparently can never be queried as
the NS entry overrules it and thus we just get an endless redirect to
ns1/2/3.example.net (till the DNS client gives up rightly ;).

For silly people like me, it would I think be a good idea to at least
warn about the above case, that is the deeper label, the re-delegation
to the same host is a standard delegation thing and a misconfiguration
which though could be valid; the deeper label should never be valid though.

A 'nsdc rebuild' will silently proceed without any warning.
(On nsd 3.2.9-1 that is)

Greets,
 Jeroen

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeroen,

On 03/05/2013 02:53 PM, Jeroen Massar wrote:
> Hi,
> 
> I did something silly in the following form:
> 
> 8<---------------------------- $TTL 14400 $ORIGIN example.org.
> 
> @ IN SOA localhost. dns.example.org. (2013022402 10800 3600 2419200
> 14400 ) NS ns1.example.net. NS ns2.example.net. NS
> ns3.example.net.
> 
> test.very.deep.label.subdomain TXT "Deep Label"
> 
> subdomain                       NS ns1.example.net. NS
> ns2.example.net. NS ns3.example.net. 
> ---------------------------------->8
> 
> Fun detail in this silly thing is that we do not provide 
> subdomain.example.org to nsd, that is we do not configure it.
> 
> The 'test.very.deep.label.subdomain' apparently can never be
> queried as the NS entry overrules it and thus we just get an
> endless redirect to ns1/2/3.example.net (till the DNS client gives
> up rightly ;).
This is by design.  The TXT record is occluded and is not served.
This situation happens normally when a master (a dynamic update
configured machine) is removing a part of a zone to replace it with a
delegation to a remote machine.  To make this atomic, the delegation
is placed first (and takes precendence) and then the TXT record and
other records can be removed piecemeal.

You can also move in reverse.  Put the zone content in place record by
record and then remove the NS records at once to atomically place the
subdomain inside the example.com zone with all its records.
> For silly people like me, it would I think be a good idea to at
> least warn about the above case, that is the deeper label, the
> re-delegation to the same host is a standard delegation thing and a
> misconfiguration which though could be valid; the deeper label
> should never be valid though.
> 
> A 'nsdc rebuild' will silently proceed without any warning. (On nsd
> 3.2.9-1 that is)
Yes, because it is a valid situation during certain dynamic update
transactions.  And NSD does not know what is going on, since the
master performs the dynamic updates.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRNf+SAAoJEJ9vHC1+BF+NWRMQAJSTd9khAk8nChz72xzwMCmX
t6FFWr4FNQNCaRM1XtmMw2J1W8axuabig8Gd/A46CjeYisPgOHLy7xi3/683Ok8U
eZht2QI6QOa1bpaxnBc1cbDtaOXWCeB5mj1lJRVZ+OUnWEkR0wPeGQpBiF1sj83z
kIF6/e/kK8oiwW6JCZhBoy7s4XjRGSk5bkiBSRgyHgHZzRfXSGB5RnwGhQUL0Y4p
jUCVwvJMqblq/xf+1ex61VP+MnzG0SNbQf2OfrlOzzgfLr0J3P74x1Ehtbc6nmj5
PJBSb34aF2YqC8VnqLc60fjvpWI/Dn/cdl2IkNbUu9jyt/bqNneLhAAi0trMJIeU
mawcL5G3gR0OThRMggKtZZetwBPj+SnU8gdrf7l9zRzsSfXG1FAtSjka03VBdMXf
RGg/p1GzvfBgEe6TAr4C6n0u7cARFgTjMi4jEs9/1GYlV85Do3RvB+pXMoCNHvQT
ShC6mVrPVAsFHXsAPHGLRA6XVD6U5oy0zDRYMWGjdi9pBAewAAY4L0Ko9Gobqg6U
BeYN3PwdxnCKb8GjEzCDU7eli23OYHnF/N1Vgq9Gz06scOxUsE4jC77z2x1r2G/k
UjOmuPoysPRmIqnaN4sZHn82j8GPCc14HDuvUM0w5Cw/8aqKwXzcSrxQU7eqfiKJ
ySC36g5wjxVi54awVxQk
=6e2i
-----END PGP SIGNATURE-----