Domain Name / DNS troubleshoot / Reverse DNS / PTR

Hello,
I have an internal domain named domainname.com . Recently we had some issues with the email delivery to certain people
#550 No RDNS/PTR entry for 60.A.B.C. ##
After contacting my ISP a reverse DNS for ip 60.A.B.C resolving to mailserver.domainname.com was created.
I told the ISP that we do not own the domain "domainname" so any reverse dns query will not be resolved to that domain name.
I was told the ptr record must resolve to something .

What are my options now ?

Now let say i own a domain say externaldomain.com and i change the internal domain name to externaldomain.com.
Will this address the situation?
I have read its not a good practice to name your internal domain as your external domain, if i can not name the external domain same as the internal domain, How will anything will be resolved to my internal domain.????

You need to set a public PTR up. You don't have to do anything internally. Only thing you have to do is make sure your email is going out the IP that you want it to... for instance that your MX record matches the public IP of your Exchange server.

Go to http://www.ipchicken.com on the exchange server....if the exchange server sends the email directly out to the internet you probably want that IP to be setup with RDNS.

For Exchange 2007 the name is configured as the FQDN for your Send Connector (Organisation Configuration, Hub Transport, Send Connectors). The name used here does not have to match your AD Domain, it should be a name which resolves in your public domain.

For example, you might use mail.yourpublicdomain.com there. You should ensure a Host (A) record exists for that on your public DNS server. Then the name can be used for the Reverse Lookup with your ISP.

The big problem with using a .com name you don't own is that your own servers, if able to connect to the Net, will go out there and find out from the .com root servers that they are not authoritative for this domain. Then they'll go out trying to register with the actual DNS server for that name (constantly, forever, even if you think you turned that off) which is problematic. :)

You can actually set up reverse dns that doesn't match and it will work almost all the time. Maybe all the time, but not necessarily so in the future. But in general it's better to separate your internal network from .com. For instance, if you use a .doc name and your DNS server for that domain is exposed to the Net to support a public website and so you can get e-mail, then people can work the DNS server to see the names and addresses of every machine on your network.

So usually what people do is use .local for their Windows network which keeps it looking inward...and use .com or whatever for their e-mail addresses, website etc. so that people on the Net can find what they need to find.

> Then they'll go out trying to register with the actual DNS server for that name (constantly, forever,
> even if you think you turned that off) which is problematic. :)

That won't occur if DNS is configured correctly for an AD domain. It can only occur when the local servers have no authority for the domain, that would be a problem because AD needs an domain to store service records in.

DNS will never forward requests for a domain it holds authority over (whether the public view agrees with that authority or not).

> You can actually set up reverse dns that doesn't match and it will work almost all the time

Except for AOL, GMail, Hotmail, and anyone else that checks the name in the HELO matches the reverse lookup.

> For instance, if you use a .com name and your DNS server for that domain is exposed to the Net to support
> a public website and so you can get e-mail

Then your firewall rules are flawed because there's no need to allow inbound DNS queries unless you are actually hosting a public DNS service.

Nothing to do with DNS configuration, everything to do with network security (or lack of).

Thanks but totally confused with different suggestions.
Jesper-- "The internal SMTP server can be configured to use the public domain name for transmission."
How do you do that ?

Chris-Dent:
"For Exchange 2007 the name is configured as the FQDN for your Send Connector (Organisation Configuration, Hub Transport, Send Connectors). The name used here does not have to match your AD Domain, it should be a name which resolves in your public domain."

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

o *If you don't own a .com domain,* and your servers have access to the Net, even if your servers think they're authoritative for it to start with, they will in fact discover otherwise in my experience. Unless something has changed recently. :)

o Yup I said almost all of the time LOL...

o You should never rely on firewalls they're an additional thing IMO--configuration should be as secure as possible to start with. But I said "if you use a .com name and your DNS server for that domain is exposed to the Net to support a public website"

What I am suggesting is that you need another domain name that is publicly resolvable via a query with an Address record in the forward domain zone that matches the Pointer record in the inverse address zone.

I have on good authority that Chris-Dent knows what s/he's talking about when it comes to Windows!

If none of them are, we need to give your server a name. This can be anything, but we must be able to resolve it from the rest of the world. Something simple like "mail.yourpublicdomain.com" or "smtp.yourpublicdomain.com" would be nice. Are you able to add this to your public DNS service?

Whichever name we create needs to point to the public IP address used by the mail server when it sends out mail. So a new Host (A) record pointing at that IP address on your public DNS server.

2. Configuring the PTR

If we got a name from the MX, or made one up and added it the ISP can be contacted again. They can be told to point the PTR record (Reverse Lookup) to the name from step 1.

3. HELO

The last step is to change the name used when your server talks to other SMTP servers.

Exactly where this is depends on your configuration, we need to take a bit of a look at this.

Open up the Properties for "EdgeSync - Default-First-Site-Name to Internet". Select the Address Space tab and see if the only entry listed is "*". Then select the Network tab and see if "Use domain name system (DNS) ..." is selected.

If "Route mail through the following smart hosts" is selected then the changes need to be made on that server.

However, if the first option is selected, and the address space is "*" (everything) then all you need do now is change the value in the FQDN box under the general tab to the name we used in 1 and 2.

@Datedman, I'll leave those discussions for a different thread. My disagreement with the points isn't relevant to this one :)

Yup I agree with everything you said, sorry if my points were badly put above. I was mostly just trying to answer his question about why internal and external domain names should be different according to the quoted...and evidently I express myself poorly. :)

Morning!
I "think" it worked! Email sent from inside to hotmail account shows the change . In the first mail it shows Received: from servername.internaldomainname.com and after making the changes it shows
Received: mail.yourpublicdomain.co.uk .

Only thing that needs to be done is to ask the ISP to change my ptr record to mail.yourpublicdomain.co.uk because if i go to zoneedit.com and do the nsloopkup it still has the old ptr name for reverse dns i.e servername.internaldomainname.com .

Featured Post

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

In this video we show how to create a User Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Recipients >> Mailb…

In this video we show how to create an Accepted Domain in Exchange 2013. We show this process by using the Exchange Admin Center.
Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center.
Navigate to the Mail Flow >> Ac…