External DNS PTR Record Issue.
In the company I work for we have multiple ISP's who have all delegated DNS responsibilities to our 3 DNS servers.
I have created all the forward zones and reverse zones the data appears to be correct.
How ever for some strange reason the mail server does not have a PTR record causing emails to bounce back.
I have tried searching around here for a problem similar to this and I constantly run into people who have the same issue but didn't have there ISP delegate responsibility to them.
In my situation the responsibility has been delegated and prior to this situation we were running BIND and everything functioned correctly. We have only made the switch over less then a week. We changed a few IP addresses but not the mail servers and one of the ISP's reverse zone with respect to ptr records doesn't work at all. The other ISP reverse zones function correctly.
Another thing to mention is reverse look ups work when using nslookup directly on the server, however using nslookup server 4.2.2.2 or a similar global dns server only forward look ups work. With the exception of the other ISP's we deal with, where all records work.
I have tried everything i can think of and everything seems correct. I have ruled out a firewall or router issue and have contact all the ISP's to double verify there configuration is correct.
I really hope this is a configuration issue with windows dns that I am missing and not something super complicated. In a situation like this If i am correct any changes i make to our external dns servers are pushed out immediately.
The only issue i can think of that would remotely effect this is the fact that the external dns servers are not part of active directory and therefor the host name of the machine does not accurately reflect the domain. I have been planning to append the dns suffix in advanced properties but feel like this is related maybe.
any help is appreciated.
thanks
I have created all the forward zones and reverse zones the data appears to be correct.
How ever for some strange reason the mail server does not have a PTR record causing emails to bounce back.
I have tried searching around here for a problem similar to this and I constantly run into people who have the same issue but didn't have there ISP delegate responsibility to them.
In my situation the responsibility has been delegated and prior to this situation we were running BIND and everything functioned correctly. We have only made the switch over less then a week. We changed a few IP addresses but not the mail servers and one of the ISP's reverse zone with respect to ptr records doesn't work at all. The other ISP reverse zones function correctly.
Another thing to mention is reverse look ups work when using nslookup directly on the server, however using nslookup server 4.2.2.2 or a similar global dns server only forward look ups work. With the exception of the other ISP's we deal with, where all records work.
I have tried everything i can think of and everything seems correct. I have ruled out a firewall or router issue and have contact all the ISP's to double verify there configuration is correct.
I really hope this is a configuration issue with windows dns that I am missing and not something super complicated. In a situation like this If i am correct any changes i make to our external dns servers are pushed out immediately.
The only issue i can think of that would remotely effect this is the fact that the external dns servers are not part of active directory and therefor the host name of the machine does not accurately reflect the domain. I have been planning to append the dns suffix in advanced properties but feel like this is related maybe.
any help is appreciated.
thanks
all you need to do is contact your ISP and ask the to put a PRT record of your EXCHANGE SERVER on to THERE DNS SERVER with a FQDN to go with that.
your emails will get bounced back if this is not done because the receiver's email provider can not verify where the email has come from unless the prt record has been put in place in your ISP dns server. This can be done very easily by contacting them unless your with BT then it becomes a nightmare.
your emails will get bounced back if this is not done because the receiver's email provider can not verify where the email has come from unless the prt record has been put in place in your ISP dns server. This can be done very easily by contacting them unless your with BT then it becomes a nightmare.
ASKER
Receiving mail works perfectly fine. Sending mail makes it to most recipients just not those who block smtp servers without a PTR.
I realize i could contact the ISP but that doesn't actually solve the problem because we didn't need to do that when we were running bind. Its a MX records are correct and the smtp server can be resolved forwardly from any dns server in the world indicating the A record is correct. Same exact setup amoung all the isp's except one doesnt work.
I realize i could contact the ISP but that doesn't actually solve the problem because we didn't need to do that when we were running bind. Its a MX records are correct and the smtp server can be resolved forwardly from any dns server in the world indicating the A record is correct. Same exact setup amoung all the isp's except one doesnt work.
What does DNSReport on www.dnsstuff.com say about your PTR record? Are there any red sections pertinent to Email?
ASKER
Dnsstuff wants you to pay for the free trial, not really interested in that. however I did try pingability.com and it reports the same no ptr record for the mail server=
Heads-up This mail server has no reverse DNS (PTR) record. Some email servers require a PTR record from any server that connects to them and reject any email from a mail server without a PTR record.
Heads-up This mail server has no reverse DNS (PTR) record. Some email servers require a PTR record from any server that connects to them and reject any email from a mail server without a PTR record.
ISP's do not normally delegate the reverse zones for security reasons, you need to get with your ISP and make sure you have them enter the reverse zones and ptr records for you, you will not get this fixed until that gets completed.
then remember after that it can still take up to 48 hrs to propogate and get correct.
then remember after that it can still take up to 48 hrs to propogate and get correct.
ASKER
Normally peralesa i would agree with you. But in this case I cant. I have double confirmed with the ISP that isnt working that reverse dns delegation has been delagated to our name servers.
I want to just mention again that everything worked fine until we switched from Bind to windows. All PTR records have been correctly assigned but for some strange reason there not propagating. the smtp server address never changed in the process.
Here is a dig - trace on the IP block i did from my spare linux box
dig -x 8.10.?.? +trace
; <<>> DiG 9.2.4 <<>> -x 8.10.?.? +trace
;; global options: printcmd
. 18035 IN NS a.root-servers.net.
. 18035 IN NS b.root-servers.net.
. 18035 IN NS c.root-servers.net.
. 18035 IN NS d.root-servers.net.
. 18035 IN NS e.root-servers.net.
. 18035 IN NS f.root-servers.net.
. 18035 IN NS g.root-servers.net.
. 18035 IN NS h.root-servers.net.
. 18035 IN NS i.root-servers.net.
. 18035 IN NS j.root-servers.net.
. 18035 IN NS k.root-servers.net.
. 18035 IN NS l.root-servers.net.
. 18035 IN NS m.root-servers.net.
;; Received 488 bytes from 10.67.0.17#53(10.67.0.17) in 15 ms
8.in-addr.arpa. 86400 IN NS NS2.LEVEL3.NET.
8.in-addr.arpa. 86400 IN NS NS1.LEVEL3.NET.
;; Received 88 bytes from 198.41.0.4#53(a.root-serve
?.?.10.8.in-addr.arpa. 3600 IN CNAME 11.?.?.10.8.in-addr.arpa.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
;; Received 176 bytes from 209.244.0.2#53(NS2.LEVEL3.
Where ?.?.com indicates my dns servers. As far as I can tell Level3 has delegated reverse delagation. But something about the windows dns server just isnt serving the info. If i just knew where to look for the problem i think id be ok. But i have checked everything to noavail.
I want to just mention again that everything worked fine until we switched from Bind to windows. All PTR records have been correctly assigned but for some strange reason there not propagating. the smtp server address never changed in the process.
Here is a dig - trace on the IP block i did from my spare linux box
dig -x 8.10.?.? +trace
; <<>> DiG 9.2.4 <<>> -x 8.10.?.? +trace
;; global options: printcmd
. 18035 IN NS a.root-servers.net.
. 18035 IN NS b.root-servers.net.
. 18035 IN NS c.root-servers.net.
. 18035 IN NS d.root-servers.net.
. 18035 IN NS e.root-servers.net.
. 18035 IN NS f.root-servers.net.
. 18035 IN NS g.root-servers.net.
. 18035 IN NS h.root-servers.net.
. 18035 IN NS i.root-servers.net.
. 18035 IN NS j.root-servers.net.
. 18035 IN NS k.root-servers.net.
. 18035 IN NS l.root-servers.net.
. 18035 IN NS m.root-servers.net.
;; Received 488 bytes from 10.67.0.17#53(10.67.0.17) in 15 ms
8.in-addr.arpa. 86400 IN NS NS2.LEVEL3.NET.
8.in-addr.arpa. 86400 IN NS NS1.LEVEL3.NET.
;; Received 88 bytes from 198.41.0.4#53(a.root-serve
?.?.10.8.in-addr.arpa. 3600 IN CNAME 11.?.?.10.8.in-addr.arpa.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
;; Received 176 bytes from 209.244.0.2#53(NS2.LEVEL3.
Where ?.?.com indicates my dns servers. As far as I can tell Level3 has delegated reverse delagation. But something about the windows dns server just isnt serving the info. If i just knew where to look for the problem i think id be ok. But i have checked everything to noavail.
I have had a few real live situations where an ISP has made a typo in entering IP addresses. I also remember this has come out in a couple of questions I've been involved with on EE. Ask the ISP how you personally can verify that the records are setup correctly.
ASKER
I'll have to look into that and see. Nowadays ISP's are stepping it up a bit and you don't need to indicate the IP addresses of your name servers they do there own research to figure it out. In the end everything lines up correctly very weird situation. . . . .
Other issues i have seen is that they do not clean out ptr records and reverse zones, get with them and make sure that all ptr records are gone and only clean new ones exist. Ask them to send you a print out of all you dns zones and you can verify yourself as well.
ASKER
Yea I am gonna have to fight with them on this one I think. Its good to know if I dont get anyplace i can always have them just assign the record for me. Just weird how it would work fine in BIND and not windows.
> .?.?.10.8.in-addr.arpa.
Exactly how have you created the zone name on your DNS server?
I'm sure you've probably done it properly, but as something is broken it does need a spot of verification.
Or is there any chance you can post the IP that's supposed to work? We can check the delegation and authoritative server from the outside.
What puzzles me slightly is that you state the reverse lookup works correctly from the server itself. Does that mean you're performing a query like this?
nslookup -q=ptr 11.?.?.10.8.in-addr.arpa
Rather than:
nslookup -q=ptr 11.xx.10.8.in-addr.arpa
Chris
ASKER
Chris-dent I created the reverse zone with the full ip address no question marks. When I run this command nslookup -q=ptr 11.xx.10.8.in-addr.arpa with the full IP address locally on the server I get the correct hostname back from the server. Honestly that makes me feel comfortable about the configuration Ive done.
I have listed the delegation above, but the more i think about it the more I feel like Level 3 isnt doing something right since my dns server hosts over 20 domains and more then 4 sets of IP ranges for reverse lookup ONLY this range doesnt work. All the other ones do.
I have listed the delegation above, but the more i think about it the more I feel like Level 3 isnt doing something right since my dns server hosts over 20 domains and more then 4 sets of IP ranges for reverse lookup ONLY this range doesnt work. All the other ones do.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Ack, missed it off.
This one is the classless delegation:
?.?.10.8.in-addr.arpa. 3600 IN CNAME 11.?.?.10.8.in-addr.arpa.
?.?.10.8.in-addr.arpa. 3600 IN NS ?.?.com.
A query for anything outside of that specific delegated scope will not be forwarded to your server to answer.
Chris
ASKER
Wait!
When you asked this question . . . . . . . ..
nslookup -q=ptr 11.?.?.10.8.in-addr.arpa
Rather than:
nslookup -q=ptr 11.xx.10.8.in-addr.arpa
I told you it was the second option but it really was the first. I forgot my external ip ends in 11 but there is also a second 11 after for the cname
When you asked this question . . . . . . . ..
nslookup -q=ptr 11.?.?.10.8.in-addr.arpa
Rather than:
nslookup -q=ptr 11.xx.10.8.in-addr.arpa
I told you it was the second option but it really was the first. I forgot my external ip ends in 11 but there is also a second 11 after for the cname
Okay, the first is rather better :)
Then we could do with seeing why your server isn't responding to (or receiving) the request from the outside. There's no chance you can share the IP with us?
Chris
ASKER
Heres the answer. . . .
Out of the 3 ISP's the one that was giving problems we dont have a /24 we have a /25
Therefor in order to get this to work I had to rename the zone to what they call the cname on there end
0-127.11.x.x.in-addr.arpa
Key thing being that 0-127
Out of the 3 ISP's the one that was giving problems we dont have a /24 we have a /25
Therefor in order to get this to work I had to rename the zone to what they call the cname on there end
0-127.11.x.x.in-addr.arpa
Key thing being that 0-127
ASKER
Thanks for your help. Funny thing in the first paragraph you wrote you answered the question i just hadn't realized it till now.
Thanks,
Leon
Thanks,
Leon
Well yeah, that would hopefully match up with the CNAME referenced in the classless delegation which is why I was asking about how you were performing the query.
In effect, for classless delegation there is no way the query should have worked from your own server unless you were querying the CNAME value.
Unfortunately there are a few different ways to write records of that kind so unless you tell us specifics it's difficult to give specific advice :)
Chris
Ah well, I'm certainly glad that you found it :) Classless delegation is one of the less obvious things we have to deal with :)
All that best.
Chris
http://centralops.net/co/
You should have an MX record that points to your mail server DNS name and and an A record references the public IP address of your mail server. If you don't see all the correct settings there then the ISP hasn't done their part yet.