DNS Zone Syntax Escape Bug (Case 65177)

[VeZoZ]

cPanel for TXT entries is escaping semi-colons and @ symbols with a backslash causing the DNS server (BIND, MyDNS) to return invalid results. This poses a problem when more and more services are asking users to add TXT entries which cPanel subsequently breaks. I had expected to see a fix make it's way into 11.36.1 or very least 11.38 but it looks as though case 65177 did not make the cut. I figured it was time to make a forum post so the very least anyone else would be aware of it. I know we weren't until more and more users complained about how they could not add the proper TXT entries.

If anyone else sees this as a potential issue feel free to open a ticket so hopefully cPanel can make it more of a priority to fix.

 

[cPanelFelipe]

Backslash-escaping ; and @ is described in RFC 1035 (cf. the description of <character-string>).

Can you be more specific as to the breakage that you’re seeing from this?

 

[VeZoZ]

Backslash-escaping ; and @ is described in RFC 1035 (cf. the description of <character-string>).

Can you be more specific as to the breakage that you’re seeing from this?

Here is an example user will want to enter a dmarc entry as per google: https://support.google.com/a/bin/answer.py?hl=en&answer=2466563&topic=2759254&ctx=topicand and the code will be:

v=DMARC1; p=none; rua=mailto:[email protected]

The raw BIND entry will be

_dmarc  300     IN      TXT     "v=DMARC1\; p=none\; rua=mailto:user\@domain.com"

This is going to return the incorrect result of

_dmarc.domain.com. 86400 IN     TXT     "v=DMARC1\; p=reject\; rua=mailto:[email protected]"

Since TXT records are already double quoted while RFC compliant is unnecessary to do. This is causing several services to determine the record is in fact invalid. The current solution is to then after the fact modify the zone file. The issue this poses is any time the user manipulates the zone again the syntax check once again runs and escapes characters it should not be.

 

[cPanelFelipe]

Since TXT records are already double quoted while RFC compliant is unnecessary to do. This is causing several services to determine the record is in fact invalid. The current solution is to then after the fact modify the zone file. The issue this poses is any time the user manipulates the zone again the syntax check once again runs and escapes characters it should not be.

As I recall, we changed this after observing that certain strings produced unexpected results when saved as TXT records in the zone editor. The encoding and parsing algorithms that are in place now round-trip correctly.

Is it possible to put a zone parser in front of your application that more closely implements the RFC? Or perhaps there is an update available to the application’s zone file parsing?

 

[VeZoZ]

As I recall, we changed this after observing that certain strings produced unexpected results when saved as TXT records in the zone editor. The encoding and parsing algorithms that are in place now round-trip correctly.

Is it possible to put a zone parser in front of your application that more closely implements the RFC? Or perhaps there is an update available to the application’s zone file parsing?

It's not an application we're creating it's actually DMARC you can read about it here: DMARC - Wikipedia, the free encyclopedia you can see some major contributors to this. Gmail, Hotmail, Paypal etc.

Then going further you can visit DMARC - Frequently Asked Questions and go to the heading "Why the semicolons are escaped in DMARC records? Should I do the same when I publish a DMARC record?" . You will see this bit:

If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Why do the query programs do this? According to the DNS protocol specification, semicolon does not need to be escaped. Only dot and backslash need to be escaped using the backslash, and even those are OK in double-quoted strings like the ones used for TXT records. However some early DNS server software used the semicolon in the syntax of their zone files, and they required you to escape the semicolon. Querying software like dig started to escape the semicolon, so as to display a result which is identical to what you would put in the zone file. Nowadays most people use DNS server software that does not require you to escape the semi colon. If you put \; in the TXT portion of the zone file, the querying software will escape the escape character, displaying \\\;

I know we don't have any push with the likes of Google or Paypal or any of the others listed and I also doubt cPanel does.

 

[cPanelFelipe]

It's not an application we're creating it's actually DMARC you can read about it here: DMARC - Wikipedia, the free encyclopedia you can see some major contributors to this. Gmail, Hotmail, Paypal etc.

Then going further you can visit DMARC - Frequently Asked Questions and go to the heading "Why the semicolons are escaped in DMARC records? Should I do the same when I publish a DMARC record?" . You will see this bit:



I know we don't have any push with the likes of Google or Paypal or any of the others listed and I also doubt cPanel does.

Good news!

We looked at this again today and did conclude that the RFC actually permits either escaping or not escaping semicolons in quoted strings in TXT records. In the interest of preserving better compatibility with situations such as what you describe, I believe a change to leave semicolons unescaped will be coming in a future 11.38 build.

As an aside, though, this assertion from the DMARC page seems incorrect:

If you escape the semicolon with a backslash, DNS libraries (used by DMARC filters), will pass the result as is, making it an invalid DMARC record.

Net::DNS::ZoneFile, at least, seems to treat backslash-escaped semicolons in TXT records as just a semicolon, contrary to what the DMARC page says:

> perl -MNet::DNS::ZoneFile -E'say Net::DNS::ZoneFile->parse(<STDIN>)->[0]{txtdata}[0][0]'
haha 123 IN TXT "oh ; \; \\; \\\; yeah"
oh ; ; \; \; yeah

(dig(1) gives the same result, albeit with escaped semicolons)