Quoting of TXT records

When a TXT record data is entered, it is added to the zone verbatim.

a1                                       	IN	TXT	THIS IS SOME TEXT

# kdig +short a1.test4.com txt @::1
"THIS" "IS" "SOME" "TEXT"

This is likely to end up being treated as "THISISSOMETEXT", or who knows what, depending on the client software.
I think that the average user expects to be able to enter THIS IS SOME TEXT and have it treated as "THIS IS SOME TEXT". Perhaps if the first non-whitespace character entered is double-quotes, we can leave the input as-is, respecting the user's intention.

[pacoorozco]

I've been looking for some literature regarding this issue. RFC 1305 defines how values should be quoted in the Zone file. With regards to TXT resource records it defines that it should be quoted if the TXT data contains spaces.

It's useful to read the first answer to this questions to understand it better.

So, we can:

1. Allow users to enter their TXT data quoted. probind will not do anything with it
2. Allow users to enter an their TXT unquoted data. probind will represent it as quoted and escaped data in the zone file if it contains spaces.

In your current approach your are quoting the data when it doesn't start with ", we should include a way to escape " that are part of the TXT data (if it contains spaces).

INPUT	OUTPUT
ThisIsATXTDataWithoutSpaces	ThisIsATXTDataWithoutSpaces
This is an unquoted TXT data	"This is an unquoted TXT data"
"This is a quoted TXT data"	"This is a quoted TXT data"
"This is a TXT data with the \" char"	"This is a TXT data with the \" char"
This is a TXT data with the " char	"This is a TXT data with the \" char"

@pacoorozco It should be clarified that double-quotes are required if you want to specify a single string containing spaces, but are always allowed and are in fact always used in zone files generated by BIND and the like, or DNS replies displayed by dig and the like.
If the string is to contain a literal double-quote then escaping is required, you are absolutely right.
To simplify, I would specify the second option as:
2. Unquoted input will always be escaped and quoted.
Now, if you really want to get it right, then option 1 can be a little tricky, for example an input such as "one"two" or ""one" etc. are invalid while "one" "two" "three" is pefectly valid, it means the TXT record contains no spaces and no quotes but three separate strings. Since a string in a TXT response is limited in length to 255 characters, a multi-string response is quite common these days and client software tends to concatenate the response to one big string, which is what works with e.g. SPF and DKIM. The notion of "separate" strings doesn't seem to really get used.
If we implement zone file checking when they are generated then we can just say that if the input starts with a double quote then it must end with one too, and leave the rest to the zone check.

[pacoorozco]

Sorry @gadall I was not able to understand the last example... If I'm not wrong you were suggesting something like:

INPUT	OUTPUT	comment
ThisIsATXTDataWithoutSpaces	"ThisIsATXTDataWithoutSpaces"	We should quote it
This is an unquoted TXT data	"This is an unquoted TXT data"	We should quote it
"This is a quoted TXT data"	"This is a quoted TXT data"	Input is quoted so we leave it as it is
"This is a TXT data with the \" char"	"This is a TXT data with the \" char"	Same, the input is quoted, so we leave it as it is
This is a TXT data with the " char	"This is a TXT data with the \" char"	We should quote it and escape it
"one""two"	"one""two"	I guess you were suggesting leave it as it is
""one"	""one"	Should we escape that one? "\"one"

@pacoorozco yeah, sure, what you've just posted is ideal, if you can pull it off. I mean, ""one" is invalid and escaping the double-quotes other than the first and last one is the only useful thing we can do.

@pacoorozco If you can tell apart "one""two" vs. ""one" then fine, I'm not sure if you're aware of some component that can take care of it. I was hinting that if we have to hand-code it, then it's a little bit too much. I'm all for having a thorough discussion but if getting this absolutely right is too much trouble I'd support a simplified approah such as:

1. If the input starts AND ends with double quotes, strip them.
2. escape any remaining unescaped double quotes
3. "\"" . $input . "\""

I suppose this would cater to real-world needs.

@pacoorozco We really must break up the data into strings up to 255 chars long. knot doesn't mind, but I've confirmed with BIND 9.17.19, it won't just break it up for you.
so it has to be
abc123._domainkey TXT "upto255" "upto255"

[pacoorozco]

Hi @gadall

After reading several articles about long TXT records, like this one.

I've been working in two implementations:

Option A: TXT is human-readable

'testrecord                               	IN	TXT	( \n
                                          "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ"\n
                                          "EFAAOCAQ8AMIIBCgKCAQEApxJI+ldB/P7ocCsU4M"\n
                                          "jgC0iK+sIQ2g1Ft1RG3LuqquzaY8dmK+SsLVQi8u"\n
                                          "uo8t7DzAhsAGcHgHNOi189twbtQEz4R3KOLhESd3"\n
                                          "xGUYP0FTvyejDOaAeZzvjCzI6oj42Y0pNDRrmuOg"\n
                                          "Ad61qJy46+smfKc+QrI4E1DGHnjrlXzrsBK73DMq"\n
                                          "X9JuD9oGRaXDghakGdAebBjNcRsZfjIv84DPmrHE"\n
                                          "9/nqacqUnpK8Z71jAEcnklPIfC6LNmrWPzG7+6fN"\n
                                          "+LbAAUSjvXGw0GpB6EkhRsrcSwilE+vPe+S42aE4"\n
                                          "dBCvAbLjcZgJIA/gVqnNlm8jfL8qshXpQjIUObfd"\n
                                          "+o4wIDAQAB"\n
                                        )'

Option B: TXT is more compressed

'testrecord                               	IN	TXT	"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApxJI+ldB/P7ocCsU4MjgC0iK+sIQ2g1Ft1RG3LuqquzaY8dmK+SsLVQi8uuo8t7DzAhsAGcHgHNOi189twbtQEz4R3KOLhESd3xGUYP0FTvyejDOaAeZzvjCzI6oj42Y0pNDRrmuOgAd61qJy46+smfKc+QrI4E1DGHnjrlXzrsBK73DMqX9JuD9oGRaXDgha" "kGdAebBjNcRsZfjIv84DPmrHE9/nqacqUnpK8Z71jAEcnklPIfC6LNmrWPzG7+6fN+LbAAUSjvXGw0GpB6EkhRsrcSwilE+vPe+S42aE4dBCvAbLjcZgJIA/gVqnNlm8jfL8qshXpQjIUObfd+o4wIDAQAB"'

WDYT?