Classless zone (RFC 2317) name format

[Wallpix]

There are 3 different format for sub class C arpa (reverse) zones. I have an error parsing the following:

<octet4>/<mask>.<octet3>.<octet2>.<octet1>.in-addr.arpa

This is the error:

pyparsing.exceptions.ParseSyntaxException: , found '/'  (at char 35000), (line:1731, col:10)

Where the zone is something like this:

zone "128/27.0.0.10.in-addr.arpa" 

If I change the slash to a dash, it is parsed properly.

zone "128-27.0.0.10.in-addr.arpa" 

So the following notation works

<octet4>-<mask>.<octet3>.<octet2>.<octet1>.in-addr.arpa

But I was expecting the previous one to also work. The 3rd annotation also works.

<address_range_from>-<address_range_to>.<octet3>.<octet2>.<octet1>.in-addr.arpa

[egberts]

Dang.

This is really an issue of a specific string type used with only the zone name that is found in ISC Bind9 (as opposed to using valid DNS or IP-address convention).

In the string charset of its zone name, slash (and backslash) characters are prohibited in p arse_bind (or Bind9?) named-config-specific zone names for some reason and I need to find out why.

It is allowed in the ISC code base but it became (oh, I remember now) problematic for it is the PyParsing that is NOT ALLOWING slash/backslash charsetr in a Python string index names (as well as variable names).

Such example of Python string index name is:

zone['128/27.0.0.10.in-addr.arpa'].name

would NOT work because slash character does not work in Python index string.

But this one should work:

zone['128_27.0.0.10.in_addr.arpa'].name

Downside to a workaround is to remap the unsupported characters for usability within its Python index naming convention.

Additional studies tells me that this will be a hindrance in order to gain parsing capability of Bind9 ... with PyParsing and Python.

Simply remaping / into underscore will open up the risk of double mapping of zone names to same index; this approach is something I [will not, scratch that] might do just to comply with Python's index naming convention.

Pray tell, are you using some kind of automated tools that is generating these "esoteric" (but valid) zone names?

[Wallpix]

I came upon this zone format for a migration project of mine. This notation was most likely entered by a human. But Infoblox is also compliant with this naming (with slash). They use ISC BIND in the backend of their solution.

    zone "128/27.0.0.10.in-addr.arpa" in { # 128/27.0.0.10.in-addr.arpa
	type master;
	database infoblox_zdb;
	masterfile-format raw;
	file "azd/db.128#27.0.0.10.in-addr.arpa._default";
	notify yes;
    };

There probably should be some kind of error thrown for this saying something in the lines of "we do not support / in classless zone format, please replace with -". Or automate this transformation. At least the documentation should probably reflect this limitation.

[egberts]

Current design document

• replacing slash(/) and backslash(\) into underscore ONLY for all zone names used, if any were found.
  • fairly easy to impement
• output warning message during reading of parser that substitution "occurred".
  • this is harder since PyParsing offers little hook routines for interim (middle-of-parsing) actions.

[egberts]

See StackOverflow by extraordinaire Paul McGuire (@ptmcg):

expr = Literal("/").setParseAction(replaceWith("_")) + "/"
print expr.parseString("zone "128/27.0.0.1 {};").asList()

More of those .replaceWith() methods used by other Open Source codes over here

[Wallpix]

I would change the slash ( / ) to a dash ( - ) for the nomination to be valid for Bind. I don't think underscore ( _ ) would parse properly in Bind.

[egberts]

Underscore works well for zone name. Even square brackets too!!!

But i ran into some issues with other non-alphanum characters, and need to recheck on the minus symbol for used within this one named index used in Python array variables.