Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
BIND
BIND
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 627
    • Issues 627
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 116
    • Merge Requests 116
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #1143

Closed
Open
Created Jul 12, 2019 by David Beck@Dave

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.
Assignee
Assign to
November 2019 (9.11.13, 9.14.8, 9.15.6)
Milestone
November 2019 (9.11.13, 9.14.8, 9.15.6) (Past due)
Assign milestone
Time tracking
None
Due date
None