A minor documentation issue & consideration of parsing inconsistencies in IPv4s in address match lists and in a controls/inet statement

Description

This was discovered during a course. It was confusing for students, but nothing is really wrong except perhaps a minor issue in the ARM.

1. Quick overview:

   • The first of these statements is valid, the last two are not:

     controls { inet 127.0.0.1 allow { 127.1; } keys { "XXkey"; }; };

     controls { inet 127.1 allow { 127.0.0.1; } keys { "XXkey"; }; };

     controls { inet 127.1 allow { 127.1; } keys { "XXkey"; }; };

   • Without other information, comparing the statements above, it is difficult to understand why 127.1 is permitted in one location, but not the other.
   • Someone used to using 127.1 on the command-line is likely to misinterpret the meaning of 127.1 in an Address Match List.

2. Address Match Lists accept IPv4 addresses with less than four octets and without a netmask.

   • Example: 177.44.8 is parsed as 177.44.8.0/32
   • Example: 127.1 is parsed as 127.1.0.0/32
   • This is reasonable. However, it is worth noting that it is very different than the parsing on the command line using commands such as dig and ping:
     • ping 177.44.8 is parsed to ping 177.44.0.8 (not to 177.44.8.0)
     • dig @127.1 is parsed to dig @127.0.0.1 (not to @127.1.0.0)
     • Particularly because dig and named.conf are both part of BIND, the inconsistency is understandably confusing at first glance.
     • For 127.1, I presume most people using it in an Address Match List would incorrectly think it parses to 127.0.0.1.
   • Note: As I read it, there is a documentation issue on page 51 of the 9.14.3 ARM in the definition of ipv4_addr:
     • ipv4_addr: An IPv4 address with exactly four elements in dotted_decimal notation.
       • However, Address Match Lists access IPv4s with less than four elements.
     • Possible correction:
       • ipv4_addr: An IPv4 address in dotted_decimal notation. If there are less than four elements, the remainder are taken to be zero.
     • AFAICT, the definition of ip_prefix does not come into play because there is no slash in the address.

3. The inet statement in a controls statement does not accept an IPv4 with less than four octets.

   • If it did, the parsing would need to match the what one gets on the command-line, and differ from an Address Match List.
     • 127.1 would need to parse to 127.0.0.1.
     • "Quick overview" above has examples.

Request

1. Change the definition of ipv4_addr in the ARM. Possibly update the definition if ip_prefix and dotted_decimal at the same time.
2. Maybe allow IPv4s in inet statements with less than four octets. For example:
   • This: controls { inet 127.1 ...
   • Would become: controls { inet 127.0.0.1 ...
   • I see arguments for and against.
3. In an Address Match List, for the address 127.1, named-checkconf could produce a warning message about the parsing, perhaps:
   • named.conf:<line#>: warning: In the Address Match List, 127.1 is interpreted as 127.1.0.0/32
   • Perhaps any address beginning with 127 and less than four octets should get this treatment.
4. Forgive me for leading you down this rabbit hole of the unimportant.