Why will one DNS alias name not resolve when others will - Bind

I am using BIND (Version 9)  for DNS services and I have a strange problem.

I have a development system with several aliases and only one is not resolving unless FQDN is used.  Thesea re all internal addresses only and all resolve to the same IP.
For example:

social.system               IN A 192.168.0.107
admin.system              IN A 192.168.0.107
sales.system                IN A 192.168.0.107
dash.system                IN A 192.168.0.107
dashboard.system       IN A 192.168.0.107
store.system                IN A 192.168.0.107

in this list . .. the only one that will not return a ping is dashboard.system
I can ping every other one and I can ping dashboard.system if I ping FQDN.  

dolphin.system.mycompany.com

I have restarted named and added ones since and still that is the only one that will not resolve  

nslookup from my vista box to the DNS server (with FQDN) will also return proper IP)

Any thoughts why?
DanRaposoAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

savoneCommented:
Well ping is not a good test for this.  There could be other reasons why it does not ping which have nothing to do with DNS.

Lets just worry about it resolving to an IP address.

can you run the following commands?

dig +trace @DNS-SERVER-IP social.system

and

dig +trace @DNS-SERVER-IP dashboard.system

(of course replace DNS-SERVER-IP with the IP address of your dns server.

0
DanRaposoAuthor Commented:
[root@pobox root]# dig +trace @192.168.0.7 social.system

; <<>> DiG 9.2.4 <<>> +trace @192.168.0.7 social.system
;; global options:  printcmd
.                       518338  IN      NS      K.ROOT-SERVERS.NET.
.                       518338  IN      NS      L.ROOT-SERVERS.NET.
.                       518338  IN      NS      M.ROOT-SERVERS.NET.
.                       518338  IN      NS      A.ROOT-SERVERS.NET.
.                       518338  IN      NS      B.ROOT-SERVERS.NET.
.                       518338  IN      NS      C.ROOT-SERVERS.NET.
.                       518338  IN      NS      D.ROOT-SERVERS.NET.
.                       518338  IN      NS      E.ROOT-SERVERS.NET.
.                       518338  IN      NS      F.ROOT-SERVERS.NET.
.                       518338  IN      NS      G.ROOT-SERVERS.NET.
.                       518338  IN      NS      H.ROOT-SERVERS.NET.
.                       518338  IN      NS      I.ROOT-SERVERS.NET.
.                       518338  IN      NS      J.ROOT-SERVERS.NET.
;; Received 492 bytes from 192.168.0.7#53(192.168.0.7) in 3 ms

.                       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2009071300 1800 900 604800 86400
;; Received 107 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 87 ms

[root@pobox root]# dig +trace @192.168.0.7 dashboard.system

; <<>> DiG 9.2.4 <<>> +trace @192.168.0.7 dashboard.system
;; global options:  printcmd
.                       518328  IN      NS      C.ROOT-SERVERS.NET.
.                       518328  IN      NS      D.ROOT-SERVERS.NET.
.                       518328  IN      NS      E.ROOT-SERVERS.NET.
.                       518328  IN      NS      F.ROOT-SERVERS.NET.
.                       518328  IN      NS      G.ROOT-SERVERS.NET.
.                       518328  IN      NS      H.ROOT-SERVERS.NET.
.                       518328  IN      NS      I.ROOT-SERVERS.NET.
.                       518328  IN      NS      J.ROOT-SERVERS.NET.
.                       518328  IN      NS      K.ROOT-SERVERS.NET.
.                       518328  IN      NS      L.ROOT-SERVERS.NET.
.                       518328  IN      NS      M.ROOT-SERVERS.NET.
.                       518328  IN      NS      A.ROOT-SERVERS.NET.
.                       518328  IN      NS      B.ROOT-SERVERS.NET.
;; Received 492 bytes from 192.168.0.7#53(192.168.0.7) in 1 ms

.                       86400   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2009071300 1800 900 604800 86400
;; Received 110 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 11 ms


0
Chris DentPowerShell DeveloperCommented:

Drop +trace. Trace is only any good for public TLDs, useless if the zone is private.

Anyway, sounds like it's far more to do with the client resolver than it is with the DNS server. The client must ask the right questions. Some systems will not append a suffix to a multi-label name, for example.

NsLookup on the other hand always will, it doesn't obey the same rules as the DNS client resolver (which Ping will use).

Given that it's resolving the rest, I take it you've configured Vista to append suffixes to multi-label names?

Chris
0
Do You Have a Trusted Wireless Environment?

A Trusted Wireless Environment is a framework for building a complete Wi-Fi network that is fast, easy to manage, and secure.

DanRaposoAuthor Commented:
Yes I have my system setup to automatically append the domain.
I can't figure out how it can be tehe client if all the other aliases are working ... this is very bizarre.

[root@pobox root]# dig @192.168.0.7 social.system

; <<>> DiG 9.2.4 <<>> @192.168.0.7 social.system
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42387
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;social.system.                        IN      A

;; AUTHORITY SECTION:
.                       10800   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2009071300 1800 900 604800 86400

;; Query time: 82 msec
;; SERVER: 192.168.0.7#53(192.168.0.7)
;; WHEN: Mon Jul 13 10:57:56 2009
;; MSG SIZE  rcvd: 107


[root@pobox root]# dig @192.168.0.7 dashboard.system

; <<>> DiG 9.2.4 <<>> @192.168.0.7 dashboard.system
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54142
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;dashboard.system.             IN      A

;; AUTHORITY SECTION:
.                       10800   IN      SOA     A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2009071300 1800 900 604800 86400

;; Query time: 12 msec
;; SERVER: 192.168.0.7#53(192.168.0.7)
;; WHEN: Mon Jul 13 10:58:28 2009
;; MSG SIZE  rcvd: 110



0
Chris DentPowerShell DeveloperCommented:

Dig isn't appending the suffix either (most likely because it didn't know it was supposed to). But it's moot, if you can resolve using the FQDN then DNS has done it's job and it has to be the DNS client failing to ask the right questions.

You might consider watching the network traffic (either at client or server side) to see which requests it's actually sending when resolving this name. If you opt to do that on the Windows side WireShark is a good package (http://www.wireshark.org/).

I agree that it's bizarre though.

Chris
0
DanRaposoAuthor Commented:
It does seem to be windows related.  I can ping from other linux and AIX systems.  Must be a new feature to block out bad words such as dashboard!!  
0
Chris DentPowerShell DeveloperCommented:

Well it is quite rude :) no?

I'm not aware of any client-side query-based blocking for the DNS service. There are a few bits and pieces on MS DNS server, but they're obviously not relevant here.

I would definitely take a look a the DNS request it's making. See if it's lying to you.

Chris
0
DanRaposoAuthor Commented:
Hey  ...is there any kind of character limit in bind?  so in other words is it possible that it is only getting dashboard?   because that would have a couple other systems with the same alias and one of which is not currently on.


Thanks
0
Chris DentPowerShell DeveloperCommented:

Sure, but it's 255 characters.

But it cannot be BIND if you get the answer when using NsLookup / Dig / other operating systems.

Chris
0
DanRaposoAuthor Commented:
What should I be looking for.  I ran wireshark.  Listened on my interface.  did a quick capture , ran ping, stopped the trace ... ran a filter for DNS and I saw a Standard query and response (no such name)

The query info had the name I was pinging as an  A record.
0
Chris DentPowerShell DeveloperCommented:

What was the name it asked for? Just "dashboard.system"?

If so, it's not appending the suffix. If you compare that with a capture when running "nslookup dashboard.system" you'll see a query for each DNS suffix on the client.

Chris
0
DanRaposoAuthor Commented:
Interestingly enough when I ran wireshark with  a successful ping to sales.system.  I got the same two responses
Standard Query  sales.system
standard query response  no such name ....  

but that ping was successful.



0
Chris DentPowerShell DeveloperCommented:

It would be worth running "ipconfig /flushdns" first.

The DNS Client won't send a query if it has a cached answer (seen with ipconfig /displaydns).

Chris
0
DanRaposoAuthor Commented:
got the same thing after running the ipconfig /flushdns command

 and again ping was successful.  


DId I mention this laptop is Vista?  I can check to confim if the others that are reporting the same thing are all on vista or XP.  In any event it's still Bizarre!!
0
DanRaposoAuthor Commented:
It appears that vista is readinganything after the . as the domain and not appending mycompany.com
0
Artysystem administratorCommented:
Hello.

This looks like a known 'feature' of Windows' 'ping'.  It tries to resolve NETBIOS name first, then DNS.
Probably you have a machine in your LAN, that is called 'dashboard', but it has different IP than dashboard.system in DNS.
You may change name resolution order via registry fix on every windows  client and try your test again.

http://support.microsoft.com/kb/172218
http://support.microsoft.com/kb/139270/EN-US/
0
Chris DentPowerShell DeveloperCommented:

> It appears that vista is readinganything after the . as the domain and not appending mycompany.com

That's the behaviour you suppressed with the group policy setting. Normally Vista wouldn't append a DNS suffix to a multi-label name (that is, a name like label1.label2 instead of just label1).

Chris
0
DanRaposoAuthor Commented:
The only workaround I can find so far is the hosts file.  


I'm still baffeled why it will find  sales.system but not dashboard.system  without a hosts file entry.!!
0
Artysystem administratorCommented:
> in this list . .. the only one that will not return a ping is dashboard.system

My next suggestion is that this name is too long for windows :-) I bet it will resolve dashboar.system (15 chars long) as it is a valid NetBIOS PC name length. dashboard.system is the only name >15 chars (16 chars long), all the others are shorter.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Artysystem administratorCommented:
And unless you use FQDN it tries to resolve NetBIOS name first, as per above  Microsoft KB article.
0
Chris DentPowerShell DeveloperCommented:

Windows XP can resolve it properly, which is pretty annoying ;)

I'll try on my Vista machine tonight, meant to do that last night and got distracted by dinner.

Chris
0
DanRaposoAuthor Commented:
Damn you Chris ... Dinner ....  You are NOT allowed to be distracted by such things ;-)

My question is unless I missed it the KB articles mentioned above do not tell me how to resolve dns names first for vista (or XP even)  Those were related to much much older operating systems.   So how do I tell Vista to resolve DNS first?   I might be missing the obvious here ... hopefully that is the case.
0
Chris DentPowerShell DeveloperCommented:

I was under the impression that Vista did use DNS first. Still, you can eliminate NetBIOS by disabling it on the network interface (WINS tab, disable NetBIOS over TCP/IP).

Chris
0
Artysystem administratorCommented:
I did a registry fix on my PC. But not on Vista, on XP, it worked.
http://smallvoid.com/article/winnt-host-name-resolution.html still may fit well Vista. Just check your registry.
0
Artysystem administratorCommented:
hehe
here is the exact answer to your question, I was wrong.
http://blogs.technet.com/networking/archive/2009/04/16/dns-client-name-resolution-behavior-in-windows-vista-vs-windows-xp.aspx

This registry entry works for both Windows XP and Windows Vista

HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName
Type = DWORD

Data:

    * 0 (Do not Append Suffix)
    * 1 (Append suffix)

0
Chris DentPowerShell DeveloperCommented:

That registry entry / policy setting is why the question at the end of my first post was "Given that it's resolving the rest, I take it you've configured Vista to append suffixes to multi-label names?" :)

But if it's working for the rest it does imply it is set. It shouldn't be selective about which it appends to.

Chris
0
DanRaposoAuthor Commented:
The answer was the gpedit solution:


Group Policy location (for Windows Vista only) - (run gpedit.msc):
Computer Configuration -> Administrative Templates -> Network -> DNS Client -> Allow DNS Suffix Appending to Unqualified Multi-Label Name Queries
Note: As with other GPOs, if you change the registry and there is also a GPO configured then GPO will override this registry value.


Thank you all for your help
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
DNS

From novice to tech pro — start learning today.