bind9 not enabled on rack controller

Users
1

Could anybody offer some pointers as to why bind9 is not enabled on my second rack controller in MaaS 3.7.1?

$ sudo /snap/bin/maas status
Service Startup Current Since
agent disabled active today at 14:38 UTC
bind9 disabled inactive -
dhcpd disabled active today at 19:00 UTC
dhcpd6 disabled inactive -
http disabled active today at 14:37 UTC
ntp disabled active today at 14:38 UTC
proxy disabled inactive -
rackd enabled active today at 14:37 UTC
syslog disabled active today at 14:38 UTC

It’s not showing up in the GUI as enabled either. I don’t see anywhere in the GUI to enable DNS on a rack server. The subnet exists as a secondary for DHCP and DHCP is working properly on the rack controller. MaaS is also advertising the primary and secondary rack controller via DHCP as DNS servers. Which is failing as DNS is not running on it.

Any ideas?

2

Hi @ry4nm1
What is the current configuration of the subnet?
Could you provide me with the output of maas $PROFILE subnet read <subnet_id> or alternatively look for the subnet in the networks page of the UI?

You should see an “allow_dns” option or “Allow DNS Resolution” checkbox respectively.

3

Hi @ry4nm1

That might be a valid bug. We moved to the custom implementation of the DNS resolver (provided by the agent service) so we no longer depend on bind9 when you install MAAS in a rack only mode. DNS should work, but I agree, seeing bind9 being disabled is very misleading.

Can you please confirm if you have your second rack controller installed as maas init rack and that this issue does happen only in this case?

4

Success.
Machine-readable output follows:
{
“name”: “192.168.0.0/22”,
“description”: “”,
“vlan”: {
“vid”: 0,
“mtu”: 1500,
“dhcp_on”: true,
“external_dhcp”: null,
“relay_vlan”: null,
“id”: 5002,
“name”: “untagged”,
“space”: “NAT-Space”,
“fabric_id”: 1,
“primary_rack”: “7gr7rw”,
“fabric”: “1G-maas-fabric”,
“secondary_rack”: “emsfad”,
“resource_uri”: “/MAAS/api/2.0/vlans/5002/”
},
“cidr”: “192.168.0.0/22”,
“rdns_mode”: 2,
“gateway_ip”: “192.168.0.1”,
“dns_servers”: [
“192.168.0.53”,
“192.168.0.5”
],
“allow_dns”: true,
“allow_proxy”: true,
“active_discovery”: true,
“managed”: true,
“disabled_boot_architectures”: ,
“id”: 2,
“space”: “NAT-Space”,
“resource_uri”: “/MAAS/api/2.0/subnets/2/”
}

It’s interesting that the dns_servers here are .5 and .53. .4 is the region/rack controller, .5 is my secondary rack controller, and .53 is an external DNS server. I wonder why .4 is not in the list…

The DHCP server is handing out:
DNS Servers . . . . . . . . . . . :
192.168.0.5
192.168.0.4
192.168.0.53
192.168.0.5

Which is also weird that it’s providing .5 twice.

5

Yes, the second rack controller was installed with:

maas init rack –maas-url –secret XXXXX

OK, maas-agent is actually listening on udp/tcp 53. I wasn’t looking for another process on 53, just looking for bind9 before…

$sudo ss -alpn | grep 53
u_str LISTEN 0 4096 /run/lvm/lvmpolld.socket 5365 * 0 users:((“systemd”,pid=1,fd=111))
u_str LISTEN 0 4096 /run/systemd/fsck.progress 5368 * 0 users:((“systemd”,pid=1,fd=117))
u_str LISTEN 0 4096 @/org/kernel/linux/storage/multipathd 5367 * 0 users:((“multipathd”,pid=528230,fd=3),(“systemd”,pid=1,fd=126))
udp UNCONN 0 0 192.168.0.5:53 0.0.0.0:* users:((“maas-agent”,pid=1142,fd=30))
udp UNCONN 0 0 192.168.240.5:53 0.0.0.0:* users:((“maas-agent”,pid=1142,fd=28))
udp UNCONN 0 0 127.0.0.54:53 0.0.0.0:* users:((“systemd-resolve”,pid=635,fd=16))
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* users:((“systemd-resolve”,pid=635,fd=14))
tcp LISTEN 0 4096 192.168.240.5:53 0.0.0.0:* users:((“maas-agent”,pid=1142,fd=29))
tcp LISTEN 0 4096 192.168.0.5:53 0.0.0.0:* users:((“maas-agent”,pid=1142,fd=31))
tcp LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* users:((“systemd-resolve”,pid=635,fd=17))
tcp LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:((“sshd”,pid=11136,fd=3),(“systemd”,pid=1,fd=153))
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* users:((“systemd-resolve”,pid=635,fd=15))

But it’s not responding to anything on the interface IP:
$ dig -t A www.google.c @192.168.0.5
;; communications error to 192.168.0.5#53: timed out
;; communications error to 192.168.0.5#53: timed out
;; communications error to 192.168.0.5#53: timed out

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t A www.google.c @192.168.0.5
;; global options: +cmd
;; no servers could be reached

But it is responding on the .54 loopback:
dig -t A www.google.c @127.0.54

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -t A www.google.c @127.0.54
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
; COOKIE: b7227167f0987ab00100000069a5813e4bddf982b249939c (good)
;; QUESTION SECTION:
;www.google.c. IN A

;; ANSWER SECTION:
www.google.c. 296 IN A 142.251.40.228

;; Query time: 2 msec
;; SERVER: 127.0.0.54#53(127.0.54) (UDP)
;; WHEN: Mon Mar 02 12:23:26 UTC 2026
;; MSG SIZE rcvd: 87

So, this looks like a filtering issue. iptables/nftables are not deployed. Any ideas?

6

MAAS doesn’t modify iptables/nftables during installation

7

It looks like the DNS agent on the rack controller is not respecting the “forwarder” option in the maas configuration and trying to query public DNS servers directly. In my case, this is running in an environment where the IT firewalls block all DNS except to their DNS servers which I need to use as a forwarding.

8

Do you see this in a region+rack controller or in a rack-only controller?

9

@ry4nm1 can you please paste the contents of your /etc/resolv.conf

10

region-rack is fine, problem is on the rack-only controller.

11

This is on the rack-only controller.

nameserver 127.0.0.53
options edns0 trust-ad
search

12

Then it’s definitely the new recursive resolved that was introduced in 3.7. Do you mind opening a bug please?

13

You are right. New resolver is using 127.0.0.1:53 (systemd-resolved) for everything except MAAS authoritative zones. This is definitely a bug/implementation issue as all requests on the rack previously were sent to the region.

I wonder if adding region’s IP under /etc/resolv.conf would help you to resolve the issue for now?

14

nvm, I opened it https://bugs.launchpad.net/maas/+bug/2143883

15

@ry4nm1

Another workaround suggestion is to update /etc/systemd/resolved.conf by setting these options:

#DNS=
#FallbackDNS=
16

It doesn’t seem to be working. The rack-controller’s resolved is set to use the region-controller as the DNS server and the rack-controller is still spewing DNS queries to upstream DNS servers.