Wednesday, December 13, 2017

who.org?

A co-worker brought me the print-out of some email traffic: somebody had been unable to send email to a government office. The email gateway of this office said that our domain did not exist. Well, it did and does.

The rest of this post requires some knowledge of domain name service (DNS). Briefly, DNS is what turns symbolic names such as www.tufts.edu into numeric addresses, and lets us all send email, browse web sites, etc., without needing to have many four-octet physical addresses memorized. You could think of it as the equivalent of a system for turning "The White House" into "1600 Pennsylvania Avenue NW" or "Carnegie Hall" into "881 Seventh Avenue". The internet has a number of "root servers". These know where to forward queries for different domains: "tufts.edu", "nytimes.com", "doj.gov". In every case, there will be a server or servers responsible for providing the authoritative information. Other servers hold and supply the information, looking up the information at the authoritative source, caching it for some period, and responding to inquiries.

Evidently the government email gateway looked up the mail exchanger (MX) record for our organization, could not find it, and rejected the email. We could not imagine why. The authoritative name servers for our domain are at Cloudflare, the mail exchangers are at Google. Hundreds if not thousands of other organizations must have the same arrangement. During the period that we could not send to this domain, we sent email to dozens or hundreds of other domains.

It was not clear how we could follow up. The government web site had no technical reference listed. The server rejecting our email was in the domain pitc.gov, for which I could find no information at all. The physical address belongs, ARIN says, to the Department of Defense: but the persons I spoke to at the number ARIN gave could do nothing to help me, though they tried. The co-worker's contact in the government said that he would inquire. A technical manager I found through LinkedIn asked a few questions.

About a week after we discovered the problem, the email started to go through. The last change that we made on our side was to make to set our  preference10 MX records according to Google's recommendations. It seemed implausible that this change could have removed the difficulty, since
  1.  Our preference 1 and preference 5 MX records were according to Google's recommendation, and the lower the preference number, the higher the priority.
  2. The preference 10 MX records that we had used were the names of machines owned and operated by Google, and accepting email.
But after at least a week of inability to send email, we were relieved to have email go through, and closed the help desk ticket.

Were the rejecting domain one used for private email, we would not have gone to the lengths we did in trying to troubleshoot this: we would have sent an email through another domain to the recipient, suggesting steps that the recipient's system administrators might try. In this case, that response was not good enough, and we kept up our (futile) troubleshooting. Ten minutes logged in to the government server, or five minutes' conversation with a system administrator might have resolved the difficulty, but neither was possible.

No comments:

Post a Comment