Ending a TXT record with a backslash?

[Darcy Kevin (FCA)]

In the grand tradition of _ceci_n'est_pas_une_pipe_, how dig *represents* a piece of TXT contents isn't necessarily how it *is*.

I just verified (via tcpdump) that a TXT record label that shows up as "blah\\" in dig's (and host's) output, actually only contains a single backslash (hex code 5C), on the wire. So, anything that uses a resolver-library routine to fetch this data, will only see a single backslash. If it's just a wrapper around "dig" or some other command-line utility, then it needs to know the idiosyncracies of whatever it's wrapping.

The reason that dig "over-escapes" stuff like this, in its representation, is so that folks can take dig output and paste it back into master files _verbatim_.

I'd be more concerned about the folks asking for this TXT record. Seems they're doing something proprietary, but not "sub-classing" their use with, say, an application-specific prefix, and, say, a colon delimiter. If the "foo" app wanted a "path=" variable in a TXT record, maybe it could be encoded as "foo:path=xxx", so that it would never collide with the "bar" app that later wants to also encode a "path=" variable, at the same point in the namespace hierarchy, for a different, incompatible purpose.

This is part of the inherent problem with using DNS TXT records to store arbitrary app data. But, you most likely already know this, since the Experimental RFC you referenced (1464) discussed it briefly in Section 4.

                                                                                                                                                                                - Kevin


From: bind-users [mailto:bind-users-bounces at lists.isc.org] On Behalf Of MURTARI, JOHN
Sent: Tuesday, May 30, 2017 3:04 PM
To: bind-users at lists.isc.org
Subject: Ending a TXT record with a backslash?

Folks,
                Recently had an issue with someone who wanted this for a TXT record:

murt2 IN TXT  "path=\";

                Now, not sure wny they wanted it - maybe the root directory in Windows???  But anyway,  BIND does not like it.

zone example.com/IN: loading from master file db.example.com failed: unbalanced quotes

                Of course, we could escape the backslash.  Which BIND then likes and the zone will load.  But a dig gives you:

;; ANSWER SECTION:
murt2.example.com.      83000   IN      TXT     "path=\\"

                Which isn't really the same thing?  Took a look at RFC1464 (Using DNS to Store Arbitrary String Attributes),  https://tools.ietf.org/html/rfc1464,   read this:

   All printable ASCII characters are permitted in the attribute value.
   No characters need to be quoted with a "`".  In other words, the
   first unquoted equals sign in the TXT record is the name/value
   delimiter.  All subsequent characters are part of the value.

   Once again, note that in most implementations the backslash character
   is an active quoting character (and must, itself, be quoted).

                That last sentence really has me stuck!  Too many adjectives?  Are there 'inactive' quoting characters?

The RFC did have an example, but I couldn't work it out...

   Attribute    Attribute       Internal Form           External Form
   Name         Value           (server to resolver)    (TXT record)
   =            \=              `==\=                   "`==\\="

                Any suggestions are welcome & please excuse my attempts at humor above.
                Best regards!
John

----------------
John Murtari - jm5903 at att.com<mailto:jm5903 at att.com>
Ciberspring
office: 315-944-0998
cell: 315-430-2702

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170530/d85a43ce/attachment-0001.html>