We've all used subdomains. The popular naming convention "www.domain.com" is in itself a subdomain (the subdomain "www" in the "domain.com" domain), but did you know each subdomain can also have it's own MX records?
The obvious questions are "why would anyone do that" and "how would anyone do that?". Here's some food for thought.
Way back in the day, things were simpler. Email specifically didn't require tons of MX and A record lookups, there weren't even DNS servers to query let alone DNS record types. Users had accounts on their local servers, and the servers had names that although understandable would be different from organization to organization. Email addresses weren't "bob@company.com", they were "bob@accounting.company.com" for Bob in accounting and "bob@engineering.company.com" for Bob the engineer. Each organization would have their own server names, and although often they'd have meaning within the organization they might be goofy to outsiders. Also, desktop PCs were uncommon then, so you would connect to the server for almost all of your daily tasks. Therefore, rocky@bullwinkle.company.com was literally addressing the email to the user account "rocky" on the server named bullwinkle.company.com. Some places still conform to these odd naming conventions. I knew someone who went to the University of Michigan's Engineering school who had an email address @engin.umich.edu. It took me months to figure out that "engin" was for " school of ENGINeering".
Nowadays it's slightly different. "company.com" generally will have all of it's users email addresses directly @company.com, but not always. For instance, let's say there's a domain BigCompany.com. BigCompany.com is all over the world, and they want their customers to know that they're dealing with their "local" office. So, they may have John@USA.BigCompany.com and John@Canada.BigCompany.com, but they're totally different Johns, in totally different regions.
Let's say they not only want to have email addresses at the country level, but also at the state level. They could also have John@California.USA.BigCompany.com and John@NewYork.USA.BigCompany.com.
Now, most companies wouldn't do this because they don't want to confuse their customers by having them talk to the wrong John all the time, but you commonly see this with schools for instance. They might be something like "Principal@SchoolName.NY.k12.us".
Ok, now we know why someone would have subdomain MX records. Either to conform to a legacy naming convention or to help routing between different regions/offices. Now the question is "how do we do that"? The answer shouldn't be too surprising, we make MX records for each subdomain.
Just like each domain name can have MX records (and should have them if email is addressed to it), subdomains can get in on the fun too with their own set of records. Let's say you have an email address webmaster@www.domain.com, but you don't want to run a mail server on the same box as your web server (which is a good idea btw!). You can simply have MX records for www.domain.com go to the same server as your regular domain like this:
Host Priority Record
domain.com 10 mail.domain.com
www.domain.com 10 mail.domain.com
Now, you may have to create a separate zone for this subdomain if you're running your own DNS server, or if you're using some provider's interface they may require additional steps to configure this but most of the time it's possible. Some services don't allow subdomain records to be made if you're using their DNS, but DNS hosting is cheap. If they don't allow this, and they have ridiculously bad support who won't discuss the finer side of RFCs with you (cough, yahoo.com, cough), just change your DNS host. Outside of this issue, you're likely to find other reasons to switch providers later if you're not already disgusted with their lack of support.
It's important to keep in mind, that this is not something you can do after the fact. Once your users have you in their address book as user@domain.com, they will ALWAYS query domain.com's MX records regardless of whether you add an alias for user@sub.domain.com unless of course you choose to change your email address and deal with all of the headaches associated with that.
It also should not be used after the border MTA using address rewriting without serious contemplation. Although there are some excellent reasons to have your border MTA rewrite the delivery addresses to "user@sub.domain.com" while the rest of the world still emails the user@domain.com" address, there are serious considerations to take into account at the very least the reply-to address, or sender rewriting back to user@domain.com on the way out.
This is not likely something that many admins have dealt with before, and could be conceptually confusing at first. Don't worry, it's nothing different than what you do on the main domain, it's just a second place to deal with. User@domain.com queries domain.com's MX and sends them there. User@Sub.Domain.com queries sub.domain.com's MX and sends them there. It's pretty simple actually once you get your head around it. :-)
-TEA
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
Subscribe to:
Posts
(
Atom
)