• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2912
  • Last Modified:

Can only ping by Netbios name, not FQDN

This is what I know so far:
Name resolution is only partially working. We have 6 VLANs associated with DHCP scopes. Users in some VLANs (IT, VPN, etc) are functioning normal using the same DNS/WINS/DHCP/Domain Controller servers as the other five.

Most users (not all) in the Employee and wireless VLANs can do an NSLOOKUP on FQDNs but they can’t ping by FQDN. They CAN ping by Netbios and IP.

Other users in the same VLANs are able to ping by FQDN.

The affected users' NICs in the employee/VPN VLANs are showing in Network settings as being part on the wireless VLAN but are getting their IP from the Employee VLAN.

DHCP scopes have not been changed except after the fact to take DC01 out of the mix due to issues with CPU saturation.
In DNS,  there are no errors other than an old one which is not related.
WINS has no errors and appears to be functioning properly.
There are no entries in AD logs about broken trusts or anything other than our typical assortment of entries. There is nothing unusual in there.

I have no idea how to even troubleshoot this from this point. Please help.
1 Solution
I think this might be a reverse DNS lookup issue.  Make sure you have a reverse lookup zone in DNS.
GusGallowsAuthor Commented:
We do have reverse lookup zones for each subnet and those have not changed.
When the name address resolution takes place are they all resolving to the same address?

nslookup Server1
nslookup Server1.domain.com
ping Server1
ping Server1.domain.com

If they don't resolve to the same address the place to look is name resolution.  Don't forget that there are local files that are part of the name resolution process.  The files can be found in %windir%\system32\drivers\etc.  Both files do NOT have a file extension (. )

   hosts          for tcp/ip standard name to address resolution
   lmhosts     for Netbios over TCP/IP (netbt) name to address resolution

If they resolve to different addresses you will need to determine WHY they resolve to different addresses, and also perform a tracert (or pathping) to those other addresses.

Good luck.
Get 10% Off Your First Squarespace Website

Ready to showcase your work, publish content or promote your business online? With Squarespace’s award-winning templates and 24/7 customer service, getting started is simple. Head to Squarespace.com and use offer code ‘EXPERTS’ to get 10% off your first purchase.

GusGallowsAuthor Commented:
They all resolve to the same place and the only items in the hosts file are for a test environment with different names (they don't exist in the production environment/DNS).

I think the NIC showing the wrong network name is a red herring as it appears to be a manually adjustable field. It does not appear to be part of the issue since the IP addresses assigned are for the appropriate network/VLAN/DHCP scope. This little tidbit just came in as well. It appears that this has happened before. Always on a Friday and the first symptom is an inability to access internet sites through proxy. My mind is blown. I am hoping come Monday that everything just starts working, but then I need to find out what is causing this and prevent it going forward.

Could a domain controller that is a primary DNS server for the dhcp scope and has it's CPUs maxed to 100% due to a logging tool cause issue like this? It was the first thing we found while troubleshooting. Killed the process and the domain controller normalized, but the problem did not correct.
Sandeep GuptaConsultantCommented:
first I would suggest to check thoroughly your DHCP scope configs and IPs associated.

check your vlan ip ranges as well.

it would be good if you come up with your configurations so we can find the solution more effectively?
What IP addresses does the wrong FQDN resolve to?

Have you tried adding a trailing "." after the FQDN, to avoid suffixing the name?
For instance, instead of pinging host.domain.com do ping "host.domain.com.", with the training .

Of course, if your DNS server fails for a reason or another, the ping command will fail too when using FQDN.
So, we should have an idea of the reason why the ping command did fail (what was the error message?)
GusGallowsAuthor Commented:
Well, guys, it wound up having nothing to do with DHCP. The issue was with our NLS server. It's certificate had expired. This caused Direct Access to act up convincing all servers that were using direct access to think they were all external to the corporate network. Once we renewed the cert, and then updated the cert in IIS using the "netsh http add sslcert ipport= certhash=CERTTHUMBPRINT appid={GUID of IIS AP}". Soon as we did that, everything went back to normal. Thanks for all the advice, but this issue was too vague to diagnose properly. Sorry about that.
GusGallowsAuthor Commented:
Found the resolution as listed in the ticket.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now