Multiple strings in a single DNS TXT record

[aykevl]

The current draft has this to say about multiple TXT records for a single domain:

If multiple TXT records for _mta-sts are returned by the resolver, records
which do not begin with v=STSv1; are discarded. If the number of resulting
records is not one, senders MUST assume the recipient domain does not implement
MTA-STS and skip the remaining steps of policy discovery.

But what if multiple strings are returned within a single TXT record? This is what SPF has to say about it:

As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS 
record (either TXT or SPF RR types) can be composed of more than one 
string.  If a published record contains multiple strings, then the 
record MUST be treated as if those strings are concatenated together
without adding spaces.  For example:

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

MUST be treated as equivalent to

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

SPF or TXT records containing multiple strings are useful in
constructing records that would exceed the 255-byte maximum length of
a string within a single TXT or SPF RR record.

And this is what DKIM has to say about it:

Strings in a TXT RR MUST be concatenated together before use with no
intervening whitespace.  TXT RRs MUST be unique for a particular
selector name; that is, if there are multiple records in an RRset,
the results are undefined.

Nothing like it has yet been defined in the STS spec.

---

Just for fun, I'm working on a small tool to check whether a domain has a valid MTA-STS setup. I noticed this problem while working on the DNS part.

[danmarg]

Thanks. I would suggest that strings be concatenated together. I will update the draft.

…

On Tue, Aug 8, 2017 at 5:44 PM Ayke ***@***.***> wrote: The current draft has this to say about multiple TXT records for a single domain: If multiple TXT records for _mta-sts are returned by the resolver, records which do not begin with v=STSv1; are discarded. If the number of resulting records is not one, senders MUST assume the recipient domain does not implement MTA-STS and skip the remaining steps of policy discovery. But what if multiple strings are returned within a single TXT record? This is what SPF <https://tools.ietf.org/html/rfc4408#section-3.1.3> has to say about it: As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. If a published record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example: IN TXT "v=spf1 .... first" "second string..." MUST be treated as equivalent to IN TXT "v=spf1 .... firstsecond string..." SPF or TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a string within a single TXT or SPF RR record. And this is what DKIM <https://tools.ietf.org/html/rfc6376#section-3.6.2.2> has to say about it: Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace. TXT RRs MUST be unique for a particular selector name; that is, if there are multiple records in an RRset, the results are undefined. Nothing like it has yet been defined in the STS spec. ------------------------------ Just for fun, I'm working on a small tool to check whether a domain has a valid MTA-STS setup. I noticed this problem while working on the DNS part. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB1vi9sV2w6kS8MwN8mqsVkkgYj91ioGks5sWQEGgaJpZM4OxdmS> .

[aykevl]

The same goes for the reporting side of the draft.

[danmarg]

@abrotman fyi.

[danmarg]

0f696b6

[abrotman]

TLSRPT already has this section:

"If multiple TXT records for _smtp-tlsrpt are returned by the resolver, records
which do not begin with v=TLSRPTv1; are discarded. If the number of resulting
records is not one, senders MUST assume the recipient domain does not implement
TLSRPT. If the resulting TXT record contains multiple strings, then the record
MUST be treated as if those strings are concatenated together without adding
spaces."

Which I believe covers the concern.

[aykevl]

@abrotman yes that has been added since I created this issue (0f696b6). I consider it to be fixed now.

There is still a small possible ambiguity wrt a record like this:

IN	TXT	"v=TLSR" "PTv1; rua=..."

because of the sentence "if the resulting TXT record contains multiple strings...", the result after a sender has tested for the record starting with v=TLSRPTv1.
But I think this isn't really an issue. I don't know who whould write such records (they're usually only split after 255 bytes) and I hope senders would concatenate the strings before testing for v=TLSRPTv1 anyway.