The content field of TXT records must be in quotation marks, but is not?

[pro-sumer]

Describe the bug

Cloudflare is complaining about TXT entries (including those from SPF_BUILDER and DMARC_BUILDER entries):

The content field of TXT records must be in quotation marks. Cloudflare may add quotation marks on your behalf, which will not affect how the record works.

To Reproduce
Steps to reproduce the behavior:

1. Use Cloudflare as DNS provider
2. Use a DNSControl configuration file with TXT entries
3. Push your changes
4. See error in Cloudflare dashboard (click on red triangle with exclamation mark inside)

Expected behavior
No warnings/errors in Cloudflare dashboard

DNS Provider

• Cloudflare

Additional context
N/A

[tlimoncelli]

CC @tresni

Hi @pro-sumer !

Can you provide a working example that demonstrates the bug? (i.e. a repro case)

Tom

[pro-sumer]

Sure! For this entry in my DNS config:

SPF_BUILDER({
  parts: [
    "v=spf1",
    "include:spf.messagingengine.com",
    "-all"
  ]
})

I get this complaint on the Cloudflare dashboard:

The content field of [TXT records](https://www.cloudflare.com/learning/dns/dns-records/dns-txt-record/) must be in quotation marks. Cloudflare may add quotation marks on your behalf, which will not affect how the record works.

for this generated TXT entry:

v=spf1 include:spf.messagingengine.com -all

[tlimoncelli]

@tresni Could you investigate?

(Note: I suspect the bug may be that CF shouldn't be displaying this warning)

[pro-sumer]

I suspect the bug may be that CF shouldn't be displaying this warning

It only popped up recently, without any changes on the DNSControl side, so I would not rule that out either...

[pro-sumer]

On the other hand, they are pretty explicit about the quotation marks in their help pages about TXT records:

However, TXT records still store their content within quotation marks ("").

[cafferata]

Originally posted (13 jun.) by @janik-cloudflare in Cloudflare community: Importing TXT records adds quotes, breaking records (comment)

Hi! TXT record contents always consist of a set of “strings”, each with a length of up to 255 bytes. Strings are typically represented as quoted sections, for example:

"the first string" "second" "another, third string"

While it wasn’t in the past, our behavior regarding zone file imports should now be correct and RFC-compliant, adding explicit quotes to imported TXT records. These explicit quotes are currently shown in both API and dashboard.

For simplicity and historical reasons, contents without explicit surrounding quotes are treated as a single string, only being split up if the 255-byte limit is exceeded. For example, one two three is treated as "one two three", even though, strictly speaking, the RFC-compliant interpretation would be "one" "two" "three". In the future, we may disallow unquoted TXT contents as we move to be fully RFC-compliant. For that reason, explicit quotes around strings in TXT record contents are expected and in fact strongly encouraged. These quotes should not cause any issues and in fact records with contents hello and "hello" will be exactly, byte-for-byte identical at the edge.

---

Originally posted (11 sep.) by @janik-cloudflare in Cloudflare community: Warning for TXT records without double quotes (comment)

Hi @mykhailo.oleksiuk! We’ve temporarily removed the warning while we write up some more documentation around this. We still recommend adding quotes, but we’ll likely also have the UI do that automatically in the future. Existing records may also be updated at some point, but since that’s a fairly large (breaking) change, it would be done slowly and after prior announcement.

There isn’t an urgent need to quote TXT contents right now, though it’s the more correct (RFC 1035) and unambiguous way to represent them, so in general we recommend it. At least for new records it’s probably a good idea! If you’re able to get existing records updated even better, but don’t feel pressured to do.

Hope that helps a little, at least until we have more documentation written up!

[tlimoncelli]

I think they've confused the RFC 1035 file format and the wire-format of the txt record.

Let me get some popcorn. This is going to be fun to watch.

[janik-cloudflare]

Could you elaborate, @tlimoncelli?

I think the warning is correct. We try to follow RFC 1035 zone file format for all record contents, and we do for all record types, with the only exception being unquoted TXT records, which are interpreted (by Cloudflare) in a way that differs how RFC-compliant parsers would interpret them. That's why they're discouraged. For example, a content of hello world on Cloudflare would normally be two strings (hello, world) per to the RFCs, but we'd interpret it as one hello world string with a literal space character between the two words.

Some other providers also allow unquoted inputs that they treat as a single string as much as possible, but quoted strings seem like the more correct and unambiguous representation.

Would it not be possible to switch to GetTargetTXTSegmented instead of GetTargetTXTJoined for the Cloudflare provider?

[tlimoncelli]

Here's my understanding of what cloudflare proposes:

1. Humans should enter RFC 1035-style quoted strings into a web interface
2. The web interface will display an error when they enter something that isn't quoted properly by RFC 1035 standards.
3. If a user enters into the web interface "hello" "world" it will generate a single TXT record with two segments: one containing hello and one containing world.
4. If a user enters into the web interface hello world it will generate:
   • NOW: a single TXT record with two segments: one containing hello and one containing world
   • FUTURE: a single TXT record with one segment: hello world

Am I understanding the situation correctly?

If so, my feedback is...

1. Humans should not be asked to enter RFC 1035-style quoted strings into a web interface.

That's a terrible user experience. Instead, it should accept a string of any length (with some reasonable limit), and behind-the-scenes segment it into 255-octet chunks. Hide all the segmentation from the users. Users don't need to see that.

If a customer wants to dictate that a TXT record should be (for example) two segments: one containing hello and one containing world then... they can go to hell because they're just f'ing with you. There are zero RFCs or other protocols that rely on specific segmentation of TXT data. They all assume the segments are joined verbatim. In python terms: ''.join(listname). I have searched and I can't find any protocol or application that requires anything else. Not even '[space]'.join(listname)

(and if you really, really, really, want to support such a user, then tell them to use the API for TXT record updates... The web is for humans, APIs are for robot... and they're asking to be treated like a robot.)

2. Using the RFC 1035 quoting mechanism in the API is logical but fraught with problems.

I'd be glad to go into more details, but let's focus on the web ui.

[tlimoncelli]

@janik-cloudflare

After writing that long message above, I realized a much more simply way to say it is:

Why would any TXT data sent via the API result in an error? If I send "one" "two" or one or "one two", the web UI should display in it properly quoted RFC 1035 format for me.

[janik-cloudflare]

If a user enters into the web interface hello world it will generate [...]

Not quite. The Cloudflare dashboard already converts it to RFC 1035 syntax today, adding explicit quotes, and I don't think there are any plans to change that in the foreseeable future. For UI purposes, when the input isn't quoted, everything is treated as a single string (unless of course the 255-byte limit is exceeded).

The warning in the UI is only shown next to old records and records created through the API (which currently keeps the verbatim content without adding quotes).

If a customer wants to dictate that a TXT record should be (for example) two segments: one containing hello and one containing world then [...]

As much as I want to agree, we do unfortunately need to support this. For example, TXT records transferred via Secondary DNS from another provider could look like that. If we split those differently, we'd be violating RFCs and breaking DNSSEC validation.

then tell them to use the API for TXT record updates

They can use both. The UI detects if the input is quoted and only adds quotes if some aren't already there.

If I send "one" "two" or one or "one two", the web UI should display in it properly quoted RFC 1035 format for me.

We'd like to get there, but preferably by actually changing the content on the API level too, actually adding quotes if missing instead of, say, allowing two different representations for the same content (abc and "abc"). That is of course a breaking API change and so will take some time to complete.

cc @hannes-cf

[tlimoncelli]

@janik-cloudflare @hannes-cf

As much as I want to agree, we do unfortunately need to support this. For example, TXT records transferred via Secondary DNS from another provider could look like that. If we split those differently, we'd be violating RFCs and breaking DNSSEC validation.

Yes, I wouldn't want to break support for zone transfers to/from secondaries, nor break DNSSEC. That's not what I was proposing. If I wasn't clear, my suggestion was to maintain the native segmentation internally and only present the "one long string" version at the user-interface level.

It sounds like what you are proposing is a text field for inputting the TXT data:

1. If the first byte is a quote " assume the user wants to specify the data as a RFC 1035-quoted string, which will display a warning if they don't comply with the format.
2. Otherwise, the string will be split into 255-octet segments invisibly for the user.

It seems like you believe there are humans that use your web UI that want to micro-manage how their TXT records are chunked. I've been maintaining DNS systems since 1991 and I've never met such a human. However, I haven't met everyone on the internet yet. So, I defer to you on this.

---

Here's how I see this playing out:

1. In the web ui a user enters: `v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdAMqtvxjdeFadOWwxdctB4YiNQ9Gio53uk2UjCzYZ1R3uBfVki0Y7a0j29AwnSe+zoHrI3+uZhedIWzK1W4GSqkxYWTlbIVH8HkrGV/QF3XQuxr50A4r2dSvI2VBCtx8npGCv5DHkTRg1RGmgRR3FvSVdwIVoEWCPtAE083GM4QvpN6tJjSZ08tl+fm/aqxsOLnZV8lM/tf4e6nkv6IsD7dkgpjGmkJFrT4hunhj5oW7l9q2933p8KVQ298OnJ47vwZWq+O9/6+RYyezNEOso4AQDGhfxD3WY38SirZyPBW2VlEYVtTCJmbOhGYXnT9RNJixIJFulkdw7E3rPbAWwIDAQAB

When the user returns to edit it, they see it has been changed to:

"v=DKIM1; k=rsa; h=sha256; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtdAMqtvxjdeFadOWwxdctB4YiNQ9Gio53uk2UjCzYZ1R3uBfVki0Y7a0j29AwnSe+zoHrI3+uZhedIWzK1W4GSqkxYWTlbIVH8HkrGV/QF3XQuxr50A4r2dSvI2VBCtx8npGCv5DHkTRg1RGmgRR3FvSVdwIVoEWCPtAE083GM4QvpN6tJjSZ08" "tl+fm/aqxsOLnZV8lM/tf4e6nkv6IsD7dkgpjGmkJFrT4hunhj5oW7l9q2933p8KVQ298OnJ47vwZWq+O9/6+RYyezNEOso4AQDGhfxD3WY38SirZyPBW2VlEYVtTCJmbOhGYXnT9RNJixIJFulkdw7E3rPbAWwIDAQAB"

Confused, they open up a support case. The reply is something about RFC 1035, quotes, and... whatever. The user doesn't understand but decides to live with it.

The head of support if miffed at all the support cases asking about this.

However...

2. Months later the user returns to update their DKIM key. They paste in their new key into the web ui, leaving the first and last quote in place but doesn't realize there's more to do:

What they enter is:

`"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAo5AKo/9BzmuQayaVlKdRbzchdun/WswHB5lkDkW8oFlkixcUKpxgspOhy944IE+r31RJ+wZWvSfrceccimKtEopOtkJSNzLrwXSKGLYBEvQSXoUeLCtQljvAUpZ2pESgeWjc2yTtTgHNpMxw9J5+c0aaZ623AnojGdvhNkJoMPdJfZ/nN6Py5d5RzcQX0XFSdsmzO3yf9T5Rs95GWdZM5Gc9VT+vKZj1b3cM8zwZGT10xxrzyCzycBhoaihKueI1/XmVuK/RzFA0jshj2s6J8uKV151TSzDT9dcX+Q4U9H+N/IirVrYH20lFKwhEetG+RaEALLaM7QLlM6C5XmIIOQIDAQAB"

The web UI display an error because the quoted text is longer than 255 octets.

They open a support case and are told to split the string into a 255-octet string and a 155-octet string.

The user replies: Why should I have to count out 255 chars when computers are much better at counting than humans. This seems like something the computer should do for them.

Oh, and they also ask, "what's an octet?"

Customer support explains that they should remove the quotes and everything will be ok.

Customer replies, "but last time you told me I needed the quotes!"

Customer walks away miffed.

3. In the web ui a user enters: hello world

(from what you've written I believe this case won't happen but I thought I'd include it to verify)

They are surprised when they do a "dig" and see the space was removed. helloworld

They open a support case about this obvious bug. They are miffed when they're told there's because of RFC 1035 they were technically wrong for entering a space without surrounding it with quotes. They reply, "No other DNS service makes me do that."

---

I'll end with this suggestion:

Why now have the web UI include a checkbox labeled "RFC 1035 format". If unchecked, users can enter any string they want and all chunking/escaping/quoting is done for them invisibly for them. If it is checked, they have to enter the text perfectly quoted and split into no-more-than-255-octet segments. That way everything is explicit and therefore less confusing to the users. Also, you can collect stats to see if anyone ever checks the checkbox.

[janik-cloudflare]

It sounds like what you are proposing is a text field for inputting the TXT data

Not proposing; this is already (more or less) how the UI behaves today.

The web UI display an error because the quoted text is longer than 255 octets.

That would not happen; overlong strings are split automatically.

In the web ui a user enters: hello world [...] (from what you've written I believe this case won't happen but I thought I'd include it to verify) [...] They are surprised when they do a "dig" and see the space was removed. helloworld

Indeed, this also would not happen.

Why now have the web UI include a checkbox labeled "RFC 1035 format"

Yes, something similar to that is on our list of ideas for the future.

[tlimoncelli]

@janik-cloudflare Thank you for taking the time to hear my concerns.