Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
pdnsutil: inconsistent error checking #4185
This is with pdns-server 4.0.0 from repo.powerdns.com on Ubuntu xenial.
Yes, it's just a TXT record without quote marks.
To reproduce, assuming sqlite3 backend
The key point is that the message about the quote marks only appears if there is a space in the content field.
I have same problem.
Below is what's happening... record sqlite entry 16 is example of TXT entry generating error.
If i remove the record causing the error, 16, then
If i reenter the same string as before but quoted i.e.
From what i know TXT records as per RFC should be quoted so edit-zone is correct, but it's confusing that it works with one unquoted string but not the other.. yet it seems to auto quote one of the TXT records ?? So
is there a reason quote is required ? I'm trying to migrate old setup to 4.0.3 (current Debian stable) and TXT records without "" are resolved fine, are not reported as bad by pdnsutil but are reported bad on reading by API (breaking any web ui that uses the API).
err-ing out on read is pointless because there is no way to fix it if you already have it in database, sans going to DB and manually fixing those. All it does is breaking any API-using app.
Also it seems like web frontends relying on database do not add "" while saving which makes it worse.
If quote is required for TXT records shouldn't it just be added automatically if record doesn't have "" instead of throwing 500's around ?
Same here, using a rather old web frontend that added TXT records without quotes.
I could fix the web-frontend and all the records, but it appears that any lack of quotes are fixed by the pdns server anyway. So I'm unsure whether to store them in (mysql) DB with or without quotes.
If check-zone started complaining about lack of quotes, I'd know which way to correct the records.
(Also running debian with pdns 4.0.3 here by the way.)
Just ran into the same:
In my postgresql backend:
Would be nice if edit could be forced, this way I need external tools to "fix" the records, which work fine except for the edit command: