DNS NS Record - why default domain name?

te-8 · 29 August 2023 13:54

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:

github.com

canonical/maas/blob/master/src/maasserver/models/domain.py#L309


      
          # this domain.
          for middle in possible:
              subdomains = subdomains.exclude(name__endswith="." + middle.name)
          for subdomain in subdomains:
              nsttl = subdomain.get_base_ttl("NS", default_ttl)
              ttl = subdomain.get_base_ttl("A", default_ttl)
              # Strip off this domain name from the end of the resource name.
              name = subdomain.name[: -len(self.name) - 1]
              # If we are authoritative for the subdomain, then generate the NS
              # and any needed glue records.  These will automatically be in the
              # child zone.
              if subdomain.authoritative:
                  mapping[name].rrset.add((nsttl, "NS", ns_host_name))
                  if ns_host_name.endswith("." + self.name):
                      # The ns_host_name lives in a subdomain of this subdomain,
                      # and we are authoritative for that.  We need to add glue
                      # to this subdomain.
                      ns_name = separate_fqdn(ns_host_name, "NS", self.name)[0]
                      for addr in dns_ip_list:
                          if IPAddress(addr).version == 4:
                              mapping[ns_name].rrset.add((ttl, "A", addr))

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?

cgrabowski · 29 August 2023 18:01

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.

te-8 · 30 August 2023 08:37

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!