I noticed this problem when my mail server stopped sending out emails. I was receiving them, but couldn't send them... getting the following message in my mail log:

Dec 28 13:49:46 control postfix/smtpd[22084]: connect from hanochnet.org[24.249.75.134]
Dec 28 13:49:46 control postfix/smtp[22083]: warning: host pack944.org[::ffff:24.249.75.134] greeted me with my own hostname hanochnet.org
Dec 28 13:49:46 control postfix/smtp[22083]: warning: host pack944.org[::ffff:24.249.75.134] replied to HELO/EHLO with my own hostname hanochnet.org
Dec 28 13:49:47 control postfix/smtp[22083]: BDDFA1FBDD: to=<test@pack944.org>, relay=pack944.org[::ffff:24.249.75.134], delay=1, status=bounced (mail for pack944.org loops back to myself)

My server is called hanochnet.org[24.249.75.134] and I was trying to send to another domain called pack944.org, which is at IP [74.126.25.10]. I get messages like this for every email I try to send, regardless of the domain I'm sending to... mac.com, yahoo.com, google.com, ... doesn't matter, it still resolves the IP to my own static IP of 24.249.75.134.

So I started trying to figure out why this was happening... I did an nslookup and dig to find out what the host returned as the IP:

control:~ # nslookup pack944.org
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
Name: pack944.org
Address: 74.126.25.10

control:~ # nslookup pack944.org
Server: 192.168.1.254
Address: 192.168.1.254#53

Non-authoritative answer:
Name: pack944.org
Address: 74.126.25.10

Dig reports the following:

control:~ # dig pack944.org

; <<>> DiG 9.2.4 <<>> pack944.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15125
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;pack944.org. IN A

;; ANSWER SECTION:
pack944.org. 30 IN A 74.126.25.10

;; AUTHORITY SECTION:
pack944.org. 30 IN NS ns1.a2webhosting.com.
pack944.org. 30 IN NS ns2.a2webhosting.com.

;; Query time: 2 msec
;; SERVER: 192.168.1.254#53(192.168.1.254)
;; WHEN: Sun Dec 28 14:27:25 2008
;; MSG SIZE rcvd: 97

Yet, when I try to telnet on port 25 to the pack944.org host, I get the following response:

control:~ # telnet pack944.org 25
Trying ::ffff:24.249.75.134...
Connected to pack944.org.
Escape character is '^]'.
220 hanochnet.org ESMTP Postfix
helo anydomain.com
250 hanochnet.org
quit
221 Bye
Connection closed by foreign host.
control:~ #

Any ideas why the DNS for pack944.org would point to my own server when I do a telnet, but not when I do a nslookup or dig?

Thanks,
Jeff

An idea: nslookup and dig always make an explicit call to the DNS system.
Try looking at /etc/nsswitch.conf to check that the DNS is effectively used to resolve host names, and then give a look at least at the file /etc/hosts that contains static mappings... just an idea, but I think you should check this

Thanks for the response. I had already checked the hosts file, but not the nsswitch file. I don't see anything wrong with it and it hasn't changed since last Feb. I'm not sure what to look for, but here's the nsswitch file.

passwd: compat
group: compat
hosts: files lwres dns
networks: files dns
services: files
protocols: files
rpc: files
ethers: files
netmasks: files
netgroup: files
publickey: files
bootparams: files
automount: files nis
aliases: files

And here's the hosts file.

# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback
fe00::0 ipv6-localnet
ff00::0 ipv6-mcastprefix
ff02::1 ipv6-allnodes
ff02::2 ipv6-allrouters
ff02::3 ipv6-allhosts

127.0.0.1 localhost
192.168.4.1 control.hanochnet.org control

Also of interest, I noticed that when I disabled the NAT loopback on my router (running Tomato firmware) that this problem went away. Unfortunately, my internal network did not work so well. Yesterday I went and bought a new router which unfortunately does not run the Tomato firmware, so I've got the default netgear stuff. I don't see a place to turn off the NAT loopback to see if that works. Any idea why no NAT loopback would fix it? Strange thing is that I've been working with this setup for a long time. It was not a new setup. It's like one day a switch was flipped and now I have this dns issue. Could this be due to internet provider?

Thanks,
Jeff

Ok, I think I figured out something on this.

I've got the DNS records for my hanochnet.org domain setup as follows:


A hanochnet.org 24.249.75.134
A *. hanochnet.org 24.249.75.134
A mail. hanochnet.org 24.249.75.134
MX hanochnet.org control.hanochnet.org 10
MX *. hanochnet.org control.hanochnet.org 10

Notice the wildcard entry... this is to catch any DNS request sent to hanochnet.org... e.g. mail.hanochnet.org, www.hanochnet.org, etc.

On my internal network... Everything is behind a wireless router. I had setup the router's domain name to be hanochnet.org. Apparently this causes the DNS lookups to start looking at the hanochnet.org domain first, then if it can't find an answer it searches the external DNS servers.

So it looks like what was happening was that DNS lookups were resolving back to my own external IP address... for example, mac.com was being searched as mac.com.hanochnet.org which ended up resolving to my ip due to the wildcard.

What I don't get is why it worked with some things and not others... I could do nslookups and ping, but could not telnet. I also don't understand why started doing this... I've had things setup this way for many months.

Oh well, I think to fix this I should remove the wildcard from my DNS records... and continue calling my local network hanochnet.org. How do others out there handle this?

Thanks,
Jeff

Hi Jeff, did you manage to solve this issue? I'm experiencing the exact same scenario.. Cannot even do an aptitude upgrade, as the debian domains resolve all to my own wan ip. Exactly the same, dig/nslookupresolve both fine, telnet resolves wrong, as does aptitude. Hoping for a clue.

I Never did completely understand this issue. But by removing the wildcard entry on the domains DNS records, and renaming my internal network so that it does not match my domain name, the problem has gone away. Wish I could tell you more, but at least it is working now. Strange.

Thank you, will do the same, and I'll test a new debian lenny install in a virtualbox first.. Yet it does not seem as if Bind is broken..

Well I just setup a fresh Lenny, in a Virtualbox, and guess what, same problem out of the box. Must be an ISP, Lan or a DNS problem, as Jeff said. Let's rule things out, will post again if I find any solution.

I seem to have 'solved' it, posting it here for Google purposes: my hosting ISP, where my domain is on one of their dns's, seems to have changed something. When I change the hostname domain in /etc/hostname to one of my other domains (.nl instead of .net, other ISP), everything works as before, with wildcards. I cannot figure out exact cause of it.