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

[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.