Musings from a small IPP

It’s amazing how easy it is to get something wrong when configuring complex systems. When it comes to networking the first thing that people notice is when their e-mail goes wrong, because e-mail is a fairly complex application these days that calls upon all of the underlying services in many unexpected ways.

Today’s problem was again an SPF failure that I hadn’t seen before. The symptom was someone trying to send mail to one of our customers. They were being bounced with an error

554 5.7.1 failed SPF X.co.uk: Time-out on DNS 'SPF' lookup of 'X.co.uk'

However there was no problem looking up the SPF record

X.co.uk. 14400 IN TXT "v=spf1 a mx ip4:95.154.214.23 ~all"

All indeed looked great — but the SPF record calls up other records, both the ‘a’ address record, and the ‘mx’ record which might in turn need to look up some more addresses.

Address record is just fine:
X.co.uk. 14400 IN A 95.154.214.35

but the mx look-up died:
dig mx X.co.uk

; <<>> DiG 9.3.4-P1 <<>> mx X.co.uk
;; global options: printcmd
;; connection timed out; no servers could be reached


This is not an error one gets if there is just no record there to look up. In that case the system replies fairly quickly with an error to say there’s nothing there, and we can continue.  This error is complete silence, which indicates that either there is a fairly serious error in the data such as an alias (cname) loop, or that the server has an access control that tells it to ignore requests.

From the mail system’s perspective, it can’t get the information needed to make the check that the owner of X.co.uk, by publishing an SPF record, has implicitly asked us to make before delivering mail that seems to come from there, so we have to fail it, and hope they get their DNS fixed quickly.