Non-standard .in-addr.arpa zones cause the migration to fail

[peteeckel]

Thanks to @wolfspyre I became aware of a problem with the migration that updates the arpa_network field in reverse zones.

If an RFC 2317 reverse zone is present in the database, currently (due to the lack of RFC 2317 support in NetBox DNS) the arpa_network calculation fails with an AddressFormat exception while handling its Zone object. While this is expected, there is a typo in the exception handler that catches it, and so the whole migration fails. See discussion #270 for details.

[wolfspyre]

You made my day!

Thanks a bunch.

I wasn't sure about the 2317 formatting issues... it looked like exception handling was able to appease netaddr, or at least tell it

yes, yes, I know... thank you...

and continue with the migration once the uone -> zone alteration was made: (sed to the 'rescue' ... well... admittedly sed's response was more akin to:

Are you kidding me? Really? You want me to do what?? sigh ... Okay fine...

)

root@pandora-01:/data/docker/overlay2# for file in `find . |grep 0018_zone_arpa_network.py`; do 
  sed -ie 's/uone.arpa_network/zone.arpa_network/' ${file};
  rm "${file}e";
done

Is there a formatting standard that netaddr DOES consider valid for subnet notation?

IF SO, aligning to that might be the least painful way forward... seeing as this is the formatting arbiter in netbox, it's likely to bite us in other ways elsewhere... but... ¯\_(ツ)_/¯

[peteeckel]

Hi @wolfspyre, thanks for the feedback!

Regarding the netaddr stuff - just ignore it for the time being. The arpa_network field in the model is there for the purpose of matching reverse zones to IPAM prefixes, and it will gain some functionality with RFC 2317 later on.

The current logic is: If the domain name of an .arpa zone is a standard domain name for non-RFC 2317 delegation, derive the subnet from the name. If not, forget it. The main reason is that there is no standard for naming RFC 2317 zones (one of the aspects in which the RFC is rather sloppy), so there will not be a way to derive the subnet from the zone name. Essentially, you can name the zone whatever you want and just tell it explicitly which subnet it is for.

[wolfspyre]

sweet! well, cool! mischief managed.