Skip to content

fix(infoblox): select the most specific reverse zone - #82

Open
MaxRink wants to merge 1 commit into
AbsaOSS:mainfrom
MaxRink:fix/reverse-zone-most-specific
Open

MaxRink wants to merge 1 commit into
AbsaOSS:mainfrom
MaxRink:fix/reverse-zone-most-specific

Conversation

@MaxRink

@MaxRink MaxRink commented Aug 15, 2026

Copy link
Copy Markdown

Problem

findReverseZone collects every reverse zone that contains the target address and returns the most specific one. It keys the candidates by mask size:

_, mask := rZoneNet.Mask.Size()
networks[mask] = zones[i]

net.IPMask.Size() returns (ones, bits). The code reads bits, which is 32 for every IPv4 zone and 128 for every IPv6 zone. Every zone of one address family therefore shares a single key, and the map keeps whichever zone appears last in the list.

The selection is not "most specific". It is "last in the list".

Effect

With 10.0.0.0/8 and 10.1.2.0/24 both configured, a PTR record for 10.1.2.3 can be written to the /8 zone, depending on the order in which the WAPI returns the zones.

Change

Read the prefix length instead of the bit count.

Tests

Two tests, IPv4 and IPv6, each asserting both list orders so the result cannot depend on ordering, plus a case where the address falls outside the narrow zone and must fall back to the broad one.

Both tests fail on main and pass with this change.

Verification

go build ./..., go vet ./..., go test ./... and golangci-lint v2.10.1 all pass locally. GoLic reports no missing headers.

findReverseZone keeps the matching reverse zones in a map and returns
the one with the highest key, to get the most specific zone.

The key was wrong. net.IPMask.Size() returns the prefix length first
and the total bit count second, but the code read the second value.
That value is 32 for every IPv4 zone and 128 for every IPv6 zone, so
all zones of one family shared a key. The map kept the zone that came
last, which made the result depend on the order of the zone list.

With 10.0.0.0/8 and 10.1.2.0/24 configured, a PTR record for 10.1.2.3
could land in the /8 zone.

Read the prefix length instead. Add tests for IPv4 and IPv6 that cover
both list orders.

@k0da k0da left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants