• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 682
  • Last Modified:

How to figure out who handles reverse DNS

My company currently has an Exchange 2003 server and we are in the process of migrating to Exchange 2010. I'm to the point where I need reverse DNS setup for the new server but cannot figure out who would handle this for us. Our public IPs are from Sprint but we manage our own MX and A records through Verio. If I go to dnsstuff.com and do a reverse lookup on our current Exchange server's IP address, the nameserver that responds is from Sprintlink but when I put in a request for Sprint to setup rDNS for the new server they tell us that Verio would handle this for us. When I call Verio they say Sprint needs to set it up because they own the IP address. I can't find any internal documentation telling me who is handling the rDNS for our current Exchange server so I'm stuck in a finger-pointing loop between Sprint and Verio. Does anyone have any idea how to determine who is currently handling our rDNS so I can also have them set up the new record?
0
cella1175
Asked:
cella1175
  • 6
  • 4
  • 3
  • +3
2 Solutions
 
ChrisCommented:
The IP address owner will manage rDNS. In this case, Sprint.
0
 
Alan HardistyCo-OwnerCommented:
This can vary from ISP to ISP.  Some allow you through DNS to setup your own Reverse DNS record, but it is usually the ISP who allocates the IP Address to you, rather than anyone else.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
didnthaveanameCommented:
Whomever's name servers your registrar is pointing at is who is hosting your DNA records and would also need to add the pointer records.  For an absolute answer, find out where the registrar for your domain is pointing for your name servers.
0
 
baller119Commented:
If Verio and Sprint want to argue, get them both on a conference call with you and have them sort it out. rDNS is a routine request and is easy enough to change...you just have to get to the right person.
0
 
ChrisCommented:
didnthaveaname, this is incorrect as far as reverse DNS goes. A reverse DNS query isn't a query against your domain. It is a query against a DNS name derived from your IP which will return your domain (if thats what you want it to return). The IP address owner (or whoever they delegate to) is the only person with the power to change a rDNS entry.
0
 
didnthaveanameCommented:
Ps - I may be wrong after reading some other comments, my perspective is from that of a company who hosts it's own name servers and is allocated large blocks of public ips - we set up our own pointer records.
0
 
baller119Commented:
See Sprint's help page for rDNS (mid-way down the page)

https://www.sprint.net/index.php?p=policy_dns

Does Verio handle your primary DNS?
0
 
Jan SpringerCommented:
Don't confuse forward DNS (MX, A, CNAME records) with inverse DNS (PTR records).

The provider or end point to which the IPs are allocated frm the RIR is delegated inverse DNS.  From there, your provider may turn around and delegate them to you.

You can run a dig +trace on all forward and inverse zone files to get that information.

If you want to provide the domain name and IP addresses, I can show you how that information is obtained.
0
 
cella1175Author Commented:
jesper,
The domain name is mail.domain.com and the 2 IP addresses are 65.xxx.xxx.195 (ex2003) and 65.xxx.xxx.206 (ex2010).
Thanks!
0
 
ChrisCommented:
You've already checked this though. You mentioned in your original post that you've done a reverse lookup and the server was sprint's. Dig will only provide you with the same result but with all intermediate DNS servers in the middle.

Sprint are responsible, you just need to get hold of someone who knows what they're talking about.

If you really want the dig output, i've pasted it below:

For 65.xxx.xxx.195:

.                  213      IN      NS      i.root-servers.net.
.                  213      IN      NS      m.root-servers.net.
.                  213      IN      NS      e.root-servers.net.
.                  213      IN      NS      c.root-servers.net.
.                  213      IN      NS      a.root-servers.net.
.                  213      IN      NS      d.root-servers.net.
.                  213      IN      NS      j.root-servers.net.
.                  213      IN      NS      f.root-servers.net.
.                  213      IN      NS      g.root-servers.net.
.                  213      IN      NS      h.root-servers.net.
.                  213      IN      NS      k.root-servers.net.
.                  213      IN      NS      l.root-servers.net.
.                  213      IN      NS      b.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 13 ms

in-addr.arpa.            172800      IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      c.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      a.in-addr-servers.arpa.
;; Received 421 bytes from 192.36.148.17#53(i.root-servers.net) in 24 ms

65.in-addr.arpa.      86400      IN      NS      r.arin.net.
65.in-addr.arpa.      86400      IN      NS      t.arin.net.
65.in-addr.arpa.      86400      IN      NS      u.arin.net.
65.in-addr.arpa.      86400      IN      NS      v.arin.net.
65.in-addr.arpa.      86400      IN      NS      w.arin.net.
65.in-addr.arpa.      86400      IN      NS      x.arin.net.
65.in-addr.arpa.      86400      IN      NS      y.arin.net.
65.in-addr.arpa.      86400      IN      NS      z.arin.net.
;; Received 181 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 50 ms

160.65.in-addr.arpa.      86400      IN      NS      NS2-AUTH.SPRINTLINK.NET.
160.65.in-addr.arpa.      86400      IN      NS      NS3-AUTH.SPRINTLINK.NET.
160.65.in-addr.arpa.      86400      IN      NS      NS1-AUTH.SPRINTLINK.NET.
;; Received 128 bytes from 199.180.180.63#53(r.arin.net) in 16 ms

195.xxx.xxx.65.in-addr.arpa. 86400 IN      PTR      mail.ams-leads.com.
xxx.65.in-addr.arpa.      86400      IN      NS      ns1-auth.sprintlink.net.
xxx.65.in-addr.arpa.      86400      IN      NS      ns2-auth.sprintlink.net.
xxx.65.in-addr.arpa.      86400      IN      NS      ns3-auth.sprintlink.net.
;; Received 160 bytes from 144.228.254.10#53(NS2-AUTH.SPRINTLINK.NET) in 58 ms


For 65.xxx.xxx.206:

.                  9      IN      NS      i.root-servers.net.
.                  9      IN      NS      m.root-servers.net.
.                  9      IN      NS      e.root-servers.net.
.                  9      IN      NS      c.root-servers.net.
.                  9      IN      NS      a.root-servers.net.
.                  9      IN      NS      d.root-servers.net.
.                  9      IN      NS      j.root-servers.net.
.                  9      IN      NS      f.root-servers.net.
.                  9      IN      NS      g.root-servers.net.
.                  9      IN      NS      h.root-servers.net.
.                  9      IN      NS      k.root-servers.net.
.                  9      IN      NS      l.root-servers.net.
.                  9      IN      NS      b.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 15 ms

in-addr.arpa.            172800      IN      NS      f.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      e.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      a.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      d.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      b.in-addr-servers.arpa.
in-addr.arpa.            172800      IN      NS      c.in-addr-servers.arpa.
;; Received 421 bytes from 192.36.148.17#53(i.root-servers.net) in 25 ms

65.in-addr.arpa.      86400      IN      NS      y.arin.net.
65.in-addr.arpa.      86400      IN      NS      t.arin.net.
65.in-addr.arpa.      86400      IN      NS      w.arin.net.
65.in-addr.arpa.      86400      IN      NS      x.arin.net.
65.in-addr.arpa.      86400      IN      NS      u.arin.net.
65.in-addr.arpa.      86400      IN      NS      v.arin.net.
65.in-addr.arpa.      86400      IN      NS      r.arin.net.
65.in-addr.arpa.      86400      IN      NS      z.arin.net.
;; Received 181 bytes from 193.0.9.1#53(f.in-addr-servers.arpa) in 105 ms

xxx.65.in-addr.arpa.      86400      IN      NS      NS3-AUTH.SPRINTLINK.NET.
xxx.65.in-addr.arpa.      86400      IN      NS      NS1-AUTH.SPRINTLINK.NET.
xxx.65.in-addr.arpa.      86400      IN      NS      NS2-AUTH.SPRINTLINK.NET.
;; Received 128 bytes from 192.42.93.32#53(y.arin.net) in 71 ms

xxx.65.in-addr.arpa.      7200      IN      SOA      ns1-auth.sprintlink.net. dns-admin.sprint.net. 2013040101 43200 3600 2419200 7200
;; Received 121 bytes from 144.228.255.10#53(NS3-AUTH.SPRINTLINK.NET) in 1 ms
0
 
Jan SpringerCommented:
SprintLink is allocated those IPs and while they are swipped to AMS, SprintLink handles inverse DNS.

ns11a.verio-web.com and ns11b.verio-web.com handle forward DNS for ams-leads.com.

So, you contact SprintLink when you need a PTR record changed for an IP and you contact Verio when you need a host name updated for an MX, A or CNAME (etc.) record.
0
 
Jan SpringerCommented:
So, in other words, Verio is right.  If you want the inverse DNS to work, SprintLink needs to do it.
0
 
Jan SpringerCommented:
Registered domain names and IP address allocations/assignments are already a matter of public record.  

There is no security loss by identifying the zone names.  Really.
0
 
Jan SpringerCommented:
Then I'll have no choice but to recommend another forum where those of us that do understand security can truly help people fix their respective problems.

We do know when to say "please be sure to redact <whatever>".
0
 
baller119Commented:
You could just ask the guy to call Sprint and not worry about all of the IPs being listed.
0
 
cella1175Author Commented:
Sorry if providing that information caused a problem. I'm new to EE and didn't think it was an issue but I'm also not that concerned with the info being out there because it is a matter of public record. I'm just glad for the assistance at this point. I have sent an email to our account manager at Sprint since their engineers keep pushing us back to Verio. I'll post an update when I hear back.
0
 
Jan SpringerCommented:
Thank you.  I was pretty sure that EE didn't define a rule which disallowed the posting of such data.

But, yes, sometimes this information is necessary to resolve a problem.
0

Featured Post

Evaluating UTMs? Here's what you need to know!

Evaluating a UTM appliance and vendor can prove to be an overwhelming exercise.  How can you make sure that you're getting the security that your organization needs without breaking the bank? Check out our UTM Buyer's Guide for more information on what you should be looking for!

  • 6
  • 4
  • 3
  • +3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now