MAAS accepts 0.0.0.0/0 as a subnet, but this breaks DNS update code

Bug #1672947 reported by James Hebden
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
MAAS
Fix Released
Medium
Mike Pontillo
2.3
Fix Released
Medium
Mike Pontillo

Bug Description

MAAS 2.1.4+bzr5591-0ubuntu1~16.04.1

It is currently possible to configure 0.0.0.0/0 as a subnet when creating/modifying a subnet in a MAAS fabric.

This creates two issues:

* Any hosts that are deployed after the subnet is created will be assigned to this subnet, even if more specific subnets exist. This could be a UI bug however, in that IPs are being shown that fall under 0.0.0.0/0, but the IPs are assigned to the more specific and correct CIDR also configured in the same fabric. I haven't yet dug into the database to confirm, but suspect this is not necessary.

* Any attempt made by hosts that fall under this new broad subnet will cause the stack trace in the linked paste on each DHCP renewal, and reverse DNS mapping generation will fail: http://pastebin.ubuntu.com/24180785/

I added additional logging temporarily to zoneconfig.py to confirm that the stack trace occured when processing

Note: I have redacted customer hostnames, IPs and hardware addresses in the output.

Related branches

Changed in maas:
milestone: none → 2.2.0
importance: Undecided → High
status: New → Triaged
importance: High → Medium
tags: added: canonical-bootstack
Revision history for this message
James Hebden (ec0) wrote :

I ended up digging into the DB further, and found that in our case, all of the IPs which ended up in the 0.0.0.0/0 subnet, were also BMCs defined in the MAAS DB BMC table. I was able to directly reassign them to the more specific subnet by manipulating the subnet ID of the static IP address entry in the database.

Once this was done, the 0.0.0.0/0 subnet showed no allocated IPs, and I was able to remove it. I chose to do this via the database instead of the UI, in case anything more than simply deleting the subnet occurs when removing a subnet in the UI.

description: updated
Changed in maas:
milestone: 2.2.0 → 2.2.x
tags: added: internal
Changed in maas:
milestone: 2.2.x → 2.3.x
Changed in maas:
milestone: 2.3.x → 2.4.x
Revision history for this message
Andres Rodriguez (andreserl) wrote :

Is there a reason we should allow 0.0.0.0/0 as a subnet? It seems to me that MAAS should not allow it?

Changed in maas:
status: Triaged → Incomplete
Revision history for this message
James Hebden (ec0) wrote :

I can't think of a valid reason to specify a subnet mask which does not narrow the scope of IP addresses at all - given 0.0.0.0/0 covers 100% of the IPv4 scope. The simple fix is to not allow it, and this will prevent breaking of DNS, and also prevent confusion when new IP are discovered, as when a 0.0.0.0/0 network is present all new IPs fall into this subnet, which is never desirable as intended behaviour.

James Hebden (ec0)
Changed in maas:
status: Incomplete → New
Changed in maas:
status: New → Confirmed
assignee: nobody → Mike Pontillo (mpontillo)
Revision history for this message
Mike Pontillo (mpontillo) wrote :

I'm adding a validation for this, but I'm a bit confused why a subnet like this was added in the first place. ;-)

Changed in maas:
status: Confirmed → Fix Committed
Changed in maas:
milestone: 2.4.x → 2.4.0alpha1
status: Fix Committed → Fix Released
Revision history for this message
Wouter van Bommel (woutervb) wrote :

Today we found that this bug is still present in MAAS version: 2.6.0 (7802-g59416a869-0ubuntu1~18.04.1)

This caused quite some issues with dns as zone's could not be updated, flooding the /var/log/maas/regiond.log file with stacktraces like:
2020-04-06 23:44:38 maasserver.region_controller: [critical] Failed configuring DNS.
        Traceback (most recent call last):
          File "/usr/lib/python3.6/threading.py", line 864, in run
            self._target(*self._args, **self._kwargs)
          File "/usr/lib/python3/dist-packages/provisioningserver/utils/twisted.py", line 861, in worker
            return target()
          File "/usr/lib/python3/dist-packages/twisted/_threads/_threadworker.py", line 46, in work
            task()
          File "/usr/lib/python3/dist-packages/twisted/_threads/_team.py", line 190, in doWork
            task()
        --- <exception caught here> ---
          File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 250, in inContext
            result = inContext.theWork()
          File "/usr/lib/python3/dist-packages/twisted/python/threadpool.py", line 266, in <lambda>
            inContext.theWork = lambda: context.call(ctx, func, *args, **kw)
          File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 122, in callWithContext
            return self.currentContext().callWithContext(ctx, func, *args, **kw)
          File "/usr/lib/python3/dist-packages/twisted/python/context.py", line 85, in callWithContext
            return func(*args,**kw)
          File "/usr/lib/python3/dist-packages/provisioningserver/utils/twisted.py", line 894, in callInContext
            return func(*args, **kwargs)
          File "/usr/lib/python3/dist-packages/provisioningserver/utils/twisted.py", line 235, in wrapper
            result = func(*args, **kwargs)
          File "/usr/lib/python3/dist-packages/maasserver/utils/orm.py", line 756, in call_within_transaction
            return func_outside_txn(*args, **kwargs)
          File "/usr/lib/python3/dist-packages/maasserver/utils/orm.py", line 563, in retrier
            return func(*args, **kwargs)
          File "/usr/lib/python3.6/contextlib.py", line 52, in inner
            return func(*args, **kwds)
          File "/usr/lib/python3/dist-packages/maasserver/dns/config.py", line 76, in dns_update_all_zones
            serial, internal_domains=[get_internal_domain()]).as_list()
          File "/usr/lib/python3/dist-packages/maasserver/dns/zonegenerator.py", line 430, in as_list
            return list(self)
          File "/usr/lib/python3/dist-packages/maasserver/dns/zonegenerator.py", line 394, in _gen_reverse_zones
            rfc2317_ranges=glue,
          File "/usr/lib/python3/dist-packages/provisioningserver/dns/zoneconfig.py", line 354, in __init__
            zone_info = self.compose_zone_info(self._network)
          File "/usr/lib/python3/dist-packages/provisioningserver/dns/zoneconfig.py", line 411, in compose_zone_info
            base = int(split_zone[rest_limit - 1])
        builtins.ValueError: invalid literal for int() with base 10: 'in-addr'

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.