When the config has "dnssec-validation auto;", BIND attempts to validate all answers, and stops checking once it gets to a DNS zone that has no signatures. Categorically, all TLDs have signatures, so the lack of a signature on the .maas DNS zone is fatal to the DNSSEC validation.
If the domain in question were "maas.example.com", then the validation would proceed as follows (while being a bit handwavy about the specifics of requests, I admit): 1) verify the .com signature 2) verify the .example.com signature (if any, otherwise declare success: done validation) 3) verify the .maas.example.com signature (if any, otherwise declare success: done validation) 4) verify the signature for machine.maas.example.com (if any, otherwise declare success: done validation) BIND doesn't care if you're a primary or a secondary or caching - it's validating the RRset, not the server. I am not aware of any distinction in BIND wrt "not an official TLD" -- Note also that if you wanted to set that, you would have to set it as an enterprise wide configuration option on every resolver, which does not scale. As far as saner default MAAS domain names, that warrants more discussion. A non-exhaustive list: 1) default to a subdomain of the the FQDN of the region, minus the first lable. (mymaashost.example.com becomes maas.example.com) Pro: The admin is very likely the admin of example.com. Con: the second time you do this, you have duplicate domains, and if they ever need to talk to each other, there is a rename... 2) default to the FQDN of the region (mymaashost.example.com becomes the default domain name) Pro: we have good confidence that we OWN this point in the DNS tree, and its descendants. Con: upstream quite possibly controls our address set, and delegation at this point means that we become authoritative for the addresses, while upstream needs them for glue. Changing the upstream-facing IP of the server becomes a more difficult process 3) default to maas.FQDN of the region (mymaashost.example.com becomes maas.mymaashost.example.com) Pro: we definitely control everything from that down. Cons: likely redundant. Whatever the domain is, we should (at least in the docs) be telling the admin what to add to the parent DNS zone to properly delegate (and maybe even have secondaries..) the DNS for the MAAS region. At what point DNSSEC signatures stop is left as a discussion for upstream DNS. MAAS generating signatures is the subject of https://bugs.launchpad.net/maas/+bug/1620662 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1500683 Title: By default DNSSEC is enabled with automatic keys To manage notifications about this bug go to: https://bugs.launchpad.net/maas/+bug/1500683/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
