3

As per RFC4408 3.1.3, a TXT record can be split up with quotation marks and will be reassembled properly - this is a way of getting around the 255 character limit on record size.

IN TXT "v=spf1 .... first" "second string..."

MUST be treated as equivalent to

IN TXT "v=spf1 .... firstsecond string..."

If a record has 3 or more parts, what determines the order in which the records are concatenated?

Community
  • 1
emc
  • 133
  • 1
  • 6
  • RFC 4408 is obsoleted by [RFC 7308](https://tools.ietf.org/html/rfc7208#section-3.3). It's best not to use it as a reference. Not that it changes anything about your question...it's just referencing the format described by [RFC 1035](https://tools.ietf.org/html/rfc1035#section-3.3.14). – Andrew B May 12 '16 at 23:26

2 Answers2

5

The parts are always reassembled in order. The 255 character limit is on parts of the TXT record. Without EDNS0, there is an addtional 512 byte limit for a UDP response. However, this does not apply to a TCP response.

BillThor
  • 27,737
  • 3
  • 37
  • 69
  • 1
    Reassembled in order of what - time entered into a database? Position in dig query? Order that the server returns the records in? – emc May 12 '16 at 23:01
  • @emc Order listed in the rdata for that record. This would be left to right as read in a zone file. – Andrew B May 12 '16 at 23:32
  • Aha, new terminology... http://superuser.com/questions/657789/format-of-txt-data-in-dns-record – emc May 12 '16 at 23:40
  • @AndrewB how does the rdata get set - automatically by the DNS server? – emc May 12 '16 at 23:56
  • @emc Yep! rdata contains the record type and associated payload. ([RFC 1034](https://tools.ietf.org/html/rfc1034#section-3.6)) – Andrew B May 13 '16 at 00:41
2

Also, you may encounter a problem with AWS Route53, where 

IN TXT "v=spf1 .... first""second string..."

IS treated as an equivalent to

IN TXT "v=spf1 .... firstsecond string..."

But if you use spaces... the following WILL FAIL:

IN TXT "v=spf1 .... first" "second string..."
Aldekein
  • 491
  • 4
  • 6
  • 1
    Whoa, interesting find, but not a 100% match for what I'm observing. A space (or no space at all) in the Route 53 console works fine for DKIM, so `"foo""bar"` and `"foo""bar"` are both treated as creating a single record with two values (and a space between the two is shown by `dig` but they concatenate correctly), while `"foo""bar"` in the Route 53 console creates two TXT records (`"foo"` and `"bar"` shown on two different lines, in random order, by `dig`). https://aws.amazon.com/premiumsupport/knowledge-center/route53-resolve-dkim-text-record-error/ – Michael - sqlbot Jan 24 '20 at 17:54