TXT records without quotes not recognized by pdnsutil

[paulhermanseu]

• Program: Authoritative
• Issue type: Bug report

Short description

When there's a TXT record in the database without quotes, this is invalid but pdnsutil does not recognize this error. When querying the PowerDNS API there is an Exception logged which tells to try 'pdnsutil check-zone'.

Environment

• Operating system: Centos 7
• Software version: 4.1.8 (MySQL backend)
• Software source: Operating system repository (epel)

Steps to reproduce

1. Create a TXT record without double quotes, for example: v=spf1 -all
2. Run pdnsutil check-zone (no warnings, no errors)
3. Query the PowerDNS api (exception)

Expected behaviour

I would expect pdnsutil to recognize this error like the exception says.

Actual behaviour

/var/log/messages pdns_server: HTTP ISE for "/api/v1/servers/localhost/zones/domain.tld.": STL Exception: Parsing record content (try 'pdnsutil check-zone'): Data field in DNS should start with quote (") at position 0 of 'v=spf1 -all'

pdnsutil check-zone Checked x records of 'domain.tld', 0 errors, 0 warnings.

Other information

The zone itself is fully functional, getting the "broken" TXT record via DNS works normal.

[aj-gh]

Unfortunately this was reported back in January 2016 and currently seems to consist at least of the following similar open issues: #3335 #4185 #6010 #6070 I also ran into this a while ago.

[Habbie]

We hope to do a TXT overhaul for 4.3.0 but it looks like it might be 4.4 or 5.0.

[HOSTED-POWER]

We also suffer from this atm, I hope for solution soon :)

[ghost]

this affects us as well, see my comments in the linked issue #6087 .

[Diego-Schmidt]

No fix for this?

[baest]

I can confirm this still is an issue. My backend is PostgreSQL and if I have a TXT record in the database like: v=spf1 a mx a:business.servnet.dk ip4:195.249.40.0/24 include:registrarmail.net include:_spf.one.com -all it is served by powerdns and pdnsutil check-zone reports no error. But if I try to retrieve the zone through the API like: http 127.0.0.1:10000/api/v1/servers/localhost/zones/teaminternet.dk. X-API-Key:**** I get an internal server error (HTTP 500 error) and in the log it says: Dec 22 09:03:11 core-dev-fra1 pdns_server[4428]: [webserver] ceaf3a5b-7129-4ef1-a4a7-04d8a31eff2e HTTP ISE for "/api/v1/servers/localhost/zones/teaminternet.dk.": STL Exception: Parsing record content (try 'pdnsutil check-zone'): Data field in DNS should start with quote (") at position 0 of 'v=spf1 a mx a:business.servnet.dk ip4:195.249.40.0/24 include:registrarmail.net include:_spf.one.com -all' If entire content of TXT record is enclosed in double quotes, then it works and the output through DNS is the same as before, so this should be a valid work-around until the problem is fixed

[martenlehmann]

I just ran into the same error, however I disagree with Paul on the opinion that a TXT record in the database without quotes would be invalid. You need to understand the context ie. where the quotes are coming from. When they were introduced used in the BIND zone file, they were needed to define the string (potentially multi line) and consider possible hash tags as part of the string rather than interpreting them as comments as usual. This becomes entirely redundant when working with a database where the individual data cell already contains the TXT record only, no comments, no parsing needed, just a long string in one cell rather than multiple segments in BIND.

The worst behavior is that PowerDNS does the job correctly when serving the TXT record in responses to queries. And it states Data field in DNS should start with quote ("), but unfortunately rather than giving a recommendation as defined with with meaning of SHOULD, it raises an exception and the API returns a 500 status code ("Internal Server Error").

[paulhermanseu]

Hi Marten what do you think a good solution would be?

1. GET query to the API = serve the records as is (without quotes and without Error 500)
2. When updating the zone via the API you have to add the quotes in order to update

[miodvallat]

Should be fixed now.