AutoPTR does not work with domain ".i"

[kumashiro]

Because reverse zone name is matched by string, domain ".i" (zone "i.") generates incorrect reverse zone name "XXXXn-addr.arpa". Zone name lookup is also broken and pdnscontrol tries to add a PTR record to forward zone.

Domain ".a" (zone "a.") may also be affected.

[zeha]

Hi, thank you for your report.

Do you have examples that are a bit more specific? I have a hard time understanding what data didn't work for you in which field and so on.

[kumashiro]

Create a new zone named "i." (domain "i"). You don't have to add any records there (maybe except SOA), then try to add any name in any forward zone. AutoPTR will fire up and offer you a broken reverse name for IP. If you'll accept it, pdnscontrol will try to add this PTR record to zone "i.", resulting in "name out of zone" error message.

Example (after creating a zone "i."): adding a name "test" to domain "example.org" with IP 192.168.0.1 will generate PTR record "1.0.168.192n-addr.arpa.i" (note the broken ".in-addr" and ".i" at the end). Accepting it will cause a PTR REPLACE query to /servers/localhost/zones/i. and "name out of zone" error.

I've fixed the first problem by replacing line 92 in static/js/controllers.zones.js with:

ptr.rrname = ptr.revName.replace(/'.'+ptr.zonename.'$'/i, '');

and the second problem by replacing line 79 in the same file with:

ptr.zone = _.last(matchingZones);

however, I don't know JavaScript at all and these fixes are probably horribly wrong.

[kumashiro]

a3322d5 works like a charm, but AutoPTR pop up shows duplicated rev name in "RR" column. Exaple for adding name "aspirin.i" with IP 192.168.16.16:

This is only a visual glitch. PTR record is created correctly.

[zeha]

Aha, so there's two bugs. Reopening.

[zeha]

Could you try again with current master + 4.0.0alpha3? I've reworked the AutoPTR code in pdnscontrol because of the 4.0 API changes and I think this might be fixed now.