On Fri, Aug 6, 2010 at 10:23 AM, [email protected] <[email protected]> wrote: > There is a ptr for mail.imcu.com to 206.18.123.221 though.
You've got that backwards. Also, you should understand that reverse-lookups (number-to-name) and forward-lookups (name-to-number) have no inherent relationship. They're resolved by completely different paths, and generally the nameservers are hosted by completely different organizations. Forward: When I look up "mail.imcu.com", my query eventually goes to UltraDNS and they give me an IP address. Specifically, in the zone <imcu.com.>, hosted by UltraDNS, there is an A (address) record: mail.imcu.com. A 206.18.123.221 You can associate whatever IP address you want with a name you own. You could associate Microsoft's web site IP address with <foo.imcu.com.> if you wanted to. Reverse: When I look up the IP address "206.18.123.221", that gets turned into a query for <221.123.18.206.in-addr.arpa.>. ARPA dates back to when the Internet was the ARPANET. "in-addr" is short for "Internet address", a special domain reserved for reverse lookups. Note that the order of the address octets is reversed. IP addresses put the most significant part first. For example, in 206.18.123.221, 208 might be a big network operator, 18 might be the area you're in, 123 might be a sub-network delegated to you, and 221 might be one of your nodes.[1] Conversely, DNS puts the most significant part last. For example, in <mail.imcu.com.>, the "com" is the most significant. So the IP address order gets reversed to work for DNS. Anyway, that leads me to a completely separate zone, <123.18.206.in-addr.arpa.>, hosted by AT&T, where there are CNAME and PTR records: 221.123.18.206.in-addr.arpa. CNAME 221.208/28.123.18.206.in-addr.arpa. 221.208/28.123.18.206.in-addr.arpa. PTR 03030611n4m055.imcu.local. The CNAME in the reverse lookup has to do with how your ISP has structured their network. The details of that aren't relevant to this problem. But the PTR tells me that 206.18.123.221 is associated with <03030611n4m055.imcu.local.> As before, whoever "owns" the DNS zone can say whatever they want. They could claim 206.18.123.221 is associated with <www.google.com.> if they wanted to. How <03030611n4m055.imcu.local.> got in there is anybody's guess. Perhaps someone at your organization made a mistake when registering things with AT&T. Perhaps AT&T had their servers open to dynamic DNS update, and one of your systems tried to register itself that way. Either which way, you'll have to contact AT&T to get it fixed, as others have said. -- Ben [1] Technically, I can tell from the CNAME that AT&T's network is *not* laid out this way. But the reality is more confusing and not relevant to this problem. Hence I pretend I don't know and write "might". ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
