hyatt.com spf record and dnscache

[David Hubbard]

So hyatt.com is serving a huge spf record:

"v=spf1 ip4:140.95.0.0/16 ip4:216.251.252.0/24 ip4:207.211.78.0/24
ip4:216.251.231.0/24 ip4:205.220.108.202 " "ip4:12.129.20.0/24
ip4:12.129.199.61 ip4:12.129.219.155 ip4:63.241.222.0/24
ip4:65.55.88.0/24 ip4:206.16.57.70 ip4:207.46.51.64/26
ip4:207.46.163.0/24 ip4:213.199.154.0/24 ip4:213.244.175.0/24
ip4:216.32.180.0/24 ip4:216.32.181.0/24 a mx ~all"

I'm troubleshooting an issue with a customer being
unable to receive email from hyatt.com; our servers
require either a SPF lookup & match or an SPF lookup
failure on an incoming mail domain to accept the
message, and in this case the dns query times out
with no response, causing the message to be deferred.

hyatt.com's name servers are:

authority: hyatt.com 2385 NS nameserver1.concentric.net
authority: hyatt.com 2385 NS nameserver2.concentric.net
authority: hyatt.com 2385 NS nameserver3.concentric.net
authority: hyatt.com 2385 NS nameserver.concentric.net

But I cannot successfully query any of them using dnsq,
it just times out:

dnsq txt hyatt.com nameserver.concentric.net
16 hyatt.com:
timed out

However I can query a bind server with dnsq and get the
response back without issue:

16 hyatt.com:
507 bytes, 1+1+4+0 records, response, weird ra, noerror
query: 16 hyatt.com
answer: hyatt.com 10591 16
kv=spf1\040ip4:140.95.0.0/16\040ip4:216.251.252.0/24\040ip4:207.211.78.0
/24\040ip4:216.251.231.0/24\040ip4:205.220.108.202\040\362ip4:12.129.20.
0/24\040ip4:12.129.199.61\040ip4:12.129.219.155\040ip4:63.241.222.0/24\0
40ip4:65.55.88.0/24\040ip4:206.16.57.70\040ip4:207.46.51.64/26\040ip4:20
7.46.163.0/24\040ip4:213.199.154.0/24\040ip4:213.244.175.0/24\040ip4:216
.32.180.0/24\040ip4:216.32.181.0/24\040a\040mx\040~all


Is this an issue of the size of the record and djbdns or
something I'm overlooking?

Thanks,

David

[Matthew Dempsky]

On Wed, Jul 28, 2010 at 9:44 AM, David Hubbard

Post by David Hubbard
Is this an issue of the size of the record and djbdns or
something I'm overlooking?

It's not the size of the record that's the issue, it's that their name
servers are sending back >512 byte UDP responses regardless of the
client's buffer size advertisement (or lack thereof, in the case of
djbdns).

Patch below will workaround the issue. (Apologies if gmail mangles it.)

--- dns_transmit.c~ Wed Jul 28 04:23:30 2010
+++ dns_transmit.c Wed Jul 28 04:23:30 2010
@@ -240,7 +240,7 @@

int dns_transmit_get(struct dns_transmit *d,const iopause_fd *x,const
struct taia *when)
{
- char udpbuf[513];
+ char udpbuf[4097];
unsigned char ch;
int r;
int fd;