[2.0rc1] MAAS does not respect default subnet's DNS server when choosing default DNS

Bug #1576116 reported by Jacek Nykis
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
High
Unassigned
1.9
Won't Fix
Medium
Unassigned
2.0
Fix Released
High
Unassigned

Bug Description

I deployed a system that uses external DHCP. Everything worked fine with exception of extra DNS server added to the config. This extra resolver is MAAS region controller and my systems don't have access to it on port 53. This causes delays in DNS resolution which then affects ssh and other things so we need to remove it before we can use the system in production.

I noticed that the problematic entry is added to the loopback interface:
auto lo
iface lo inet loopback
    dns-nameservers 91.189.XX.XX
    dns-search maas master-XXX

Adding region controller as resolver can be useful in some scenarios but it will break in others, especially in bigger environments with firewalls between subnets.

Can you provide option to control this feature on per subnet basis?

un maas <none> <none> (no description available)
ii maas-cli 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS command line API tool
un maas-cluster-controller <none> <none> (no description available)
ii maas-common 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS server common files
un maas-dhcp <none> <none> (no description available)
ii maas-dns 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS DNS server
ii maas-proxy 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS Caching Proxy
ii maas-region-controller 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS server complete region controller
ii maas-region-controller-min 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS Server minimum region controller
ii python-django-maas 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS server Django web framework
ii python-maas-client 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS python API client
ii python-maas-provisioningserver 1.9.1+bzr4543-0ubuntu2~trusty1 all MAAS server provisioning libraries

Related branches

Revision history for this message
Andres Rodriguez (andreserl) wrote :

Hi Jacek,

MAAS doesn't support full external DHCP / DNS. And it will always use MAAS' region as DNS server, provided that is in MAAS where you assign the names of the machines will have on deployment.

You can, however, add a different resolver per subnet in MAAS, however, again, MAAS region will always be added.

Now the fact that it is adding it to loop back is strange provided that MAAS doesn't write loop back interface. Can you provide your e/n/I and get the curtin config for such node?

summary: - MAAS adds regions controller as DNS resolver
+ DNS resolver added to loopback
Changed in maas:
status: New → Incomplete
Revision history for this message
Jacek Nykis (jacekn) wrote : Re: DNS resolver added to loopback

I uploaded curtin and /etc/network/interfaces here:
https://private-fileshare.canonical.com/~jacek/lp1576116.tgz

Please don't share outside of the company.

We have been using full external DHCP for some time and it always worked for us. I don't mean to say that this method is good or should be supported just want to point out that even if unsupported it still works just fine. I think it's unrelated to this problem though.

I can think of situations where adding MAAS as resolver on every host will cause problems. For example if MAAS DNS does not have full view of all zones but you force it on top of what is coming from DHCP or config management systems can end up with intermittent resolution problems for some hosts.
Another scenario is one we've just hit - firewalls blocking access to MAAS DNS.

If this behaviour can't be changed maybe there is a way to make it more visible and obvious to avoid surprises?

Changed in maas:
status: Incomplete → New
Revision history for this message
Blake Rouse (blake-rouse) wrote :

The MAAS DNS nameserver being added to loopback is correct. This is not MAAS doing this but curtin. We tell curtin that the DNS nameserver for the MAAS region is a global nameserver meaning it should be used on all interfaces no matter what. That tells curtin to place it into the loopback interface. The loopback interface is always up and resolvconf will read that data an place it into the resolv.conf.

If this was not placed into the loopback curtin would need to place it under resolv.conf.d/base because it would not work any where else in the /e/n/i config. This was a previous bug that curtin had and was resolved by placing the global DNS nameservers on the loopback interface.

summary: - DNS resolver added to loopback
+ MAAS adds regions controller as DNS resolver
Changed in maas:
milestone: none → 2.0.0
status: New → Triaged
Gavin Panella (allenap)
Changed in maas:
status: Triaged → New
Changed in maas:
milestone: 2.0.0 → 2.1.0
Changed in maas:
status: New → Triaged
importance: Undecided → High
Changed in maas:
status: Triaged → Fix Committed
Revision history for this message
Mike Pontillo (mpontillo) wrote : Re: MAAS adds regions controller as DNS resolver

We currently have no plans to backport this to MAAS 1.9, since it would change the behavior post-release, so could have an impact on existing deployments.

Revision history for this message
Haw Loeung (hloeung) wrote :

Mike, there's an option to enable/disable APT proxy in 1.9 ("Enable the use of an APT and HTTP/HTTPS proxy"), can't we have something similar for DNS ("Enable MAAS controller as DNS resolver")?

summary: - MAAS adds regions controller as DNS resolver
+ [1.9,2.0rc1] MAAS does not respect default subnet's DNS server when
+ choosing default DNS
summary: - [1.9,2.0rc1] MAAS does not respect default subnet's DNS server when
- choosing default DNS
+ [2.0rc1] MAAS does not respect default subnet's DNS server when choosing
+ default DNS
Changed in maas:
status: Fix Committed → Fix Released
milestone: 2.0.1 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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