I have just configured a new Debian Etch machine on our office network and all is ticketyboo as I expected except...

jeff-debian:/var/log# ping shakira.aspire.local
ping: unknown host shakira.aspire.local
jeff-debian:/var/log# host shakira.aspire.local
shakira.aspire.local has address 192.168.0.117

all usual apps work like ping and fail to find any of the local machines with .local addresses but find the same machines fine if I define a fictitious .com domain on the same (admittedly horrible windows2003) dns server. Windows boxes and ubuntu boxes find .local machines as they should. This is a new on on me, anyone any clues?

That is...odd. Did you confirm that this box is using the same DNS resolver as the Windows and Ubuntu boxes?

What response do you get from Is it any different than Any difference than the same query run from the Windows and Ubuntu boxes? And all the same questions when you specify shakira.aspire.local.

Hopefully that will cough up a hint.

No point posting all possible digs because the answers are too similar, diffs of the output on the ubuntu and debian boxes reveal that dig puts more spaces in some lines on ubuntu and that the query numbers and times are different, but the information is identical. Also that the answers are essentially identical whether or not the dns server is specified, and even if I specify the alternate windows dns server.

for digging the general and specific requests the digs are as follows:-


; <<>> DiG 9.3.4 <<>> any aspire.local
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51176
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;aspire.local. IN ANY

;; ANSWER SECTION:
aspire.local. 3600 IN NS alima.jobsgopublic.local.
aspire.local. 3600 IN NS grp-svr-02.jobsgopublic.local.
aspire.local. 3600 IN SOA grp-svr-02.jobsgopublic.local. hostmaster.jobsgopublic.local. 80 900 600 86400 3600

;; ADDITIONAL SECTION:
alima.jobsgopublic.local. 3600 IN A 192.168.0.23
grp-svr-02.jobsgopublic.local. 3600 IN A 192.168.0.21

;; Query time: 0 msec
;; SERVER: 192.168.0.21#53(192.168.0.21)
;; WHEN: Sun Apr 15 11:21:18 2007
;; MSG SIZE rcvd: 167


; <<>> DiG 9.3.4 <<>> any shakira.aspire.local
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62288
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;shakira.aspire.local. IN ANY

;; ANSWER SECTION:
shakira.aspire.local. 3600 IN A 192.168.0.117

;; Query time: 0 msec
;; SERVER: 192.168.0.21#53(192.168.0.21)
;; WHEN: Sun Apr 15 11:21:59 2007
;; MSG SIZE rcvd: 54



Which all appear normal. But I still get
PING shakira.aspire.local (192.168.0.117) 56(84) bytes of data.
64 bytes from shakira.aspire.local (192.168.0.117): icmp_seq=1 ttl=64 time=1.76 ms
64 bytes from newintranet.jobsgopublic.local (192.168.0.117): icmp_seq=2 ttl=64 time=0.150 ms

on the Ubuntu box and
ping shakira.aspire.local
ping: unknown host shakira.aspire.local

on the debian, I am completely flummoxed at the moment.

What resolvers do you have configured for the Debian box? I'm wondering if perhaps you have localhost listed first, and ping is not "patient" enough to wait for that to fail and the secondary resolvers to be queried. Clearly, dig and host are getting the correct answers...is it possible that ping and other programs that fail to resolve the hostnames are simply not getting their responses quickly enough?

Of course, that doesn't begin to explain why ping gets an answer quickly enough when you set up bogus .com hostnames...

I admit I'm grasping at straws.

I've tried fiddling with name orders, with resolvers and even installing and uninstalling various dns servers, (bind bind9 and tunydns). My only thought was if there is some obscure reference somewhere to allowable TLDs or maybe to the maximum possible length of a TLD but I can't see it anywhere. If it exists it applies to all (well all I have tried) normal uses of name resolution, ssh, ping, web browsing, telnet ftp etc., but not to anything that explicitly looks up a name resolution. I shall keep digging thanks for the suggestions, any more are welcome!

I haven't come up with anything else. Have you tried running strace on the ping process or some other program in which resolution is failing? It's sort of a long shot, but it will allow you to see the steps that the program is going through in order to get the hostname resolved. It will certainly show you if you are getting to the step of actually querying the MS DNS servers, or if the program is failing before that.

Give that a shot, perhaps it will get us somewhere.