Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
07-09-2013, 03:04 PM
|
#1
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Rep:
|
3rd try.... windows 7 clients randomly failing to resolve address of nameserver
i've posted about this twice and got zero responses, so.. third times the charm right?
I have a BIND server setup for my home network. It's named "pLAN9-Server1", address 172.16.16.2, local domain name of "pLAN9.site". This machine is also a dhcpd server. After what seems like a random amount of time, and with no apparent cause, Windows 7 clients stop being able to resolve the address of the nameserver itself. Any other address gets resolved fine, it's just the nameserver itself. Even weirder, doing an "nslookup" from a Win7 box that's having the problem always returns the proper result??? But pinging the server by name or trying to access it via Windows explorer fails.... that doesn't make ANY sense to me... if nslookup resolves the name, why is every other means of accessing the server failing? Of course, the Windows boxes don't log anything remotely helpful. Doing an "ipconfig /renew" on the windows machines always fixes the problem temporarily, but it eventually comes back, once again with no comprehensible reason. It seems like it's a DNS-only problem, as accessing the server by IP always works.
Here's output on the windows command line from a machine that currently has no access (nslookup -d2):
Code:
> plan9-server1
Server: pLAN9-Server1.pLAN9.site
Address: 172.16.16.2
------------
SendRequest(), len 42
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
plan9-server1.pLAN9.site, type = A, class = IN
------------
------------
Got answer (72 bytes):
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 1, additional = 0
QUESTIONS:
plan9-server1.pLAN9.site, type = A, class = IN
ANSWERS:
-> plan9-server1.pLAN9.site
type = A, class = IN, dlen = 4
internet address = 172.16.16.2
ttl = 259200 (3 days)
AUTHORITY RECORDS:
-> pLAN9.site
type = NS, class = IN, dlen = 2
nameserver = plan9-server1.pLAN9.site
ttl = 259200 (3 days)
------------
------------
SendRequest(), len 42
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: query, want recursion
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
plan9-server1.pLAN9.site, type = AAAA, class = IN
------------
------------
Got answer (92 bytes):
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
plan9-server1.pLAN9.site, type = AAAA, class = IN
AUTHORITY RECORDS:
-> pLAN9.site
type = SOA, class = IN, dlen = 38
ttl = 86400 (1 day)
primary name server = plan9-server1.pLAN9.site
responsible mail addr = admin.plan9.co
serial = 2013062701
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 2419200 (28 days)
default TTL = 86400 (1 day)
------------
Name: plan9-server1.pLAN9.site
Address: 172.16.16.2
> exit
C:\Users\Wil>ping plan9-server1
Ping request could not find host plan9-server1. Please check the name and try again.
C:\Users\Wil>ping plan9-server1.plan9.site
Ping request could not find host plan9-server1.plan9.site. Please check the name and try again.
Why the frick can't Windows ping it by name, even when I try the FQDN?
server config files
/etc/named.conf:
Code:
//
// /etc/named.conf
//
options {
directory "/var/named";
pid-file "/var/run/named/named.pid";
auth-nxdomain yes;
datasize default;
// Uncomment these to enable IPv6 connections support
// IPv4 will still work:
// listen-on-v6 { any; };
// Add this for no IPv4:
// listen-on { none; };
// Default security settings.
allow-recursion { localnets; };
allow-transfer { localhost; };
allow-update { localhost; };
allow-query { localnets; };
forwarders { 208.67.222.222; 208.67.222.222; };
listen-on { 127.0.0.1; 172.16.16.2; };
max-cache-ttl 1209600;
# edns-udp-size 512;
edns-udp-size 4096 ;
version none;
hostname none;
server-id none;
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-transfer { localhost; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
allow-transfer { localhost; };
};
zone "." IN {
type hint;
file "root.hint";
};
zone "pLAN9.site" IN {
type master;
notify no;
file "pLAN9.zone";
};
zone "16.16.172.in-addr.arpa" IN {
type master;
notify no;
file "pLAN9.rev";
};
logging {
channel xfer-log {
file "/var/log/named.log";
print-category yes;
print-severity yes;
print-time yes;
severity debug 10;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};
/etc/dhcpd.conf:
Code:
option domain-name "pLAN9.site";
option domain-name-servers 172.16.16.2,208.67.222.222;
option routers 172.16.16.1;
option wpad code 252 = text;
option wpad "\n\000";
default-lease-time 604800;
min-lease-time 604800;
max-lease-time 604800;
authoritative;
log-facility local7;
subnet 172.16.0.0 netmask 255.255.0.0 {
range 172.16.16.50 172.16.16.249;
}
zone files
/var/named/pLAN9.zone (forward)
Code:
$TTL 3D
@ IN SOA pLAN9-Server1.pLAN9.site. admin.plan9.co. (
2013062701
8H
2H
4W
1D )
NS pLAN9-Server1
localhost A 127.0.0.1
pLAN9-Server1 A 172.16.16.2
pLAN9-Gateway A 172.16.16.1
pLAN9-Server2 A 172.16.16.3
pLAN9-Wil A 172.16.16.10
pLAN9-HTPC A 172.16.16.11
pLAN9-Laptop A 172.16.16.12
Galt-PC A 172.16.16.15
Switch A 172.16.16.19
pLAN9-WAP A 172.16.16.254
/var/named/pLAN9.rev (reverse)
Code:
$TTL 3D
@ IN SOA pLAN9-Server1.pLAN9.site. admin.plan9.co. (
2013062701
8H
2H
4W
1D )
NS pLAN9-Server1.pLAN9.site.
1 PTR pLAN9-Gateway.pLAN9.site.
2 PTR pLAN9-Server1.pLAN9.site.
3 PTR pLAN9-Server2.pLAN9.site.
10 PTR pLAN9-Wil.pLAN9.site.
11 PTR pLAN9-HTPC.pLAN9.site.
12 PTR pLAN9-Laptop.pLAN9.site.
15 PTR Galt-PC.pLAN9.site.
19 PTR Switch.pLAN9.site.
254 PTR pLAN9-WAP.pLAN9.site.
|
|
|
07-09-2013, 03:23 PM
|
#2
|
Senior Member
Registered: Dec 2005
Location: Florida
Distribution: CentOS/Fedora/Pop!_OS
Posts: 2,983
|
what does your hosts file in win7 look like?
Microsoft is stupid when it comes to LAN side DNS resolution unless it is part of an AD network in full native mode.
|
|
|
07-09-2013, 03:25 PM
|
#3
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
Code:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
i haven't touched any of themm. (btw, gotta love windows keeping the hosts file in "drivers(?)/etc/")
|
|
|
07-09-2013, 04:13 PM
|
#4
|
Moderator
Registered: Mar 2008
Posts: 22,150
|
Do these clients use a wpad file to authenticate or proxy with?
|
|
|
07-09-2013, 04:16 PM
|
#5
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
Actually no, if youre referring to the "option wpad" thing in dhcpd.conf. I put that there because all of the Win7 clients were semi-flooding the dhcp server with a bunch of spurious "DHCPINFORM" messages, and adding those lines stopped that.
Could that be part of the problem?
|
|
|
07-09-2013, 04:56 PM
|
#6
|
Member
Registered: Apr 2005
Location: Fargo, ND
Distribution: Slackware, CentOS
Posts: 87
Rep:
|
What response are you getting from an nslookup and what does you NS log when your windows clients request?
|
|
|
07-09-2013, 04:58 PM
|
#7
|
Member
Registered: Apr 2005
Location: Fargo, ND
Distribution: Slackware, CentOS
Posts: 87
Rep:
|
Are you DNS servers being set up on the windows clients? what is the output from ipconfig /all on one of the windows clients?
|
|
|
07-09-2013, 05:04 PM
|
#8
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
Quote:
Originally Posted by ArcLinux
What response are you getting from an nslookup and what does you NS log when your windows clients request?
|
i already posted an nslookup output at the beginning of my original post. nslookup resolves the name fine, ping/explorer does not.
and ipconfig /all
Code:
Windows IP Configuration
Host Name . . . . . . . . . . . . : pLAN9-Laptop
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : pLAN9.site
Ethernet adapter OPENVPN:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TAP-Windows Adapter V9
Physical Address. . . . . . . . . : 00-FF-B1-5E-CF-44
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Ethernet adapter LAN:
Connection-specific DNS Suffix . : pLAN9.site
Description . . . . . . . . . . . : JMicron PCI Express Gigabit Ethernet Adapter
Physical Address. . . . . . . . . : 00-90-F5-BB-6A-34
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 172.16.16.12(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Lease Obtained. . . . . . . . . . : Tuesday, July 09, 2013 3:58:15 PM
Lease Expires . . . . . . . . . . : Tuesday, July 16, 2013 3:58:15 PM
Default Gateway . . . . . . . . . : 172.16.16.1
DHCP Server . . . . . . . . . . . : 172.16.16.2
DNS Servers . . . . . . . . . . . : 172.16.16.2
208.67.222.222
NetBIOS over Tcpip. . . . . . . . : Disabled
Tunnel adapter isatap.pLAN9.site:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . : pLAN9.site
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Tunnel adapter Teredo Tunneling Pseudo-Interface:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:0:5ef5:79fb:30f7:31f:b9a5:8de(Preferred)
Link-local IPv6 Address . . . . . : fe80::30f7:31f:b9a5:8de%12(Preferred)
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled
Tunnel adapter isatap.{B15ECF44-5D7D-45D4-A9A5-A092ACBA9E61}:
Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
|
|
|
07-09-2013, 11:32 PM
|
#9
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
just adding that when the systems lose access, running a rndc querylog on the DNS server produces absolutely no results when the clients try to ping/access by name. Nothing at all. So it seems like the Windows clients aren't even trying to send a DNS query.... but only for the nameserver's query... this makes no sense.
|
|
|
07-11-2013, 11:04 PM
|
#10
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
an update on this
i have since removed the second DNS server from dhcpd.conf, the opendns address that I had had as the secondary dns. it's been almost 3 days without a problem. if it doesn't happen for a few more days ill mark this solved.
|
|
|
07-11-2013, 11:23 PM
|
#11
|
Senior Member
Registered: Jan 2012
Distribution: Slackware
Posts: 3,348
Rep:
|
Quote:
Originally Posted by psycroptic
an update on this
i have since removed the second DNS server from dhcpd.conf, the opendns address that I had had as the secondary dns. it's been almost 3 days without a problem. if it doesn't happen for a few more days ill mark this solved.
|
You've found the culprit.
The reason is the way Windows handles multiple DNS entries. It works like this: - The primary entry is always used. None of the other entries are ever tried as long as the primary DNS server responds, even if the response is NXDOMAIN.
- Should the primary server fail to respond within the timeout period (2 sec), Windows switches to the next server in the list. Permanently. It does not ever switch back unless the secondary server fails to respond.
- If the secondary server fails to respond, Windows switches to the tertiary server (or back to the primary server if no tertiary server exists)
Perhaps the server running BIND gets overloaded at times, or the DNS packets are dropped because of temporary bandwidth issues in your LAN. Or there could be noise disrupting your wireless network, if that's what the Windows PC is using.
Such events would trigger a switch of DNS server on the Windows client, and from then on it would be using the OpenDNS server exclusively. Of course, the OpenDNS server knows nothing of the contents of your internal DNS zone, and will return NXDOMAIN for any queries related to the "pLAN9.site" domain.
The only way to make Windows switch back to the primary server is to deactivate and reactivate the network connection, reset the IP configuration (as you've discovered), or reboot the OS. Oh, and sometimes Windows may decide that the primary DNS server is not the one you've put first in your DHCP zone. In other words, never mix internal and external DNS servers.
|
|
|
07-11-2013, 11:30 PM
|
#12
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
actually, it isn't dropped queries or packets or anything; i typically reboot this and all of my servers fairly frequently as i update them nearly constantly. during the reboot, if any client tried to query DNS for any reason, it would fail, and from then on would never try my internal server again.
am i the only one who doesn't think this is fairly illogical behavior on the part of Windows? i would think that, at least like every 50 queries or so it would try the first one again to see if it's back up? since after all, Windows itself calls the first DNS server "primary"...
in any case, i guess it wasn't exactly a "Linux" question, but thanks for all the help folks.
|
|
|
07-12-2013, 05:00 AM
|
#13
|
Member
Registered: Oct 2012
Location: Tucson, AZ
Distribution: Debian/CentOS
Posts: 124
Rep:
|
I could be wrong, but I believe your problem there was the fact that Linux isn't syntax picky... it's syntax fucking crazy!
Correct me if I'm wrong but here is the difference between my home setup (running CentOS6 w/ bind) and your setup (what're you running?):
Mine:
option domain-name-servers 192.168.1.5, 192.168.1.1, 75.75.75.75, 76.76.76.76, 8.8.8.8, 8.8.4.4;
Yours:
option domain-name-servers 172.16.16.2,208.67.222.222;
Could it be as simple as not having a space that separates them? It caused a problem for me when I first configured bind! Anyways I hope it helps.
Here's iPhone & Windows7 Pro devices getting the correct information (in the correct order) in the attachments...
|
|
|
07-12-2013, 10:40 PM
|
#14
|
Member
Registered: Aug 2011
Location: USA
Distribution: ArchLinux - 3.0 kernel
Posts: 349
Original Poster
Rep:
|
hmm, i'll try that and see if the problem comes back.
marking as solved, thanks for the info all
|
|
|
07-13-2013, 02:00 AM
|
#15
|
Member
Registered: Oct 2012
Location: Tucson, AZ
Distribution: Debian/CentOS
Posts: 124
Rep:
|
So, did it solve anything?
|
|
|
All times are GMT -5. The time now is 10:48 PM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|