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-boun...@lists.isc.org] On Behalf Of 
MURTARI, JOHN
Sent: Tuesday, May 30, 2017 3:04 PM
To: bind-users@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 - jm5...@att.com<mailto:jm5...@att.com>
Ciberspring
office: 315-944-0998
cell: 315-430-2702

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to