DNS NS Record - why default domain name?

Users
#1

I digged into the source to find out why my MAAS DNS controller puts a wrong NS record in my default zone (missing a dot at the end of rrdata and thus creating a “default_domain.default_domain” record).

I didn’t find an answer, so my question would be: has anyone an idea why the NS record for a subdomain (or for any authoritative domain it seems) must be the default domain name? This is a deviation from the usual way to delegate domains.

And if this is indeed intentional, I would consider this a bug:

https://github.com/maas/maas/blob/master/src/maasserver/models/domain.py#L309

Using a domain name and not a label without checking for the ending dot is creating the above mentioned “default_domain.default_domain” issue and leading to bind ignoring this record alltogether:

named[12842]: zone default_domain/IN: subdomain.default_domain/NS 'default_domain.default_domain' has no address records (A or AAAA)

Any idea anyone what is going on here or why it was designed this way?

Should I file a bug?

#2

Hi @te-8,
While I can see how this rather old behavior is not ideal, it’s technically not wrong with regards to DNS, as for instance
dig @<maas dns server> my.subdomain NS returns
my.subdomain. 30 IN NS <default domain>.
Which in turn should be resolved to the proper IP.

There are many approaches to doing this, I feel what you’re intending is more so the best practices way of doing so, however I feel the ideal solution here would actually be to allow the user to set the NS record for a given domain in MAAS. Which would be a feature request rather than a bug.

#3

Hi,

thanks for the input. The reason why you see this result (assuming your maas installation has the same issues as mine) would be that if you are queriing the same server for the subdomain where the parent domain resides, bind collapses the zones information and finds the subdomains DNS server address in the subdomain. Nonetheless you should find an error in your bind log complainign about a non-resolvable NS record in the parent zone.

As far as I can see this all works only by accident.

Would you mind checking if you also have the above mentioned error in your logs? I am still wondering if maybe I made a mistake somewhere along the road…

Thank you!