Mail: Reverse DNS and working with your ISP

In a recent post, I talked about how some mail hosts require that a FQDN be included in a reverse DNS lookup. A commenter noted that they were having some trouble getting their ISP to respond to requests for configuring a PTR record. So what I thought I’d do is go into a little bit more detail on how reverse DNS works, and then explain the process I use for finding the right person to make this happen.

Reverse DNS is the process used to determine what hostname is associated with an IP address. So that’s the reverse of a typical DNS lookup – which you would use to try and find the IP address associated with a particular host name. DNSStuff has a really good article that explains this if you want to dig a bit deeper.

So in order to implement reverse DNS lookup for an address, you must setup a PTR record for the hostname. Your ISP should have a PTR record already configured, and you can check this out by using the reverse DNS lookup feature on the dnsstuff.org web site. A typical ISP provided PTR record might look something like this… “1.0.168.192.static.ISP.com” (except with a valid IP address). What you want it to look like is this: “mail.example.com”.

Unless you have a good relationship with your Telco/ISP account manager, you’re probably going to have a tough time finding the right person if you’re just calling customer support. So instead of calling them, start by doing a WHOIS lookup on the ISP. What you’re looking for are the hostmaster (usually hostmaster@isp.com) and abuse addresses (usually abuse@isp.com). They’re typically very responsive and can act as a technical a point-of-contact for escalating and handling things that customer support has no knowledge of.

So what should you tell them in your email? Well, make certain to explain the entire situation - don’t just tell them that you need the PTR changed. Explain everything including the fact that you looked up the public block lists and confirmed that the client isn’t on any, include the fact that you reviewed the firewall’s outbound SMTP configuration, include the fact that you contacted the mail host’s support group, use all of the above points to justify your request for changing the PTR record.

Finally, not all ISP’s will cooperate with this request. My recommendation is to develop a relationship with an account manager at the Telco/ISP that will work this for you, and then use them as your point of contact for everything – from provisioning new service, to making changes to the PTR records. Short of that, your best bet is to follow the above recommendations.

SBS2003: Renaming the "CompanyWeb" in SBS

Well, maybe not rename exactly, but at least get it to respond to “http://whateveryouwant/”. The reason we’re not actually renaming companyweb is because it breaks-stuff – to much stuff to readily fix, as SBS references companyweb in a lot of different places.

So to start with, open up DNS manager (run command, “dnsmgmt.msc”) and take a look at the existing “CNAME” alias for “companyweb”. Using this as a template, create a new CNAME alias called WhateverYouWant, making sure that the FQDN is WhateverYouWant.domain.local, and that the target host points to your SBS server (servername.domain.local).

Finally go into IIS and right-click and select properties on the CompanyWeb, and add a host header for WhateverYouWant and WhateverYouWant.domain.local. Stop and restart your CompanyWeb in IIS. Then launch a web browser and point it at http://whateveryouwant/ and the companyweb will respond.

Keep in mind that http://companyweb/ will still work, but if you’d prefer something else, like say http://intranet/ or something that makes more sense for your organization, then this will work nicely.

DNS: Troubleshooting name resolution issues

I had an interesting conversation about name resolution with a consultant who was on-site with a customer. He was having problems finding a machine by hostname… the conversation was interesting from the standpoint that name resolution is something most people take for granted, and I thought it was worth posting because the situation was a bit non-standard, and useful for discussion.

“I added a machine to the network, and I can ping it by IP address because I know the address, but when I ping by name, I get “request timed out”, and the IP that it responds with is the wrong address.”

Okay, so is this a Windows 2000/2003 AD environment, using AD-integrated DNS, and WINS?

“Yes, AD-integrated DNS, WINS, etc”.

Does the workstation have a static IP?

“Yes, it has an IP of xxx.xxx.xxx.xxx and it’s pointed at the internal DNS server.”

Is the machine that you’re having problems with a member of the domain?

“No. See, the machine needs to be in a workgroup because… [some valid reason].”

How are you doing name resolution?

“Well, I have the client pointing to DNS, so DNS should resolve it.”

Have you checked the DNS management console? Because it might not be registering; or it's registered with the wrong IP.

"You’re right. Why isn’t it registering?"

Since it’s not a member of the domain, you need to allow “Nonsecure and secure Dynamic updates” in DNS (DNS>Server>Forward Lookup Zones>corp.domain.com). Then, you need to specify a DNS suffix for the connection on the client, tell it to register, and have it use the connection’s DNS suffix in DNS registration.

"Okay, done. But I’m still getting that wrong address when I try to ping it by name."

Did the machine come up and grab an address from DHCP before you gave it a static IP?

"Yes."

It probably registered in WINS; open up the WINS management console and delete those entries that are no longer relevant for the client… either that, or point the client to the WINS server.

"It worked!"

To summarize, when the client came up for the first time and pulled an address via DHCP it registered with DNS and WINS. After assigning a static IP to the client, he was able to ping it by IP. But when pinging by hostname, the host was resolving the old IP that had previously been registered in DNS and WINS. By the time I got involved he had unregistered the client from DNS, but not removed the entries from WINS. I had him turn on unsecured dynamic updates to DNS, set the DNS suffix on the client, and the machine started registering properly.

It’s important to keep in mind that unsecured dynamic updates to DNS can be a security risk. The default behavior in Active Directory-integrated DNS is to only allow secure updates, so this should be considered before making such changes.