MAAS not forwarding DNS

Bug #1688644 reported by Kevin Buretta
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MAAS
Triaged
High
Unassigned
2.2
Triaged
High
Unassigned

Bug Description

MAAS Version 2.1.5+bzr5596-0ubuntu1 (16.04.1)
All nodes provision (16.04) and deploy (12.04 HWE-T) successfully. However...

I believe that I have set up my MAAS server to do DNS forwarding to my primary DNS server so that my nodes will be able to do DNS Lookups.

I have added the correct gateway and DNS server (Primary DNS) to the subnet which contains my MAAS server as well as all of my nodes. The main purpose for this network arrangement is that when fully orchestrated my nodes will need to be discoverable to other domain machines and their resolutions/reservations are all present in Domain DNS/DHCP.

If I look in a particular nodes /etc/resolv.conf I see all applicable DNS listed.

The first IP listed is my MAAS server
The following two are primary and secondary DNS.
The problem is that when a node tries to ping a domain IP it will be successful, but it cannot ping or nslookup any DNS names because it's primary DNS in order is MAAS first.

I have set up 10.1.5.45 10.1.5.46 as the "Upstream DNS used to resolve domains not managed by this MAAS" in the settings page and see these values present in the MAAS server's /etc/bind/maas/named.conf.options.inside.maas as forwarders. I have already turned dnssec off on the MAAS server per another article and so this file also reports "dnssec-validation no;"

I have tested removing the MAAS server IP from my nodes /etc/resolv.conf and after removal it successfully resolves all domain names that I require for further orchestration. But of course this removal is not persistent as it would be added back in at the top of the list if the node was ever restarted.

===> [NODE] slurm01:/etc/resolv.conf <===
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 10.1.30.199
nameserver 10.1.5.45
nameserver 10.1.5.46
search brivmrc.org maas BRIVMRC.ORG

===> [MAAS] srvmaas02:/etc/bind/maas/named.conf.options.inside.maas <===
forwarders {
    10.1.5.45;
    10.1.5.46;
};

dnssec-validation no;

allow-query { any; };
allow-recursion { trusted; };
allow-query-cache { trusted; };

-------------------------------------------------------------------------------------------------------
To recreate this problem: Try provisioning and deploying nodes intended for Domain DNS/DHCP control while using MAAS 2.1 only as a forwarder.

Expected results: Nodes will have the relevant DNS servers listed in their resolv.conf but they will have the MAAS server listed first and it will not pass DNS queries to the forwarders as listed in settings. Note also that in my case the Upstream DNS was populated with the correct IP address prior to the provisioning and deployment of the nodes, and both server and nodes have incurred a full reboot but still experience this issue.

Tags: dns
Revision history for this message
Kevin Buretta (kburetta) wrote :

Additional Finding, Nodes can reach fully external resolutions like www.google.com but they cannot ping internal domain resources through the forwarder. The MAAS server can ping both internal and external resolutions however.

This finding indicates that the forwarder is partially functional as the nodes should not be able to resolve anything without it. Why the internal DNS zone is excluded from what it can forward is currently unknown to me.

Changed in maas:
status: New → Incomplete
status: Incomplete → New
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Kevin,

I wonder if this is the same bug as yours: https://bugs.launchpad.net/maas/+bug/1670886

Can you try adding what's suggested in that bug report and see if that fixes the problem ?

tags: added: dns
Changed in maas:
milestone: none → 2.3.0
importance: Undecided → High
status: New → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.