3

Short question: how can I ping by short hostname from Windows when DNS is correct?

Protracted exposition:

On Hold

I've been instructed to address other things since this began, so I haven't gotten back to it yet. Thank you to those who've replied so far--and rest assured I didn't abscond with free advice, leaving neither gratitude nor confirmation. I'll return to this ASAP and report back on which solution (will have) worked.


I have a Windows domain (controller: Leo) and a new RHEL7 box (Peanut) serving internal DNS. I need to ping boxes and access Samba shares by short hostname.

Leo and Sam have been here forever, Leo serving DNS. Peanut is brand-new.

192.168.0.2  - Leo - Windows, domain controller, DNS server
192.168.0.3  - Sam - smug DNS resolution test target
192.168.0.29 - Peanut, BIND 9.9.4-RedHat-9.9.4-14.el7 (ESV)

The first obvious solution was add Peanut to Leo's DNS; that works but only resolves FQDN requests--no short names.

C:\bin>nslookup peanut.internal.local 192.168.0.2
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    peanut.internal.local
Address:  192.168.0.29

I've seen many NetBios references, but none which call it a good idea. Nonethless I configured netbios name in smb.conf. I should mention I know nothing about NetBios.

I set up DNS on Peanut thinking Linux would give me more options and flexibility--it did. One guy said DNS can not serve short names--discouraging but I found a way to make it happen. I thought I had this beat when nslookup began resolving short names.

DHCP now serves Peanut as primary DNS and Leo as secondary, which I've verified with ipconfig on Windows and nmcli on Linux. I had premature success syndrome with Linux troubleshooting bias before I removed Sam from my hosts file. Linux uses DNS exactly how I want this to work:

# [09.32.04] ROOT@linnicks [etc] 18   grep peanut /etc/hosts
:( [09.32.08] ROOT@linnicks [etc] 19   ping peanut
PING peanut (192.168.0.29) 56(84) bytes of data.
64 bytes from peanut.internal.local (192.168.0.29): icmp_seq=1 ttl=64 time=0.182 ms
64 bytes from peanut.internal.local (192.168.0.29): icmp_seq=2 ttl=64 time=0.339 ms
^C
--- peanut ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.182/0.260/0.339/0.080 ms
# [09.32.12] ROOT@linnicks [etc] 20

DNS is working, but Windoze clients still ignore it. I can nslookup for either host without specifying server or FQDN.

C:\bin>nslookup sam
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    sam.internal.local
Address:  192.168.0.3


C:\bin>nslookup peanut
Server:  peanut.internal.local
Address:  192.168.0.29

Name:    peanut
Address:  192.168.0.29

I can ping Sam (been here forever with Leo, DC/DNS), but I can't ping Peanut; evidently ping doesn't find names the same way. What's being served that helps Sam and ignores Peanut?

C:\bin>ping sam
Pinging sam [192.168.0.3] with 32 bytes of data:
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128
Reply from 192.168.0.3: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.0.3:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\bin>ping peanut
Ping request could not find host peanut. Please check the name and try again.

I could do an AD logon script to replicate \sys32\drivers\etc\hosts, but that'd still leave me manually updating /etc/hosts on several Mac and Linux boxes. Global services done right require no manual SneakerNet bandaids--yet have no idea what I'm missing.

I'll welcome any ideas on this; the wall is getting sore where I've been hitting it with my forehead.

update: check domain search suffix

Shane Madden and Derfk have got to be on the right track, though I'm not sure I should expect delayed results. I've updated DHCP config with the below but still don't see it on my WinBoxen.

pool 192.168.0.0/24 {
  address-range low 192.168.0.51 high 192.168.0.150;
  name-server {
  192.168.0.29;
  192.168.0.2;
  8.8.8.8;
  8.8.4.4;
  }
  domain-search {
  internal.local;
  }
  wins-server {
  192.168.0.2;
  }

I'd expect this to show in ipconfig's output for primary dns suffix, but it hasn't--and pings still fail. I'll keep digging, but feel welcome to chime in...

zedmelon
  • 63
  • 1
  • 1
  • 7
  • 1
    What does the DNS search suffix configuration look like on the systems? – Shane Madden Oct 03 '14 at 16:35
  • 1
    I'm guessing your DHCP server is not broadcasting the Domain Search List so computers know what domains to try on unqualified hostnames. – DerfK Oct 03 '14 at 16:35
  • @ShaneMadden I'm guessing you mean clients. It's blank. I think DerfK is right...and probably what you're suspecting. – zedmelon Oct 03 '14 at 19:46
  • @DerfK, thanks, I'll check that. Evidently I was thinking backward from the start, but now that DNS can serve short names, I'd still guess that would be unnecessary. – zedmelon Oct 03 '14 at 19:47
  • If only using one DNS suffix use DHCP option: 015 which specifies the connection-specific DNS domain suffix to be used by the DHCP client. – Brian Oct 05 '14 at 21:03

3 Answers3

2

You need to have a configured DNS search suffix for short names to resolve successfully - this can either be done through DHCP options, automatically configured by Windows domain membership, or manually configured on each system (not recommended).

(Side note - please don't use NetBIOS name resolution! It's bad and old!)

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • Hrm. Juniper SRX serves DHCP, and it had no 'domain-search.' I added it but don't see a change on my test box, even after a couple ipconfig /renew, /release, and /flushdns ...the 'primary dns suffix' is still blank. I'll give it a few and check again. – zedmelon Oct 03 '14 at 20:05
1

The DNS Suffix Search List can also be specified in Active Directory Group Policy at:

Computer > Templates > Network > DNS Client > DNS Suffix Search List

That would be particularly useful for computers that don't use DHCP.

If the record is not registered in a zone, or if you have too many zones for the search list to be practical, using the Global Names zone may be an option.

Deploying a GlobalNames Zone
http://technet.microsoft.com/en-us/library/cc731744.aspx

Greg Askew
  • 35,880
  • 5
  • 54
  • 82
0

This is a bit of a guess, but from looking at your DHCP config I surmise you have the WINS server role installed on your DC (wins-server {192.168.0.2;}).

Does 'sam' have a record in WINS, but 'peanut' not? If so, I would guess that your short-name resolution has always been using WINS rather than DHCP.

You can verify this using the NBLookup tool from Microsoft (free download);

http://support2.microsoft.com/default.aspx?scid=kb;en-us;830578

I would strongly encourage moving away from WINS, but hopefully this will solve your short-term problem.

Steve365
  • 1,263
  • 9
  • 16