'deeper' labels and a covering NS delegation

NSD
1

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

2

Hi Jeroen,

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

3

[...]

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.

That explains, thanks.

Still something for people to watch out for when making broken configs :wink:

Greets,
Jeroen