Things to remember when defining your zones

I did some research and found much interesting information supported by the RFC which is worth a bit of highlighting:

http://serialcoders.sytes.net/Download/RFC/rfc2181.txt

Particularly section 10 is relevent to this topic.

10.1.
This may be a bit obvious to veteran DNS users, but don't worry, it gets better. If you include a CNAME record for a given domain you may NOT have any other records with it except SIG, NXT, and KEY. In addition, you may NOT have multiple CNAME records for a given domain. (more about CNAME below)

10.1.1.
A moot point in my opinion. CNAME stands for 'canonical name' and are to be used as aliases. They're used as simply labels by some people (I have no idea how or why).

10.2. PTR records
This will be a good discussion, I'll save it for last.

10.3. MX and NS records
This is a good one too. Don't EVER point these babies to a CNAME record. The following example is illegal:

domain.com. A 127.0.0.1
domain.com. NS ns1.domain.com.
domain.com. NS mail.domain.com.
ns1.domain.com. CNAME domain.com.
mail.domain.com. CNAME domain.com.

I know I know, I used to harp about how if you have dynamic IP's then using CNAME makes it easier on you. Well, it may make it easier on you, but it makes it OH SO MUCH HARDER on everybody else! A big reason for this is the CONVENIENCE of additional section processing where if you look up a domain's MX records, and you get a list, the additional section has the IP address for the domain provided in the MX record. This does NOT happen if you CNAME'd it. Instead, you're FORCING that poor bastard to make yet another lookup to find that IP address.

It is also however discouraged (although legal) to point multiple domains at a single IP like the following:

domain.com. A 127.0.0.1
domain.com. NS ns1.domain.com.
domain.com. MX 10 mail.domain.com.
ns1.domain.com. 127.0.0.1
mail.domain.com. 127.0.0.1
www.domain.com. 127.0.0.1

heh, now you've got your hands tied behind your back it seems. What are you supposed to do if you have 1 IP, many services, and can't CNAME them, and can't point multiple domains to a single IP?!? Well I say screw 'em. Do it anyway. The only reason it is discouraged is cause of reverse IP mapping with PTR records. There IS however a solution which is covered in the following topic...

Back to section 10.2: PTR records

Now it is time to learn something. I certainly did. Is it for this information I researched in the first place:

Issue: Multiple PTR records returned by a given IP address:

Let's say you want to do this for the example I've been working with:

1.0.0.127.IN-ADDR.ARPA. PTR domain.com.
1.0.0.127.IN-ADDR.ARPA. PTR ns1.domain.com.
1.0.0.127.IN-ADDR.ARPA. PTR mail.domain.com.
1.0.0.127.IN-ADDR.ARPA. PTR www.domain.com.

This is perfectly legal! Neither RFC 1034 nor 1035 says you can't do this. And the RFC this discussion is about actually EXPLICITLY declares that this is legal. However, 1035 has a little bit to say in seeming contradiction. Near the end of section 3.5. it states several cautions in reference to the IN-ADDR.ARPA domain. It says this explicitly:

"Gateways will often have two names in separate domains, only one of which can be primary."

Indirectly, it is saying that you should choose to use the domain for the primary gateway in the reverse query. It could've said to use both, but it didn't. Yet one other note, it is explicitly shown through example in this very section that you CAN get multiple PTR records in a response to a network reverse query. A network reverse query is when you specify 1 to 3 IP octets before the IN-ADDR.ARPA domain.

However, despite the legality I MUST - I wish I didn't have to - say that you SHOULD NOT have multiple PTR records returned by a 4 octet (full IP) reverse query. In other words, the PTR example I gave above DOES NOT WORK! Why? Cause software does not look past the first PTR record. It grabs the first one and bases it's check on it. Since the server is to return these records with no particular order (basically random) you can't be certain which PTR record domain checkers will get. So cause of short-sighted possibly lazy programmers, we are crippled in functionality. Single IP administrators have their hands tied behind their back, and we're doomed to smile and nod at domain check failures.

So what do you do? The mail domain is the most important. We need a reverse check for that to help avoid anti-spam measures. So the following is recommended for my 3rd example:

1.0.0.127.IN-ADDR.ARPA. PTR mail.domain.com.

There is another way however. All is not lost. You CAN pass those domain checks. Not only can you avoid spam blocking, but you can also have the reverse lookup work for your name server domain too to avoid warnings you may get from checking software or even nslookup. There is a cost however. Take a look for yourself:

[domain.com]
domain.com. A 127.0.0.1
domain.com. NS domain.com.
domain.com. MX 10 domain.com.
www.domain.com. 127.0.0.1

[1.0.0.127.IN-ADDR.ARPA]
1.0.0.127.IN-ADDR.ARPA PTR domain.com.

There you have it folks. All domain checks works cause really, you only have 1 domain that needs checking. All those domains that pointed to a single IP has been reduced to 2. I could CNAME the www host, but I want fast domain resolution for my website. I know, I know, it's kinda unsatisfying to have your name server and mail server simply called "domain.com". That is the price to be paid when all you have is one IP.

Or you can be like me, thumb your nose at the domain checkers, and stick to just reverse mapping the mail domain.

brought back to top for a specific person's sake. I wish topics like this was sticky in this forum rather than PHP related topics.

I am hoping that perhaps you still check this forum from time to time. I am not a DNS expert by any means and am having an issue getting mail from a mail server that is performing a PTR check. We are hosting our own mail and web but not DNS. We have DNS records set up and I had my ISP create a PTR record for our domain but am still unable to get mail from that mail server. I have 1 IP for my web and 1 IP for my mail. My current DNS is in the following config:

domain.com A 127.0.0.1
{www}.domain.com A 127.0.0.1
mail.domain.com MX 10 127.0.0.2

with a PTR record:
2.0.0.127.IN-ADDR.ARPA. PTR mail.domain.com

As I said, I am not a DNS expert by any means. Any thoughts on what I may have incorrect? Not sure of what other information you would need. Thank you in advance for any assistance that you may offer.

This may be completely off (and I will admit I probably know enough about DNS to be dangerous), but I had a similar situation at my previous place of employment. Despite the fact that I had the PTR record in place for reverse lookups to my mail server, I still had certain domains that would not process email from our server....one of them being Comcast.

Turns out that I did not have the required SPF record on my NS. I ran one of the many SPF wizards which gave me the proper syntax, created the SPF record, and mail started flowing like a champ.

Although this may be a moot point since you don't host DNS yourself, and one would think a DNS hosting service would have SPF records. But....I guess ya never know....

whowhatwhere

Hi,


HA! Exactly my problem. Currently the second ns record for my domain points off into the wild blue yonder instead of at my DNS server, because the company I leased my domain from won't break the rules.

It doesn't appear to be a problem, as my systems are online 24/7 and I'm diligent about performing random checks to ensure it is working, but I worry for the day someone decides to mess with the problem and host a mail server in my name...

I agree about the stickies - this stuff is far more useful, IMHO.

Best regards,
AstroTux.

Thanks for the reply...whowhatwhere, I took your advice and thought I had better check and make sure that an SPF record did in fact exist. And wouldn't you know it, there was no record. So, I used an SPF wizard and created one. Verified the validity of it through 3 different SPF testers and it passed all three. Now, to see if mail starts flowing from that one domain. I will keep you posted. Thanks!!