Dns

DNS Failures

We use DNS a lot in email, particularly for authentication, so diagnosing why DNS isn’t returning what we expect it to is a pretty common challenge. And DNS responses aren’t exactly the clearest thing to understand.

Sending domains and hostnames

Lots of times I see someone asking a question and they talk about their sending domain. And it’s sometimes not 100% clear which domain they mean by that – and when we’re talking about alignment and reputation it can make a difference. So here’s a list of (some of?) the different places a mailserver uses a domain.

DNS for white label authentication with SproutDNS

I wrote last year about using “stunt” nameservers for customer subdomain authentication – i.e. dynamically generating all the authentication records needed in DNS for each customer as needed.

TXT Records

DKIM public keys live in DNS TXT records. A DNS TXT record contains strings of text, and each string is limited to be no more than 255 characters long.

Customer subdomain authentication

EDIT: Now with a production-ready implementation I talk about more here.

Wildcards and DKIM and DMARC, oh my!

If you’re an ESP with small customers you may have looked at the recent Google / Yahoo requirements around DMARC-style alignment for authentication and panicked a bit.

The trouble with CNAMEs

When you query DNS for something you ask your local DNS recursive resolver for all answers it has about a hostname of a certain type. If you’re going to a website your browser asks your resolver for all records for “google.com” of type “A”¹ and it will either return all the A records for google.com it has cached, or it will do the complex process of looking up the results from the authoritative servers, cache them for as long as the TTL field for the reply says it should, then return them to you.

Unresolvable RFC.5321 domain at Yahoo

Seen this recently?

451 Message temporarily deferred due to unresolvable RFC.5321 from domain; see https://postmaster.yahooinc.com/error-codes

Life of an Email

I’m repeating the presentation I gave at M3AAWG in London for the Certified Senders Alliance.

It’s all about how to send an email by hand, and how knowing the mechanics of how an email is sent can help us diagnose email delivery issues.

We’re starting in about five hours from when I post this.

Register at https://register.gotowebinar.com/register/2268789893122531343

Undelivered mail without a bounce

A few weeks ago I wrote a blog post focusing on one small part of bounce handling. Today I want to talk about delivery failures that aren’t bounces. This is really the biggest issue for companies who have written their own bulk sending servers. Modern bulk MTA appliances and ESPs correctly handle these types of bounces. However, when you’re troubleshooting it’s important to know that sometimes there won’t be a SMTP level bounce.

SPF and TXT records and Go

A few days ago Laura noticed a bug in one of our in-house tools – it was sometimes marking an email as SPF Neutral when it should have been a valid SPF pass. I got around to debugging it today and traced it back to a bug in the Go standard library.

DNS Flag Day

There are quite a lot of broken DNS servers out there. I’m sure that’s no surprise to you, but some of them might be yours. And you might not notice that until your domains stop working early next year.

TLS certificates and CAA records

Transport Layer Security (TLS) is what gives you the little padlock in your browser bar. Some people still call it SSL, but TLS has been around for 18 years – it’s time to move on.
TLS provides two things. One is encryption of traffic as it goes across the wire, the other is a cryptographic proof that you’re talking to the domain you think you’re talking to.
The second bit is important, as if you can’t prove you’re talking to, for example, your bank you could really be talking to a malicious third party who has convinced your browser to talk to their server instead of your bank which makes the encryption of the traffic much less useful. They could even act as a man-in-the-middle and pass your traffic through to your bank, so that you wouldn’t notice anything wrong.

When your browser connects to a website over TLS it, as part of setting up the connection, fetches a “TLS certificate” from the server. That certificate includes the hostname of the server, so the browser can be sure that it’s talking to the server it thinks it is.
How does the browser know to trust the certificate, though? There’s not really a great way to do that, yet. There’s a protocol called DANE that stores information in DNS to validate the certificate, much the same as we do with DKIM. It’s a promising approach, but not widely supported.
What we have today are “Certificate Authorities” (CAs). These are companies that will confirm that you own a domain, issue you a certificate for that domain where they vouch for it’s authenticity (and usually charge you for the privilege). Anyone can set themselves up as a CA (really – it’s pretty trivial, and you can download scripts to do the hard stuff), but web browsers keep a list of “trusted” CAs, and only certificates from those authorities count. Checking my mac, I see 169 trusted root certificate authorities in the pre-installed list. Many of those root certificates “cross-sign” with other certificate authorities, so the actual number of companies who are trusted to issue TLS Certificates is much, much higher.
If any of those trusted CAs issue a certificate for your domain name to someone, they can pretend to be you, secure connection padlock and all.
Some of those trusted CAs are trustworthy, honest and competent. Others aren’t. If a CA is persistently, provably dishonest enough then they may, eventually, be removed from the list of trusted Certificate Authorities, as StartCom and WoSign were last year. More often, they don’t: Trustwave, MCS Holdings/CNNIC, ANSSI, National Informatics Center of India (who are currently operating a large spam operation, so …).
In 2011 attackers compromised a Dutch CA, DigiNotar, and issued themselves TLS Certificates for over 500 high-profile domains – Skype, Mozilla, Microsoft, Gmail, … – and used them as part of man-in-the-middle attacks to compromise hundreds of thousands of users in Iran. Coverage at the time blamed it on “DigiNotar’s shocking ineptness“.
In 2015 Symantec/Thawte issued 30,000 certificates without authorization of the domain owners, and even when they issued extended validation (“green bar”) certificates for “google.com” they weren’t removed from the trusted list.
So many CAs are incompetent, many are dishonest, and any of them can issue a certificate for your domain. Even if you choose to use a competent, reputable CA – something that’s not trivial in itself – that doesn’t stop an attacker getting certificates for your domain from somewhere else.
This is where CAA DNS records come in. They’re really simple and easy to explain, with no fancy crypto needed to set them up. If I publish this DNS record …

Are they using DKIM?

It’s easy to tell if a domain is using SPF – look up the TXT record for the domain and see if any of them begin with “v=spf1”. If one does, they’re using SPF. If none do, they’re not. (If more than one does? They’re publishing invalid SPF.)
AOL are publishing SPF. Geocities aren’t.
For DKIM it’s harder, as a DKIM key isn’t published at a well-known place in DNS. Instead, each signed email includes a “selector” and you look up a record by combining that selector with the fixed string “._domainkey.” and the domain.
If you have DKIM-signed mail from them then you can find the selector (s=) in the DKIM-Signature header and look up the key. For example, Amazon are using a selector of “taugkdi5ljtmsua4uibbmo5mda3r2q3v”, so I can look up TXT records for “taugkdi5ljtmsua4uibbmo5mda3r2q3v._domainkey.amazon.com“, see that there’s a TXT record returned and know there’s a DKIM key.
That’s a particularly obscure selector, probably one they’re using to track DKIM lookups to the user the mail was sent to, but even if a company is using a selector like “jun2016” you’re unlikely to be able to guess it.
But there’s a detail in the DNS spec that says that if a hostname exists, meaning it’s in DNS, then all the hostnames “above” it in the DNS tree also exist (even if there are no DNS records for them). So if anything,_domainkey.example.com exists in DNS, so does _domainkey.example.com. And, conversely, if _domainkey.example.com doesn’t exist, no subdomain of it exists either.
What does it mean for a hostname to exist in DNS? That’s defined by the two most common responses you get to a DNS query.
One is “NOERROR” – it means that the hostname you asked about exists, even if there are no resource records returned for the particular record type you asked about.
The other is “NXDOMAIN” – it means that the hostname you asked about doesn’t exist, for any record type.
So if you look up _domainkey.aol.com you’ll see a “NOERROR” response, and know that AOL have published DKIM public keys and so are probably using DKIM.
(This is where Steve tries to find a domain that isn’t publishing DKIM keys … Ah! Al’s blog!)
If you look up _domainkey.spamresource.com you’ll see an “NXDOMAIN” response, so you know Al isn’t publishing any DKIM public keys, so isn’t sending any DKIM signed mail using that domain.
This isn’t 100% reliable, unfortunately. Some nameservers will (wrongly) return an NXDOMAIN even if there are subdomains, so you might sometimes get an NXDOMAIN even for a domain that is publishing DKIM. shrug
Sometimes you’ll see an actual TXT record in response – e.g. Yahoo or EBay – that’s detritus left over from the days of DomainKeys, a DomainKeys policy record, and it means nothing today.

Relaying Denied

I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things

December 2016: The Month in Email

Happy New Year! We’re looking forward to some interesting new projects this year, both for our clients and for Word to the Wise. Stay tuned!
December was a slow month for blogging, with everything going on. But we’re back on the horse now and ready to blog for 2017.

List and subscription management continue to be hot topics, especially in the wake of the listbombing attacks earlier this year. Earlier this month, I presented a webinar on listbombing for the EEC and DMA to review the attacks and discuss best practices for companies to manage subscriptions. For Ask Laura, I wrote about the unsubscribe process and how senders can best manage those requests to keep their lists current and compliant.
With all the holiday mail flying around, Steve wrote up a good post about the challenges of DNS hosting and issues customers may have reaching your site. He also wrote about canonicalization, a process for comparing things to see if they are the same, which is useful for understanding how messages change during the delivery process. It’s important to understand how this works with DKIM, as that process specifically looks at changes to messages in delivery to validate them.
I wrote a post about how delivery at Gmail is a bit different from other mail providers, which can lead to intermittent delivery problems, and got some useful information in the comments about some upcoming process changes. And as always, unwanted email is SPAM. It doesn’t matter if you call it outreach or prospecting, or “here’s something you might find interesting!” Still SPAM.

Is your website up? Are you sure?

“What would you do for 25% more sales?”
It’s panicked gift-buying season, and I got mail this morning from Boutique Academia, part of their final push before Christmas.
Inbox__18_975_messages__26_unread_
They’re hoping for some Christmas sales in the next three days. They do make some lovely jewelry – ask Laura about her necklace some time – so I clicked on their mail.
Failed_to_open_page
That’s not good. I like Boutique Academia, and fixing email and dns problems is What We Do, so I took a look.
Safari isn’t quite as bad with not-exactly-truthful error messages as Internet Explorer, but I still don’t really trust it. Perhaps the problem is with the click-tracking domain in the email, rather than with boutiqueacademia.com? So I open the base page at http://boutiqueacademia.com, get redirected immediately to https://www.boutiqueacademia.com – which fails to load.
15542402_1501169219896451_6901276936993410491_n
OK, start with the basics. DNS.

DNSBLs, wildcards and domain expiration

Last week the megarbl.net domain name expired. Normally this would have no affect on anyone, but their domain registrar put in a wildcard DNS entry. Because of how DNSBLs work, this had the effect of causing every IP to be listed on the blocklist. The domain is now active and the listings due to the DNS wildcard are removed.

HE.net DNS problems

Hurricane Electric had a significant outage of their authoritative DNS servers this morning, causing them to return valid responses with no results for all(?) queries. This will have caused delivery problems for any mail going to domains using HE.net DNS – which will include some of their colocation customers, as well as users of their free services – but also will have caused reverse DNS to fail for most servers hosted by Hurricane Electric worldwide, so if any of your mail is being sent from HE hosted machines you may have seen problems.
(We’re HE customers so we noticed. Still happy with them as a vendor.)

The Internet is hard.

There are so many things that need to happen to make the Internet work. DNS entries need to be right. MXs need to be set up. Web servers need to be configured. And, let’s be honest, anyone who has ever run their own services on the Internet has flubbed a configuration.
We don’t think about it, because most of the time the configurations are handled by scripts and they do things right. But at some point someone needs to type in something and there’s a risk it will go horribly wrong. I’ve been digging into domain data for a client of mine today. I think I’m going cross-eyed over it. But I have found so many weird things that just mean someone isn’t paying attention to what they’re doing.
Like the domain that has a MX record that says:

I’m pretty sure the intention of the domain owner is to publish a null MX. But they added an extraneous “0” in there and ended up publishing something really weird. Even worse, the MTA that this client is using is listing this as a “delivered” email. I’m pretty sure that mail to that domain never left the MTA.
I’ve found horribly typoed MX domains for popular spam filters. I’ve found domains that have invalid characters in them. I’ve found domains that are totally a mess.
The vast majority of us have some story or other of the time we really broke things by accident. Like the time a very large ISP deleted their MX records. Or when a different ISP changed their internal forwarding and broke SPF authentication for everyone mailing that domain. Or when another ISP accidentally blocked every IP beginning with 6.
Sometimes I’m amazed that the Internet ever works. No matter how big it gets, there are actual people writing actual code and configurations. The number of things that have to happen to get packets from A to B is pretty impressive. We rarely ever notice the breakages, the people who run things are really good at their jobs. But sometimes poking in the grotty corners reminds me how easy it is to break things. It’s sometimes a wonder things actually work.

Some mechanisms and modifiers (collectively, “terms”) cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the “include”, “a”, “mx”, “ptr”, and “exists” mechanisms, and the “redirect” modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”.
Read More

TXTing

txt
On Friday I talked a bit about the history behind TXT records, their uses and abuses.
But what’s in a TXT record? How is it used? When and where should you use them?
Here’s what you get if you query for the TXT records for exacttarget.com from a unix or OS X command line with dig exacttarget.com txt

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

PTR Records

PTR records are easy to over look and they have a significant impact on your ability to deliver mail without them. Some ISP and mailbox providers will reject mail from IP addresses that do not have a PTR record created. PTR records are a type of DNS record that resolves an IP address to a fully qualified domain name or FQDN. The PTR records are also called Reverse DNS records. If you are sending mail on a shared IP address, you’ll want to check to make sure the PTR record is setup, however you most likely will not be able to change it. If you are on a dedicated IP address or using a hosting provider like Rackspace or Amazon AWS, you’ll want to create or change the PTR records to reflect your domain name.
We usually think about DNS records resolving a domain name such as www.wordtothewise.com to an IP address. A query for www.wordtothewise.com is sent to a DNS server and the server checks for a matching record and returns the IP address of 184.105.179.167. The A record for www is stored within the zone file for wordtothewise.com. PTR records are not stored within your domain zonefile, they are stored in a zonefile usually managed by your service provider or network provider.
Some service providers provide an interface where you can create the PTR record yourself, others require you to submit a support request to create or change the PTR record.
If you know what IP address you are sending mail from, use our web based DNS tool to check if you have a PTR record created.
http://tools.wordtothewise.com/dns
Checking for a PTR record for 184.105.179.167 returns
167.128-25.179.105.184.in-addr.arpa 3600 PTR webprod.wordtothewise.com.
If you received Response: NXDOMAIN (There is no record of any type for x.x.x.x.in-addr.arpa), this means you’re missing the PTR record and need to create one ASAP if you are sending mail from that IP address!

4 things spammers do legitimate marketers don't

I’ve never met a spammer that claims to be a spammer. Most that I’ve met claim to be legitimate marketers (or high volume email deployers). But there are things spammers do that I never expect to see a legitimate marketer doing.
I’ve written about these things throughout the blog (tag: TWSD), but it’s probably time to actually pull them together into a single post.

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

I can't click through if you don't exist

Recipients can’t click through if you don’t exist
A tale of misconfigured DNS wrecking someone’s campaign.
I got mail this morning from A Large Computer Supplier, asking me to fill in a survey about them. I had some feedback for them, mostly along the lines of “It’s been two decades since I bought anything other than rackmount servers from you, maybe I’m not a good advertising target for $200 consumer laptops?” so I clicked the link.

Failed_to_open_page

(I’ve replaced the real domain with survey.example.com in this post, to protect the innocent, but everything else is authentic).
That’s not good. The friendly error messages web browsers give sometimes hide the underlying problem, but that looks like a DNS problem. Did they do something stupid, like putting the wrong URL in the mail they sent?

Flush your DNS cache (again)

This time it appears that DNS for major websites, including the NY Times, has been compromised. Attackers put in DNS entries that redirected visitors to a malware site. The compromise has been fixed and the fake DNS entries corrected.
However, people may still have the old data in their DNS caches and security experts are suggesting everyone flush their DNS cache to make sure the fake data is gone.
The Washington Post has an article explaining DNS hijacking.

SPF Fail: too many DNS lookups

I’ve had a couple folks come to me recently for help troubleshooting SPF failures. The error messages said the SPF record was invalid, but by all checks it was valid.
Eventually, we tracked the issue down to how many include files were in the SPF record.
The SPF specification specifically limits the number of lookups that can happen during a SPF check.

The death of IP based reputation

Back in the dark ages of email delivery the only thing that really mattered to get your email into the inbox was having a good IP reputation. If your IP sent good mail most of the time, then that mail got into the inbox and all was well with the world. All that mattered was that good IP reputation. Even better for the people who wanted to game the system and get their spam into the inbox, there were many ways to get around IP reputation.
Every time the ISPs and spam filtering companies would work out a way to block spam using IP addresses, spammers would figure out a way around the problem. ISPs started blocking IPs so spammers moved to open relays. Filters started blocking open relays, so spammers moved to open proxies. Filters started blocking mail open proxies so spammers created botnets. Filters started blocking botnets, so spammers started stealing IP reputation by compromising ESP and ISP user accounts. Filters were constantly playing catchup with the next new method of getting a good IP reputation, while still sending spam.
While spammers were adapting and subverting IP based filtering a number of other things were happening. Many smart people in the email space were looking at improving authentication technology. SPF was the beginning, but problems with SPF led to Domains Keys and DKIM. Now we’re even seeing protocols (DMARC) layered on top of DKIM. Additionally, the price of data storage and processing got cheaper and data mining software got better.
The improvement in processing power, data mining and data storage made it actually feasible for ISPs and filtering companies to analyze content at standard email delivery speeds. Since all IPv4 addresses are now allocated, most companies are planning for mail services to migrate to IPv6. There are too many IPv6 IPss to rely on IP reputation for delivery decisions.
What this means is that in the modern email filtering system, IPs are only a portion of the information filters look at when making delivery decisions. Now, filters look at the overall content of the email, including images and URLs. Many filters are even following URLs to confirm the landing pages aren’t hosting malicious software, or isn’t content that’s been blocked before. Some filters are looking at DNS entries like nameservers and seeing if those nameservers are associated with bad mail. That’s even before we get to the user feedback, in the form of “this is spam” or “this is not spam” clicks, which now seem to affect both content, domain and IP reputation.
I don’t expect IP reputation to become a complete non-issue. I think it’s still valuable data for ISPs and filters to evaluate as part of the delivery decision process. That being said, IP reputation is so much less a guiding factor in good email delivery than it was 3 or 4 years ago. Just having an IP with a great reputation is not sufficient for inbox delivery. You have to have a good IP reputation and good content and good URLs.
Anyone who wants good email delivery should consider their IP reputation, but only as one piece of the delivery strategy. Focusing on a great IP reputation will not guarantee good inbox delivery. Look at the whole program, not just a small part of it.

Weird mail problems today? Clear your DNS cache!

A number of sources are reporting this morning that there was a problem with some domains in the .com zone yesterday. These problems caused the DNS records of these domains to become corrupted. The records are now fixed. Some of the domains, however, had long TTLs. If a recursive resolver pulled the corrupted records, it could take up to 2 days for the new records to naturally age out.
Folks can fix this by flushing their DNS cache, thus forcing the recursive resolver to pull the uncorrupted records.
EDIT: Cisco has published some more information about the problem. ‘Hijacking’ of DNS Records from Network Solutions

DNS, SERVFAIL, firewalls and Microsoft

When you look up a host name, a mailserver or anything else there are three types of reply you can get. The way they’re described varies from tool to tool, but they’re most commonly referred to using the messages dig returns – NXDOMAIN, NOERROR and SERVFAIL.
NXDOMAIN is the simplest – it means that there’s no DNS record that matches your query (or any other query for the same host name).
NOERROR is usually what you’re hoping for – it means that there is a DNS record with the host name you asked about. There might be an exact match for your query, or there might not, you’ll need to look at the answer section of the response to see. For example, if you do “dig www.google.com MX” you’ll get a NOERROR response – because there is an A record for that hostname, but no answers because there’s no MX record for it.
SERVFAIL is the all purpose “something went wrong” response. By far the most common cause for it is that there’s something broken or misconfigured with the authoritative DNS for the domain you’re querying so that your local DNS server sends out questions and never gets any answers back. After a few seconds of no responses it’ll give up and return this error.
Microsoft
Over the past few weeks we’ve heard from a few people about significant amounts of delivery failures to domains hosted by Microsoft’s live.com / outlook.com, due to SERVFAIL DNS errors. But other people saw no issues – and even the senders whose mail was bouncing could resolve the domains when they queried Microsofts nameservers directly rather than via their local DNS resolvers. What’s going on?
A common cause for DNS failures is inconsistent data in the DNS resolution tree for the target domain. There are tools that can mechanically check for that, though, and they showed no issues with the problematic domains. So it’s not that.
Source ports and destination ports
If you’re even slightly familiar with the Internet you’ve heard of ports – they’re the numbered slots that servers listen on to provide services. Webservers listen on port 80, mailservers on port 25, DNS servers on port 53 and so on. But those are just the destination ports – each connection comes from a source port too (it’s the combination of source port and destination port that lets two communicating computers keep track of what data should go where).
Source ports are usually assigned to each connection pretty much randomly, and you don’t need to worry about them. But DNS has a history of the source port being relevant (it used to always use source port 53, but most servers have switched to using random source ports for security reasons). And there’s been an increasing amount of publicity about using DNS servers as packet amplifiers recently, with people being encouraged to lock them down. Did somebody tweak a firewall and break something?
Both source and destination ports range between 1 and 65535. There’s no technical distinction between them, just a common understanding that certain ports are expected to be used for particular services. Historically they’ve been divided into three ranges – 1 to 1023 are the “low ports” or “well known ports”, 1024-49151 are “registered ports” and 49152 and up are “ephemeral ports”. On some operating systems normal users are prevented from using ports less than 1024, so they’re sometimes treated differently by firewall configurations.
While source ports are usually generated randomly, some tools let you assign them by hand, including dig. Adding the flag -b "0.0.0.0#1337" to dig will make it send queries from source port 1337. For ports below 1024 you need to run dig as root, but that’s easy enough to do.
A (slightly) broken firewall
“sudo dig -b "0.0.0.0#1024" live.com @ns2.msft.net” queries one of Microsofts nameservers for their live.com domain, and returns a good answer.
“sudo dig -b "0.0.0.0#1023" live.com @ns2.msft.net” times out. Trying other ports above and below 1024 at random gives similar results. So there’s a firewall or other packet filter somewhere that’s discarding either the queries coming from low ports or the replies going back to those low ports.
Older DNS servers always use port 53 as their source port – blocking that would have caused a lot of complaints.
But “sudo dig -b "0.0.0.0#53" live.com @ns2.msft.net” works perfectly. So the firewall, wherever it is, seems to block DNS queries from all low ports, except port 53. It’s definitely a DNS aware configuration.
DNS packets go through a lot of servers and routers and firewalls between me and Microsoft, though, so it’s possible it could be some sort of problem with my packet filters or firewall. Better to check.
“sudo dig -b "0.0.0.0#1000" google.com @ns1.google.com” works perfectly.
So does “sudo dig -b "0.0.0.0#1000" amazon.com @pdns1.ultradns.net“.
And “sudo dig -b "0.0.0.0#1000" yahoo.com @ns1.yahoo.com“.
The problem isn’t at my end of the connection, it’s near Microsoft.
Is this a firewall misconfiguration at Microsoft? Or should DNS queries not be coming from low ports (other than 53)? My take on it is that it’s the former – DNS servers are well within spec to use randomly assigned source ports, including ports below 1024, and discarding those queries is broken behaviour.
But using low source ports (other than 53) isn’t something most DNS servers will tend to do, as they’re hosted on unix and using those low ports on unix requires jumping through many more programming hoops and involves more security concerns than just limiting yourself to ports above 1023. There’s no real standard for DNS source port randomization, which is something that was added to many servers in a bit of a hurry in response to a vulnerability that was heavily publicized in 2008. Bind running on Windows seems to use low ports in some configurations. And even unix hosted nameservers behind a NAT might have their queries rewritten to use low source ports. So discarding DNS queries from low ports is one of the more annoying sorts of network bugs – one that won’t affect most people at all, but those it does affect will see it much of the time.
If you’re seeing DNS issues resolving Microsoft hosted domains, or you’re seeing patterns of unexpected SERVFAILs from other nameservers, check to see if they’re blocking queries from low ports. If they are, take a look and see what ranges of source ports your recursive DNS resolvers are configured to use.
(There’s been some discussion of this recently on the [mailop] mailing list.)

Maybe the sky is only falling a little bit

There was quite a bit of breathless reporting last week about the DoS against Spamhaus and how it was large enough to break the Internet. As the postmortem has gone on, a few things are becoming clear.

Internet Storm Center on the Spamhaus DOS

The Internet Storm Center (ISC) has a blog post up discussing the DOS attack against Spamhaus. They do confirm they saw traffic approaching 300Gbps against Spamhaus. They also point out that most people probably never knew.

More on the attack against Spamhaus and how you can help

While much of the attack against Spamhaus has been mitigated and their services and websites are currently up, the attack is still ongoing. This is the biggest denial of service attack in history, with as much as 300 gigabits per second hitting Spamhaus servers and their upstream links.
This traffic is so massive, that it’s actually affecting the Internet and web surfers in some parts of the world are seeing network slowdown because of this.
While I know that some of you may be cheering at the idea that Spamhaus is “paying” for their actions, this does not put you on the side of the good. Spamhaus’ actions are legal. The actions of the attackers are clearly illegal. Not only is the attack itself illegal, but many of the sites hosted by the purported source of the attacks provide criminal services.
By cheering for and supporting the attackers, you are supporting criminals.
Anyone who thinks that an appropriate response to a Spamhaus listing is an attack on the very structure of the Internet is one of the bad guys.
You can help, though. This attack is due to open DNS resolvers which are reflecting and amplifying traffic from the attackers. Talk to your IT group. Make sure your resolvers aren’t open and if they are, get them closed. The Open Resolver Project published its list of open resolvers in an effort to shut them down.
Here are some resources for the technical folks.
Open Resolver Project
Closing your resolver by Team Cymru
BCP 38 from the IETF
Ratelimiting DNS
News Articles (some linked above, some coming out after I posted this)
NY Times
BBC News
Cloudflare update
Spamhaus dDOS grows to Internet Threatening Size
Cyber-attack on Spamhaus slows down the internet
Cyberattack on anti-spam group Spamhaus has ripple effects
Biggest DDoS Attack Ever Hits Internet
Spamhaus accuses Cyberbunker of massive cyberattack

Troubleshooting tools

There have been a number of comments on my post about Hotmail moving to SPF authentication having to do with troubleshooting authentication failures. I have been helping clients troubleshoot these issues, and am able to take on new clients to solve authentication problems. Contact me for more information.
Of course, many of these issues can be solved with access to the right tools. Steve’s been working on a number of tools that may help the troubleshooting process and we’ve recently launched them on Emailstuff.org. The website itself contains a number of DNS and data related tools we use for investigations and thought we’d share with the public at large.
One of the really useful tools is the SPF record expander. Plug in any domain, like google.com, and see what IP addresses they authorize to send mail.

Collaboration key to fighting crime on the internet

The Pittsburg Post Gazette has a good article on the DNS Changer Working group and how it can serve as a model for future collaboration against cyber crime.

MAAWG presents the first J.D. Falk award

Last week at MAAWG went much like all MAAWG conferences go: too much to do, too many interesting panels to attend, too many people to connect and work with, a plethora of very interesting keynote speakers and a total lack of sleep. Most of what happens at MAAWG is not public, but some of the events are.
One of the things that I can talk about is the J.D. Falk award. This award was established by MAAWG, Return Path and J.D.’s family to recognize people who work, usually behind the scenes and without fanfare, to enhance the Internet and protect end users. I sat on the award committee and we had a number of nominations for very worthy work. But the nomination that stood out was the one for Tom Grasso. Tom was the driving force behind the creation of the DNS Changer Working group. He was responsible for connecting experts from throughout the Internet industry, including ISPs, anti-virus vendors, and the broader security community to prevent the Internet for going dark for hundreds of thousands of infected individuals.
I am very proud of the decision the committee made. The bar has been set high for future recipients. Tom did an amazing job convincing lots of players to work together. His involvement definitely made the internet better for everyone, not just those infected by Rove Digital’s malware. What he did is a model for private / public partnerships in the future.
I don’t think I could say it better than the MAAWG press release, so I’ll just end with that.

Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

So you want to start a company? (part 4)

You’re setting up a company (or a new division or maybe even a new brand) and you’d like to use email to communicate with your customers. In this series of posts I’m going to touch on some of the things you can do today to make email life easier for you in the future. Today’s final post is on DNS hosting and setup.

The view from a blacklist operator

We run top-level DNS servers for several blacklists including the CBL, the blacklist of infected machines that the SpamHaus XBL is based on. We don’t run the CBL blacklist itself (so we aren’t the right people to contact about a CBL listing) we just run some of the DNS servers – but that means that we do get to see how many different ways people mess up their spam filter configurations.
This is what a valid CBL query looks like:

Basic email delivery using telnet

Whenever we’re working with someone to diagnose some obscure delivery issue one of the things we usually have them try is to “run a transaction by hand”. Being able to do that is a trick that everyone working with email should be able to do. I was drafting a blog post today and wanted to refer to running a transaction by hand and I realized that we hadn’t actually explained it anywhere. So here we are.
When you’re running a transaction by hand you’re doing everything your mailserver would do to deliver an email, but you’re doing it yourself. That means that you get to see all the responses from the mailserver you’re sending the mail to, and also any delays or errors in much more detail than you can usually get from mailserver delivery logs.
I want to send some email to playingwithtelnet@gmail.com. There are two main steps to doing this – first I need to find out which mailserver I need to talk to to send mail to gmail, then I need to actually send the mail.
To find the mailserver I have to look up the MX record for gmail.com. From a unix / linux / mac command prompt you can do that like this (the bits you type are in orange):

Troubleshooting the simple stuff

I was talking with one of my Barry pals recently and was treated to a rant regarding deliverability experts that can’t manage simple things. We’ve been having an ongoing conversation recently about the utterly stupid and annoying questions some senders ask. Last week, I was ranting about a delivery person asking what “5.7.1. Too many receipts this session” meant. This morning I got an IM.