I’m new to Incus. I’ve set up the basics with managed bridge based on the official docs, and now I’m trying to set up bind in a container, running the role of a secondary NS server that gets zone data for my network zone myzone.test from the primary, which is the Incus internal dns server. I can get the AXFR response from Incus with all containers’ FQDNs and their A / AAAA records in there, SOA record twice as should be, but the response is devoid of any NS record. Bind has a problem with such response, it doesn’t accept it and thus it doesn’t work, it won’t serve all the usual A records as it gets them from the AXFR response.
The relevant bind log:
managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer complete) managed-keys-zone: Key 38696 for zone . is now trusted (acceptance timer complete) zone myzone.test/IN: refresh: retry limit for primary 10.0.0.35#5353 exceeded (source 0.0.0.0#0) zone myzone.test/IN: Transfer started. 0x7f085f635000: transfer of ‘myzone.test/IN’ from 10.0.0.35#5353: connected using 10.0.0.35#5353 zone myzone.test/IN: has no NS records 0x7f085f635000: transfer of ‘myzone.test/IN’ from 10.0.0.35#5353: failed while processing responses: bad zone
How can I set up new NS record in the Incus internal NS server for the given network zone (myzone.test), so that it appears in its AXFR response?
We basically don’t know what the FQDN of the public DNS servers will be, so we can’t generate useful NS records out of the box. Setting dns.nameservers provides that information to Incus, at which point the zone should include the NS records.
incus network zone set myzone.test dns.nameservers=ns.myzone.test,ns2.myzone.test
and right after that, subsequent AXFR responses contain two NS records as expected. After some waiting and several rndc reloads, bind realized the change and now serves everything as expected.
I’ve encountered a strange thing though - if I set dns.nameservers to a hostname with a dot at the end:
incus network zone set myzone.test dns.nameservers=ns.myzone.test.,ns2.myzone.test. ,
requests for AXFR start failing. Is this an intentional behaviour in Incus? In DNS, if I recall correctly, the hostname variant with dot at the end is the canonical form. The usual one without the dot is just a convenient short-hand, so I’d expect Incus to accept also the canonical form with the dot…
I believe that normally no trailing dot would make it relative to the zone with the trailing dot making it canonical.
I’ve noticed most DNS providers these days don’t really implement it that way as that tends to cause more confusion than anything else
And in our case we’re asking for a list of DNS nameservers which would usually be expected to be FQDNs and not something relative to the current zone.
Anyway, I think we should just strip any trailing dot from the user provided value so it doesn’t matter if you provide a normal FQDN or a canonical record.
