3

The issue described here is not solved.

But there are some updates. When i do a "dig" with no flags i get a timeout error. When i add a "+trace" option, it resolves.

Can anyone point me to the reason for that?

UPD

Well, i found the reason why it differs, when +trace is used, you"re not getting an answer from the local nameserver but perform iterative resolution itself.

So i"m still with the mail problem.

Community
  • 1
gtfx
  • 193
  • I am having a similar issue where I get a different IP when using +trace (the one I expect), but this is with MS DNS and I don't have a solution either :-/ – Kyle Brandt Sep 15 '09 at 13:27
  • I updated the post, maybe it will be helpful for your issue – gtfx Sep 15 '09 at 14:12

2 Answers2

4

If "dig +trace" is yielding the correct results but "dig" itself is not, then it sounds like whatever servers you are using locally have not expired in the invalid results yet. (I looked at the other thread, it looks like some DNS changes were made recently).

You can use "dig @x.x.x.x" (where x.x.x.x is another DNS server) on a couple of different servers to verify this.

Fixing: You can "fix" this by clearing the cache/rebooting your resolving nameserver, if you have control over it. If you do not, you will have to wait until the Time-To-Live expires. Or...

Workaround: On the servers that need to resolve that host, you can create an entry in /etc/hosts (assuming you are on *nix of some sort, Windows has a hosts file as well though) mapping the host in question with an appropriate IP address. Just remember to remove this entry when DNS finally updates.

Charles Hooper
  • 1,530
0

Your local nameserver is busted in some way. Post your bind config, maybe? /etc/resolv.conf ?

Bill Weiss
  • 11,089