All People Seem To Need Data Processing, and when it comes to networking, understanding the OSI model is imperative. However you remember this seven layer schema, it's vital when troubleshooting difficult issues to remember them. Use these handy dandy mnemonics to help:
Please Do Not Throw Sausage Pizza Away (layer 1-7)
All People Seem To Need Data Processing (backwards, from layer 7-1)
Please Do Not Trust Sales People Always (1-7 again)
More information can be found in A+ and Network+ cert books, and other study guides I'm sure. Wikipedia has more information here too.
It's important to understand that although rare, your server logs can lie. Your mail server runs on the Application layer, so it only "sees" what that layer sees. Although of course it relies on all layers on down to the Physical layer, one single server may have several daemons running on different layers intercepting the data at different points along the way.
For instance, on a *nix box, you may have Sendmail logging that it's connecting to mail.domain.com [1.2.3.4].
Sendmail made a call to the DNS resolver and pulled the MX records. Again it called the resolver to resolve the A records listed in the MX. Then it tries to connect, but IPtables has a static route for 1.2.3.4 to send the data to 5.6.7.8, which is now refusing the connection.
Since Sendmail is running on the application layer, it doesn't log (or even see) when IP it's ACTUALLY connecting to, only where it *should* be connecting to. In order to see the packets you're going to have to do some traffic dumps using tcpdump, tcpick or Wireshark.
Of course, this is a very unique situation, either intentionally done by a sophisticated admin as a workaround or as a temporary "fix" for DNS issues, etc. Either way it's a kludge, and this is why each server should keep a changelog for later reference including the exact lines entered for later grep-ability (yes, I just made that word up :-) )
Also, there obviously could be many other issues with routing or other types of packet interference from router/firewalls locally to ISP related routing issues, but this was one instance that boggled me for several hours, so it stands out as an excellent reference.
-TEA
Showing posts with label DNS. Show all posts
Showing posts with label DNS. Show all posts
Sunday, July 4, 2010
Sunday, June 20, 2010
DNS doesn't end at MX you know...
Ok, so you understand MX records, you're ready to take on the world, right?
Not quite yet. Patience young grasshopper.
So, you're sending email to user@domain.com, you queried dns1.domain.com for the MX records and now you've got these MX records:
Host Priority Record
domain.com 10 mail1.domain.com
domain.com 20 mail2.domain.com
domain.com 30 mail3.domain.com
Ummm, so, computers don't speak English, they don't know what a "mail1.domain.com" is. They want digits that can turn into nice 1s and 0s that they can compute . What's a poor mail server to do with this stuff?
While we're at it, how did we even know to talk to dns1.domain.com to get these records?
Also, once we knew to talk to dns1.domain.com, we're back to the first question of how does the mail server know WTH a "dns1.domain.com" is, and where are the 1s and 0s it needs?
I is so confus :-(
Don't worry, there's more to an email's life than just MX records. There's lots of types of records including type A, type SOA, and type CNAME.
I. Type A records
Type A records ("A" for "Address") turn "mail1.domain.com" into a nice pretty number (the "IP Address" or "Internet Protocol address") for our mail server (and all other computers) to compute. The A record might look like this:
Mail1.domain.com IN A 10.0.100.28
Now we can see that the first MX record for domain.com has a name of "mail1.domain.com", but that name actually resides at 10.0.100.28. This number means nothing to most of us silly humans, but to a computer it's a nice string of digits that it can compute and then connect to.
TCP/IP and all of it's routing mechanisms are beyond the scope of this article, so you'll just have to make do with "once you have the IP you can connect to the server". :-P pbbt!
II. SOA records
OK, so this is a little backwards since you need the SOA records before you can get the MX records or A records, but you should already understand MX records, and you need to understand A records before you can get SOA records.
SOA records are the "Start Of Authority" records. There are literally millions of DNS servers in the world. How do you know which ones are responsible for the records you're querying? Well, that's where SOA records come into play. SOA records are given by the "root" name servers to offload queries to other DNS servers, and to provide a distributed architecture that is easier to maintain and provides more fault tolerance.
Root name servers are the biggest and baddest name servers in the world. There are two sets of them for your .com, .net, and the like, one at root-servers.net and one at gtld-servers.net. If queried, they will either reference the other one (like a father who says "go ask your mother", or vice-versa) or they will give the DNS server registered with them as authoritative.
You can play with this yourself using nslookup on Windows or dig on *nix.
Once the root servers give the name of the DNS server, that server's A record must be resolved then it can be queried for the MX, A, CNAME, or any other type of records you wish.
III. CNAME records
CNAME records are basically aliases to A records. For instance, "www.domain.com" might be the same server as "ftp.domain.com", so you could make ftp.domain.com a CNAME for www.domain.com, then an additional query would happen for the A record "www.domain.com" which when resolved would then allow transmission.
Typically, CNAMEs should not be in MX records. There's a ton of debate over whether they're allowed in the MX at all according to RFCs. I'm not going to enter that debate, but I will say that there are enough mail servers on the planet that don't respect CNAMEs in the MX that you should do everything in your power not to put them there. At the very least it adds an additional query to your DNS server (to get the IP of the A record in the CNAME), so for simplicity's sake I'd recommend against it as well.
One time a CNAME might be used is if you have a server that accepts email that does not have MX records. Originally, user@domain.com was actually literally user@some.server.com. You could even address email to an IP address like "user@10.0.100.28" for example and it would work. Most mail servers will fall back to this convention if MX records cannot be resolved, so you could for instance have a CNAME errors.domain.com pointing to "mail1.domain.com", then you could email "www-server@errors.domain.com", "email-server@errors.domain.com", etc which would then actually send the email to mail1.domain.com.
NOTE: this does not alias other record types, only A records. For instance, setting domain2.com as a CNAME for domain1.com DOES NOT make domain2.com's MX records the same as domain1.com's. CNAME records are not copies of the zone, they are address aliases and will only route traffic to the A record they point to. Additionally, it's technically against RFCs to have both MX and CNAMEs for the same zone. I.e. if you have www.domain.com as a CNAME, you can't also have MX for www.domain.com.
So, there you have it. MX record resolution requires SOA lookups, which require their own A record resolution. MX records include A records typically, which require their own resolution by the SOA. CNAMEs shouldn't be used in the MX, and can't have their own MX, but they can still be used to route email in a pinch.
Try using nslookup or dig to do your own DNS recursion. Once you realize how many DNS queries each email requires, be sure to give your DNS server a big pat on the back for so many jobs well done.
-TEA
Not quite yet. Patience young grasshopper.
So, you're sending email to user@domain.com, you queried dns1.domain.com for the MX records and now you've got these MX records:
Host Priority Record
domain.com 10 mail1.domain.com
domain.com 20 mail2.domain.com
domain.com 30 mail3.domain.com
Ummm, so, computers don't speak English, they don't know what a "mail1.domain.com" is. They want digits that can turn into nice 1s and 0s that they can compute . What's a poor mail server to do with this stuff?
While we're at it, how did we even know to talk to dns1.domain.com to get these records?
Also, once we knew to talk to dns1.domain.com, we're back to the first question of how does the mail server know WTH a "dns1.domain.com" is, and where are the 1s and 0s it needs?
I is so confus :-(
Don't worry, there's more to an email's life than just MX records. There's lots of types of records including type A, type SOA, and type CNAME.
I. Type A records
Type A records ("A" for "Address") turn "mail1.domain.com" into a nice pretty number (the "IP Address" or "Internet Protocol address") for our mail server (and all other computers) to compute. The A record might look like this:
Mail1.domain.com IN A 10.0.100.28
Now we can see that the first MX record for domain.com has a name of "mail1.domain.com", but that name actually resides at 10.0.100.28. This number means nothing to most of us silly humans, but to a computer it's a nice string of digits that it can compute and then connect to.
TCP/IP and all of it's routing mechanisms are beyond the scope of this article, so you'll just have to make do with "once you have the IP you can connect to the server". :-P pbbt!
II. SOA records
OK, so this is a little backwards since you need the SOA records before you can get the MX records or A records, but you should already understand MX records, and you need to understand A records before you can get SOA records.
SOA records are the "Start Of Authority" records. There are literally millions of DNS servers in the world. How do you know which ones are responsible for the records you're querying? Well, that's where SOA records come into play. SOA records are given by the "root" name servers to offload queries to other DNS servers, and to provide a distributed architecture that is easier to maintain and provides more fault tolerance.
Root name servers are the biggest and baddest name servers in the world. There are two sets of them for your .com, .net, and the like, one at root-servers.net and one at gtld-servers.net. If queried, they will either reference the other one (like a father who says "go ask your mother", or vice-versa) or they will give the DNS server registered with them as authoritative.
You can play with this yourself using nslookup on Windows or dig on *nix.
Once the root servers give the name of the DNS server, that server's A record must be resolved then it can be queried for the MX, A, CNAME, or any other type of records you wish.
III. CNAME records
CNAME records are basically aliases to A records. For instance, "www.domain.com" might be the same server as "ftp.domain.com", so you could make ftp.domain.com a CNAME for www.domain.com, then an additional query would happen for the A record "www.domain.com" which when resolved would then allow transmission.
Typically, CNAMEs should not be in MX records. There's a ton of debate over whether they're allowed in the MX at all according to RFCs. I'm not going to enter that debate, but I will say that there are enough mail servers on the planet that don't respect CNAMEs in the MX that you should do everything in your power not to put them there. At the very least it adds an additional query to your DNS server (to get the IP of the A record in the CNAME), so for simplicity's sake I'd recommend against it as well.
One time a CNAME might be used is if you have a server that accepts email that does not have MX records. Originally, user@domain.com was actually literally user@some.server.com. You could even address email to an IP address like "user@10.0.100.28" for example and it would work. Most mail servers will fall back to this convention if MX records cannot be resolved, so you could for instance have a CNAME errors.domain.com pointing to "mail1.domain.com", then you could email "www-server@errors.domain.com", "email-server@errors.domain.com", etc which would then actually send the email to mail1.domain.com.
NOTE: this does not alias other record types, only A records. For instance, setting domain2.com as a CNAME for domain1.com DOES NOT make domain2.com's MX records the same as domain1.com's. CNAME records are not copies of the zone, they are address aliases and will only route traffic to the A record they point to. Additionally, it's technically against RFCs to have both MX and CNAMEs for the same zone. I.e. if you have www.domain.com as a CNAME, you can't also have MX for www.domain.com.
So, there you have it. MX record resolution requires SOA lookups, which require their own A record resolution. MX records include A records typically, which require their own resolution by the SOA. CNAMEs shouldn't be used in the MX, and can't have their own MX, but they can still be used to route email in a pinch.
Try using nslookup or dig to do your own DNS recursion. Once you realize how many DNS queries each email requires, be sure to give your DNS server a big pat on the back for so many jobs well done.
-TEA
Wednesday, June 9, 2010
What's an "MX Record"?
Unfortunately, MX records are one of the most misunderstood points of email transmission. Padawan mail admins have many misconceptions. Here are a few:
1. That the MX records have a specific naming convention like mail.domain.com or smtp.domain.com
2. That every server that handles email must be in the MX record
3. That the destination MTA must be in the MX record
4. That an "MX server" is another name for a mail server
5. That a "reverse DNS" lookup queries the sending domain's MX
Now that we know a few of the things an MX record is NOT, let's take a look at what it IS.
An MX record is simply an entry in a domains DNS zone. Typically they consist of one or more "A" type records (which then require resolution) with priorities assigned to them. Also, as with all DNS record a TTL value, or Time To Live, is assigned to them as a whole (and to each type A record as well).
They are simply references to the border MTA(s) responsible for relaying incoming email for a domain. When an email server is asked to email user@domain.com, it queries the DNS servers responsible for the domain (often by recursing to the root name servers looking for SOA records) and asks for the MX records. Typically, the MX records consist of type A records so then another query is given to find the IP addresses associated to them.
Let's take this story as an example. Let's say you're at a friends house discussing a long lost friend.
Friend: Hey I bumped into John last week at the mall
You: Really, I haven't seen him in years! Did you get his phone number?
Friend: Yes, but I don't remember it. You'll have to look in my phone.
You: Where's your phone? (recursive DNS query to the root NS)
Friend: Over on the table
You: What's his entry? (MX record query)
Friend: It's "John Doe"
You open the phone and look at "John Doe's" entry (type A record lookup) and call him on your phone. (transmission)
This simple story, that has probably never actually happened to any of us but should be able to be understood by most of us, is as simple as MX gets. Of course there's more to it (TTL values, "border MTAs", lots more DNS lookups, and any number of issues routing), but those are really more relegated to the realm of troubleshooting, and not something to worry our pretty little heads with right now :-)
Once it's been determined where to send the email, the transmission ensues and sooner or later after being relayed, archived, scanned for spam/viruses, and many more operations the email will eventually find it's home at the destination server and be picked up by the client to be read by the user.
Just think of all of the servers across the globe that played a part in getting your email to it's destination sometime when you're sending email. It really is amazing how it all comes together so seamlessly.
The next time you get the call from your user wondering why it took five seconds to get an email try explaining this to them. Boggle their mind a little bit ;-)
-TEA
1. That the MX records have a specific naming convention like mail.domain.com or smtp.domain.com
2. That every server that handles email must be in the MX record
3. That the destination MTA must be in the MX record
4. That an "MX server" is another name for a mail server
5. That a "reverse DNS" lookup queries the sending domain's MX
Now that we know a few of the things an MX record is NOT, let's take a look at what it IS.
An MX record is simply an entry in a domains DNS zone. Typically they consist of one or more "A" type records (which then require resolution) with priorities assigned to them. Also, as with all DNS record a TTL value, or Time To Live, is assigned to them as a whole (and to each type A record as well).
They are simply references to the border MTA(s) responsible for relaying incoming email for a domain. When an email server is asked to email user@domain.com, it queries the DNS servers responsible for the domain (often by recursing to the root name servers looking for SOA records) and asks for the MX records. Typically, the MX records consist of type A records so then another query is given to find the IP addresses associated to them.
Let's take this story as an example. Let's say you're at a friends house discussing a long lost friend.
Friend: Hey I bumped into John last week at the mall
You: Really, I haven't seen him in years! Did you get his phone number?
Friend: Yes, but I don't remember it. You'll have to look in my phone.
You: Where's your phone? (recursive DNS query to the root NS)
Friend: Over on the table
You: What's his entry? (MX record query)
Friend: It's "John Doe"
You open the phone and look at "John Doe's" entry (type A record lookup) and call him on your phone. (transmission)
This simple story, that has probably never actually happened to any of us but should be able to be understood by most of us, is as simple as MX gets. Of course there's more to it (TTL values, "border MTAs", lots more DNS lookups, and any number of issues routing), but those are really more relegated to the realm of troubleshooting, and not something to worry our pretty little heads with right now :-)
Once it's been determined where to send the email, the transmission ensues and sooner or later after being relayed, archived, scanned for spam/viruses, and many more operations the email will eventually find it's home at the destination server and be picked up by the client to be read by the user.
Just think of all of the servers across the globe that played a part in getting your email to it's destination sometime when you're sending email. It really is amazing how it all comes together so seamlessly.
The next time you get the call from your user wondering why it took five seconds to get an email try explaining this to them. Boggle their mind a little bit ;-)
-TEA
Subscribe to:
Posts
(
Atom
)