for the name, they're all sent in one response packet, which will have
well known problems if they don't fit in a 512 byte UDP response
packet, and less well known but more serious problems if they don't
fit in a single TCP packet.
I admit to hearing this statement at San Diego last week, but I didn't
understand it then, and I don't understand it now. What is being referred to
with the term "TCP packet"? Is this a reference to the MTU?
Yes. I was surprised to learn that there is a bug in widely used
resolver libraries so that if it makes a TCP request, and the response
isn't entirely contained in the first packet, the resolver gives up and
retries. A large DNS provider thought it was being DDOS'ed (actually, it
was being DDOS'ed) and tracked it down to this bug being triggered by
some large response data.
I will admit to not being familiar with *all* DNS software, but I am having a
hard time believing that there is DNS resolver software that a) does TCP, but
b) somehow is unable to read an entire DNS message using TCP if it requires
more than a few IP packets to transmit.
Believe it. I think it's due to bugs in the code that waits for a
response or a timeout and doesn't go back to look for more data after
getting the first data chunk back. Given how few DNS queries have
needed TCP, and how few of the responses have been too big to fit in a
1500 MTU, it's not surprising nobody's noticed before.
Since no one seems to be talking about removing the "v=spf1/2" from the
beginning of TXT RDATA, I don't think "break" is the correct term here. The
_marid subdomain seems to improve the subtyping situtation in the
non-wildcard case, and leave the status quo in the wildcard case. This looks
like a net improvement to me.
So if you need multiple TXT records at your wildcard, you will have to be
careful about the size of that TXT RR set, but everyone else gets more
leeway.
I suppose that's true. It still seems to me to be asking for trouble,
since any unrelated application with TXT records is going to load up
the responses as well.