4

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?

Improve this question
1
  • RFC 4408 is obsoleted by RFC 7308. 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.
    – Andrew B
    May 12, 2016 at 23:26

2 Answers 2

Reset to default
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.

Improve this answer
5
  • 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, 2016 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, 2016 at 23:32
  • Aha, new terminology... superuser.com/questions/657789/format-of-txt-data-in-dns-record
    – emc
    May 12, 2016 at 23:40
  • @AndrewB how does the rdata get set - automatically by the DNS server?
    – emc
    May 12, 2016 at 23:56
  • @emc Yep! rdata contains the record type and associated payload. (RFC 1034)
    – Andrew B
    May 13, 2016 at 0: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..."
Improve this answer
1
  • 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"<space>"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"<enter>"bar" in the Route 53 console creates two TXT records ("foo" and "bar" shown on two different lines, in random order, by dig). aws.amazon.com/premiumsupport/knowledge-center/…
    – Michael - sqlbot
    Jan 24, 2020 at 17:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .