munisee
asked on
Exchange, DNS and Reverse Lookup Records - Need Help
We recently decided to migrate to an MPLS network. To be fair, no vendor names will be mentioned. Lets just call it Splint MPLS. While cutting over to Splints network, rather than use thier IP's, we are using blocks that we recently acquired.
We have 15-20 remote sites, 5-6 of them with Exchange servers. All mail comes in here at the hub site and gets routed. However each exchange server has the ability to send mail from their location. So, they have PTR records set up with thier ISPs to comply with reverse lookups from other mail servers.
When we move to our new network, the ISP will advertise our IP's that WE own. They will be the same ISP at every site and now we will need new PRT records for the new IP addressing at each site. The ISP is telling me they can't do this because we own the IP's, not them. And now it seems we need to get a public DNS server just to get around this.
I need to know if this is correct? Or is there any way to setup DNS / CNAMES / MX records.. to get each site to send mail and work the way we currently do without the need for a PTR record locally at each site? I just don't think there is. I don't want to have to have a public DNS server to worry about if I don't have to.
I can explain this differently if I am not wording this properly. Thank you.
We have 15-20 remote sites, 5-6 of them with Exchange servers. All mail comes in here at the hub site and gets routed. However each exchange server has the ability to send mail from their location. So, they have PTR records set up with thier ISPs to comply with reverse lookups from other mail servers.
When we move to our new network, the ISP will advertise our IP's that WE own. They will be the same ISP at every site and now we will need new PRT records for the new IP addressing at each site. The ISP is telling me they can't do this because we own the IP's, not them. And now it seems we need to get a public DNS server just to get around this.
I need to know if this is correct? Or is there any way to setup DNS / CNAMES / MX records.. to get each site to send mail and work the way we currently do without the need for a PTR record locally at each site? I just don't think there is. I don't want to have to have a public DNS server to worry about if I don't have to.
I can explain this differently if I am not wording this properly. Thank you.
Alan Hardisty
Most ISP's own the IP Addresses - not you - did the ISP provide you with the IP's or did you somehow purchase them?
ASKER
We acquired the IP's from an acquisition made recently. We purchased an ISP and received a large number of public IP's. We gave most back to IANA but kept enought to distrubute to each location. With the direction we are going it makes sense to register and host our own public DNS server however I would like to avoid that if possible right now. When I talk to Splint, as I have a few sites cut over already to the MPLS cloud, they say that becuase we own the IP's they cannot/will not set up PTR records for us. With this, another engineer here at work is trying to tell me we can do this without having PTR records at each site. Something about CNAME's matching MX records. Perhaps I am not fully understanding exactly how the PTR process works - with client (receiving mail servers) perform reverse lookups against our SMTP server that the email was sent from and the IP it sends from just needs to match the fqdn in the header of the email when a reverse lookup is done, correct? How would you set this up in a hub/spoke Exchange environment with each spoke sending mail from thier location ?
ASKER
It is critical that I get this resolved. No offense but I am re-posting another question that is similar to this. I just need to get more information. I need to find out who is responsible for the PTR record... the owner of the IP ? the advertiser of the IP? What if in our case the owner is us, but we advertise through someone else? Do we need to set up our own DNS server on the Internet?
I have a site that is having issues that is already on our MPLS network. We cannot go back and they are having problems with bounce backs that are a direct cause of no PTR record for our new IP.
I have a site that is having issues that is already on our MPLS network. We cannot go back and they are having problems with bounce backs that are a direct cause of no PTR record for our new IP.
The PTR is a record assigned to the IP Address which for a mail server is usually something like mail.domain.com.
When a server receives a connection from your server, it receives the FQDN from your SEND / SMTP Connector and also knows the IP Address you are connecting from. It may perform a reverse lookup of your FQDN and check that it resolves to the same IP Address you are connecting from and also it will check Reverse DNS (PTR) to see that the FQDN also resolves back to the connecting IP Address. If either of these checks fails, the server may reject your connection attempt and your mail will be rejected.
The responsibility for assiging PTR (Reverse DNS records is on the owner of the IP Addresses, so as that is you - that is your responsibility. How you go about this - I have no idea as it is usually done by the ISP and I have never had to set this. ISP's allow the end user to setup the PTR record - some don't.
When a server receives a connection from your server, it receives the FQDN from your SEND / SMTP Connector and also knows the IP Address you are connecting from. It may perform a reverse lookup of your FQDN and check that it resolves to the same IP Address you are connecting from and also it will check Reverse DNS (PTR) to see that the FQDN also resolves back to the connecting IP Address. If either of these checks fails, the server may reject your connection attempt and your mail will be rejected.
The responsibility for assiging PTR (Reverse DNS records is on the owner of the IP Addresses, so as that is you - that is your responsibility. How you go about this - I have no idea as it is usually done by the ISP and I have never had to set this. ISP's allow the end user to setup the PTR record - some don't.
1) ISP's will not install any address which is 172.16/12 or 10/8 or 192.168/16 in their DNS.
2) It's easy for you to setup a split dns (at least from what I see in your email). This allows you to house your internal DNS completely hidden from the out side world. All remote sites can have a secondary or a primary dns server (all depending on how your organization is setup).
3) A base drawing (I think I have the idea) would be helpful. But I think you are looking at a hub and spoke method. All sites are connected to each other via MPLS, but there is a default route which goes out to an ISP (where your dns is held). So any lookups for internal records go there. To fix this you need an internal dns seperate from your ISP.
Am I making sense or am I way off base.
DMT
2) It's easy for you to setup a split dns (at least from what I see in your email). This allows you to house your internal DNS completely hidden from the out side world. All remote sites can have a secondary or a primary dns server (all depending on how your organization is setup).
3) A base drawing (I think I have the idea) would be helpful. But I think you are looking at a hub and spoke method. All sites are connected to each other via MPLS, but there is a default route which goes out to an ISP (where your dns is held). So any lookups for internal records go there. To fix this you need an internal dns seperate from your ISP.
Am I making sense or am I way off base.
DMT
ASKER
1. Understood... rfc 1918
2. This is for a PTR record only, for Exchange to allow for HELO reponses that match the header of the email. Typically the IPS at the site where Exchange is would add PTR record for us. Unfortunately our new provider owns the physical connection, but we own the IP addresses. We bought a company that had almost 20,000 valid IP addresses. Most of which we gave back to ARIN, keeping 10 /24's for ourselves. So, now since we have a new ISP, and typically they we would use thier public IP and they would list the PTR record, they are saying because the IP belongs to us, they can't do the PTR record for us. Now email was being blocked. We since have routed all mail through our internal smart host until this is resolved. So my question was, if we own the IP, not the ISP, where does the PTR record go? Is the ISP just being stubborn? Is there any other way around this?
3. Currently our DNS is with our present ISP here at our datacenter. We have MPLS live here, but in a parallel configuration, migrating a site at a time. Once we get all the sites connected internally, i.e. WAN, we will then cut over to the public IP block here at our hub site, or data center. This is where all our public facing services are hosted. The remote sites are using the new IP's as they have client VPN's, some minor hosted services and some have Exchange servers. Hence the issue with the PTR record.
2. This is for a PTR record only, for Exchange to allow for HELO reponses that match the header of the email. Typically the IPS at the site where Exchange is would add PTR record for us. Unfortunately our new provider owns the physical connection, but we own the IP addresses. We bought a company that had almost 20,000 valid IP addresses. Most of which we gave back to ARIN, keeping 10 /24's for ourselves. So, now since we have a new ISP, and typically they we would use thier public IP and they would list the PTR record, they are saying because the IP belongs to us, they can't do the PTR record for us. Now email was being blocked. We since have routed all mail through our internal smart host until this is resolved. So my question was, if we own the IP, not the ISP, where does the PTR record go? Is the ISP just being stubborn? Is there any other way around this?
3. Currently our DNS is with our present ISP here at our datacenter. We have MPLS live here, but in a parallel configuration, migrating a site at a time. Once we get all the sites connected internally, i.e. WAN, we will then cut over to the public IP block here at our hub site, or data center. This is where all our public facing services are hosted. The remote sites are using the new IP's as they have client VPN's, some minor hosted services and some have Exchange servers. Hence the issue with the PTR record.
1) the /24's must be portable via ARIN and thus routable for the ISP to accept them. /24's are usually frowned upon in BGP advertisements to peers. Unless you have a larger block (/18+- etc).
2) Eitherway, you must setup a split dns so your internal dns reflects the internal records only.
3) Externally, the MX and SPF will point to your firewall or mail relay (pending on if you nat the inbound through a UAG or ISA or just pass it through).
4) Clients are using what as their dns server (the ISP?)
4) Your design is not anything unusual and can easily be resolved. We use MPLS all the time and multiple ISPs so you will resolve your problem.
We can take this off line if wish for privacy reasons if you wish to send more information.
DMT
2) Eitherway, you must setup a split dns so your internal dns reflects the internal records only.
3) Externally, the MX and SPF will point to your firewall or mail relay (pending on if you nat the inbound through a UAG or ISA or just pass it through).
4) Clients are using what as their dns server (the ISP?)
4) Your design is not anything unusual and can easily be resolved. We use MPLS all the time and multiple ISPs so you will resolve your problem.
We can take this off line if wish for privacy reasons if you wish to send more information.
DMT
Alan -
lighten up man...
lighten up man...
Alan -
Had an message just about to send to you, so I'm glad you reposted. No, you did your job, just a little too direct and you had prior information of "offline" which I was not directly referring to. However, water under the bridge.
Thanks for doing your job.
Sincerely,
Interframe Gap
Had an message just about to send to you, so I'm glad you reposted. No, you did your job, just a little too direct and you had prior information of "offline" which I was not directly referring to. However, water under the bridge.
Thanks for doing your job.
Sincerely,
Interframe Gap
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for sticking with this. I have been sucked into the blackhole of 'other crap to do' and apologize for not staying current with this post. We were able to get what we needed. Turns out we are stuck in paperwork at Arin. We were, as a temp solution, able to fire up the old NS's that were originally registed with Arin (as we bought the host company) and then just stuck our zone and PRT/A record there for reverse lookup. This is working and as soon as Arin acknowledges us as the new owners of these IP blocks, (we have a /20) we will then just use our current DNS provider as the authotritive name servers for these IPs. Thank you !