pdnsutil edit-zone fails if SOA misses automatically filled in values

[yerrysherry]

Hallo,

I followed the documentation on https://doc.powerdns.com/md/authoritative/howtos/#basic-setup-configuring-database-connectivity to input some records in my database.

root@pdns4:~# pdnsutil edit-zone example.com
Error: Parsing record content (try 'pdnsutil check-zone'): missing field at the end of record content 'localhost [email protected] 1'
root@pdns4:~# pdnsutil check-zone example.com
Checked 10 records of 'example.com.', 0 errors, 0 warnings.
root@pdns4:~#

pdns=> select * from records where id=1;
 id | domain_id |    name     | type |         content         |  ttl  | prio | change_date | disabled | ordername | auth
----+-----------+-------------+------+-------------------------+-------+------+-------------+----------+-----------+------
  1 |         1 | example.com | SOA  | localhost [email protected] 1 | 86400 |      |             | f        |           | t
(1 row)

pdns=>

Why did the 'pdnsutil check-zone example.com' said that everything is ok?

Regards,
Gerrit

[yerrysherry]

root@pdns4:~# dig chaos txt version.bind @127.0.0.1 +short
"PowerDNS Authoritative Server 4.0.0-alpha2 (built Feb 25 2016 15:11:21 by root@8ae5d9441a25)"

[pieterlexis]

This is because PowerDNS has settings soa-*-default that fill this in at runtime (and also at pdnsutil check-zone time). The warning is harmless in this case, but it needs to go.

[pieterlexis]

Fixing this might be harder than anticipated. As it means adding the soa-*-default options to the ZoneParser, which might be a little too overreaching for the edit-zone feature. I suggest fixing the documentation and perhaps adding a message to the error telling the user that saving regardless will mean the use of the soa-*-default values.

[michael-yip]

Any fix for this bug? I'm using PowerDNS 4.x.x and found that the third party PowerDNSAdmin panel https://github.com/ngoduykhanh/PowerDNS-Admin/) wouldn't function properly with this bug

[zeha]

I fail to see how this bug is relevant for API consumers.

[michael-yip]

I didn't expect it neither but it seems the panel uses pdnsutil for editing zone files as I've received an error message via the portal interface itself.

[conradjones]

relevant for API consumers :
Jun 10 18:29:36 dns01 pdns_server[30169]: HTTP ISE for "/api/v1/servers/localhost/zones/DOMAIN.com": STL Exception: Parsing record content (try 'pdnsutil check-zone'): missing field at the end of record content ' 2018061000 28800 7200 604800 86400

sysadmin@dns01:~$ curl -H "X-API-Key: password" http://localhost:8081/api/v1/servers/localhost/zones/DOMAIN.com Internal Server Errorsysadmin@dns01:~$

[breaked01]

Any fix for this bug?

[glowfishDE]

Also suffering from this bug. When will it be fixed? Or whats the solution to it?

[nwilging]

Sorry to dig up a relatively old thread, but I ran into this issue just now and ended up finding a pretty easy fix.

First off, please _never_ say you "fail to see how this effects...." when it's clear that your users are having an issue with application functionality. This absolutely affects the API, and there's nothing about this bug that wouldn't affect zone manipulation via the API.

In this case, I was able to fix this bug by fixing a broken SOA record in my zone. I was attempting to retrieve zone information from the API and was getting a 500 internal server error. Logs showed the error mentioned in this ticket was the culprit.

The problem is my SOA record was missing nameserver data. All I had to do is prepend the IP of one nameserver to the SOA record. My broken record content looked something like:

example.com 2019121807 28800 7200 604800 86400

I added the NS IP to fix:

127.0.0.1 example.com 2019121807 28800 7200 604800 86400

My apologies if this doesn't fix the specific problem anyone else is having, but this was the issue in my case. Hope this helps. Also, I would recommend some more graceful error handling within the API. I think it's reasonable to expect an error message rather than a 500 internal server error, and it makes our job as API consumers much easier.

[zeha]

Duplicate of #5382?