phpIPAM + PowerDNS: Invalid response from server: 422 Unprocessable Entity (500) adding VNET subnet

[kmorwath]

I'm trying to create a 172.16.0.0/16 subnet from the 172.16.0.0/12 address space. I have created in phpIPAM the 16 zones, 16.172.in-addr.arpa. through 31.172.in-addr.arpa already.

But when I'm trying to create the subnet in Proxmox, it reurns:

create sdn subnet object failed: can't read zone 16-31.172.in-addr.arpa.: Invalid response from server: 404 Not Found (500)

Although I'm using only the 16.172.in-addr.arpa zone. So I tried to create a zone named 16-31.172.in-addr.arpa, although it doesn't look to me a valid reverse zone name. Anyway, phpIPAM accepts it, and it appears in PowerDNS:

sysadmin@daedalus:~$ sudo -u pdns pdnsutil list-all-zones
Jan 29 15:47:36 [bindbackend] Done parsing domains, 0 rejected, 0 new, 0 removed
test.internal
64.100.in-addr.arpa
16.172.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
20.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
16-31.172.in-addr.arpa

But when I try to add the subnet again, I get (172.16.0.1 is defined as the gateway):

create sdn subnet object failed: error add 1.0.16.172.in-addr.arpa. to zone 16-31.172.in-addr.arpa.: Invalid response from server: 422 Unprocessable Entity (500)

"Unprocessable entity" is the PowerDNS error when it cannot process input. The error message should show more details, but Proxmox doesn't show it. Shouldn't Proxmox verify only there is a reverse zone for the subnet?

 

[kmorwath]

The error does not appear if the reverse DNS field is not set, but I believe there could a bug there.

 

[gareththered]

I've a similar error when I'm trying to edit the connected network on a VM. My setup uses 172.28.0.0 to 172.29.0.0 but I'm getting the same error about zone 16-31.172.in-addr.arpa. I'm using the internal IPAM by the way. Like you, removing the reverse DNS field gets rid of it, but also kills IPAM - it registers nothing now.

 

[kmorwath]

It doesn't happen with 10.0.0.0/8 address space, but probably I saw some issue with the 100.64.0.0/10 address space too, have to investigate further. 172.16.0.0/12 and 100.64.0.0/10 are trickier to handle when it comes to reverse zones because they are not aligned on an octet boumdary.

It looks Promox is using automatically "classless IPv4 delegation" zone names, which require a different DNS setup, even if a subnet falls exactly in a octet aligned existing reverse zone.

I'm going to try DNS setups as described here:

https://datatracker.ietf.org/doc/html/rfc2317
https://kb.isc.org/docs/aa-01589

Anyway a zone named 16-31.172.in-addr.arpa would imply delegations from the 172/8, as far as I can see .