[SGVLUG] Windows DNS question

Mic Chow zen at netten.net
Wed Jan 29 13:50:15 PST 2014


Ah, this explains a lot!

I am surprised that you just had WINS and DNS issues.  Typically the issue
that happens when SAMBA is enabled on a server, is that it answers before
the Windows Domain controllers answer, so the workstations attempts to
validate and get its login information from the Linux server, instead of
the domain controllers.  Since the SAMBA server is not in the actual role
of domain controller, it is not handing out any of that information.  The
workstations then get bloody confused.  Part of this is part of the
"election system" that Windows uses to determine which server is the
"Master Browser" at the time.

I missed out on the presentation at my old LUG in Memphis about mixing an
environment with both Windows domain controller and SAMBA ones.

Mic



On Wed, Jan 29, 2014 at 12:56 AM, Matthew Campbell <dvdmatt at gmail.com>wrote:

> So problem solved.
>
> What changed on my network is I split my DHCP server and fileserver onto
> two separate VMs.  When I booted up the new Linux based fileserver Samba
> took over WINS service for the network and was distributing information
> conflicting with the DNS server.
>
> To fix this I turned off Samba WINS (which is on by default) on the new
> fileserver and installed samba with no shares on the DNS server and made it
> the network master.
> 152c152
> < ;     security = user
> ---
> >       security = user
> 155c155
> < ;     domain master = yes
> ---
> >       domain master = yes
> 185,186c185,186
> < ;     os level = 33
> < ;     preferred master = yes
> ---
> >       os level = 99
> >       preferred master = yes
> 203c203
> < ;     wins support = yes
> ---
> >       wins support = yes
> 207c207
> < ;     dns proxy = yes
> ---
> >       dns proxy = yes
>
> Adding the DNS server as the WINS host in the /etc/dhcp/dhcpd.conf file
> completed the config.
> option netbios-name-servers senge;                      # WINS server
>
> Everything has been stable for 2 hours.  I'm not convinced I'm done but
> finding the problem was a relief.
>
> It was certainly not obvious from the error messages where the problem was
> coming from and the Microsoft documentation was, um, absent.  Almost like
> they want you to pay to be able to run the OS you purchased from them...
>
> I hope this all helps someone else.  Thanks for the bandwidth.
>
> Matt
>
>
> ---------
> *Matthew Campbell*
> Storage Solution Consultant
> Storage Design and Engineering
>
> *Kaiser Permanente*
> IMG-Systems Integration
> 99 S. Oakland
> Pasadena, CA 91101
>
> 626-564-7228 (office)
> 8-338-7228 (tie-line)
> 818-314-9897 (mobile phone)
> Green Center 3-North, 031W29
> ---------
> *kp.org/thrive <http://kp.org/thrive>*
>
>
> On Mon, Jan 27, 2014 at 2:49 PM, Michael Proctor-Smith <
> mproctor13 at gmail.com> wrote:
>
>> Did you change the ip addresses of the hosts that you are having issues
>> correctly looking up?
>>
>> I have in the past had this issue with MACs as they would ask there peers
>> the address of the host before asking the DNS server. Which lead to the
>> nslookup being correct but anything that used system gethostaddress like
>> ping, ssh, browsers not being correct.
>>
>> It is not only netbios issue, I suspect the reason disabling ipv6 fixed
>> it is because ipv6 has dynamic host discovery feature that I can't remember
>> the name of that does the same thing that the MACs were doing and generally
>> asked the local network before asking dns.
>>
>>
>> On Mon, Jan 27, 2014 at 1:30 PM, Mic Chow <zen at netten.net> wrote:
>>
>>> Personal experience.  We had network issues here with things not routing
>>> or resolving correctly.  We disabled IPV6 and all the issues went away.
>>> Not to say that is THE solution, it is more like a decent piece of
>>> duct-tape while finding a better solution.  Since my company has not made
>>> the move to IPV6 and the rule is to disable IPV6 here.  However, not
>>> everybody deploying devices attached to the network follow the rules.  What
>>> we think is happening is that there is something here that is responding
>>> and replying to a lookup request on the IPV6 side and tossing that data
>>> back over the IPV4 stuff.  It makes no logical sense, but it seems to be
>>> really prevalent on the Microsoft implementation of a network stack.
>>>
>>> I asked about the implementation of DNS, because we do have issues with
>>> our Microsoft internal DNS server not being timely with its names table and
>>> we get legacy names where the devices have long since either disconnected
>>> or have a different IP.  this is usually with DDNS (Windows Dynamic DNS)
>>> and WINS.  Sadly my group is not allowed to actually manage or modify the
>>> internal DNS servers.
>>>
>>> -Mic
>>>
>>>
>>>
>>> On Mon, Jan 27, 2014 at 12:05 PM, Matthew Campbell <dvdmatt at gmail.com>wrote:
>>>
>>>> Good morning, still at it (day 3).  I'm logging some of the work I'm
>>>> doing so when you run across this you can refer back here for the process
>>>> as it looks like there are a lot of parallel problems with DHCP/DNS that
>>>> yield the same results.
>>>>
>>>> With IPV6 disabled on the network interface I am still seeing the same
>>>> problem.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *matt at Nala:220% nslookup leonaServer:
>>>> senge.campbell.littlelionstudios.com
>>>> <http://senge.campbell.littlelionstudios.com> Address:  172.28.1.2Name:
>>>> leona.campbell.littlelionstudios.com
>>>> <http://leona.campbell.littlelionstudios.com>Address:
>>>> 172.28.3.151matt at Nala:221% ping leonaPing request could not find host
>>>> leona. Please check the name and try again. matt at Nala:222% *
>>>> Option:  Could it be a problem on my DNS server?
>>>>
>>>> http://stackoverflow.com/questions/330395/dns-problem-nslookup-works-ping-doesnt
>>>> Lots of possible answers here.  I had already added the patch for the
>>>> answer that looks the best (Windows adds .local to any hostname without a
>>>> dot in it WTF?) by adding '.' to the domain resolution order on the Windows
>>>> box so this is not it.
>>>>
>>>> Option: "On Windows 2000 and later, if a request to your primary DNS
>>>> server times out, it switches to the secondary DNS server and stays with it
>>>> for a period of time. However, nslookup always connects to the primary."
>>>> As the problem is intermittent and resolves after a period of time
>>>> maybe some of the boxes booted while the DNS server was offline and have
>>>> incorrect name servers?  This case is not upheld by the continuing
>>>> intermittent failures.
>>>>
>>>> Option:  Could the computer be accessing another DNS server?  I traced
>>>> packets on my DNS server and it is not receiving the request from the host
>>>> so something else is resolving the name. Supporting this option is the
>>>> previous example where nslookup is returning the correct IP address and ssh
>>>> / ping are getting a different answer.  Flushing the dns cache on the host
>>>> does not solve the problem so the incorrect answer is coming from somewhere
>>>> external:
>>>>
>>>> No mention of aslan in the local cache:
>>>>
>>>> *ipconfig /displaydns *
>>>>
>>>> Just to be safe dump the cache:
>>>>
>>>> *ipconfig /flushdns *
>>>>
>>>> Still no joy, 2 different IP addresses are being returned.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *matt at Nala:214% ssh aslan<snip>The RSA host key for aslan has changed,
>>>> and the key for the corresponding IP address 172.28.2.111is
>>>> unknown.<snip>matt at Nala:215% nslookup aslanServer:
>>>> senge.campbell.littlelionstudios.com
>>>> <http://senge.campbell.littlelionstudios.com> Address:  172.28.1.2Name:
>>>> aslan.campbell.littlelionstudios.com
>>>> <http://aslan.campbell.littlelionstudios.com>Address:
>>>> 172.28.2.100matt at Nala:216% *
>>>> Option: there could be another DNS server on the network
>>>> The host is set with the correct DNS lookup order.  The primary DNS
>>>> server returns the correct hostname.  The secondary and tertiary DNS
>>>> servers return 'host not found' so they are not providing the incorrect DNS
>>>> entry.
>>>>
>>>> Option: there could be another service other than DNS providing the
>>>> hostname lookup
>>>> This is supported by operations.  nslookup can resolve nashost2, but
>>>> Windows Explorer, ping and ssh can't find the server.
>>>>
>>>> Yahoo!!! Found a clue in the /var/log/named.log file:  It looks like
>>>> when I coppied the dnssec keys over from my old server I didn't get the
>>>> configuration quite right.  But what's with the double dipping in the
>>>> domain pool in that last line?
>>>>
>>>>
>>>>
>>>> *Jan 27 04:39:34 senge named[2244]: 27-Jan-2014 04:39:34.217 dnssec:
>>>> info:   validating @0x7f3d904dd090: littlelionstudios.com
>>>> <http://littlelionstudios.com> SOA: bad cache hit
>>>> (littlelionstudios.com.dlv.isc.org/DLV
>>>> <http://littlelionstudios.com.dlv.isc.org/DLV>) Jan 27 04:39:34 senge
>>>> named[2244]: 27-Jan-2014 04:39:34.217 lame-servers: info: error (broken
>>>> trust chain) resolving
>>>> 'nashost2.campbell.littlelionstudios.com.littlelionstudios.com/A/IN
>>>> <http://nashost2.campbell.littlelionstudios.com.littlelionstudios.com/A/IN>':
>>>> 208.109.255.44#53 *
>>>> Yahoo!!! Found another clue:
>>>> It turns out that Windows silently ignores applications it can run if
>>>> your launcher is not of the right type.  I was running inside a 32 bit
>>>> shell and the NetBIOS tool is only a 64 bit app on Windows 8.  Opening a
>>>> command shell let me find the problem:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *C:\Users\matt>nbtstat -A 172.28.2.111Ethernet:Node IpAddress:
>>>> [172.28.2.122] Scope Id: []           NetBIOS Remote Machine Name
>>>> Table       Name               Type         Status
>>>> ---------------------------------------------    ASLAN          <00>
>>>> UNIQUE      Registered    ASLAN          <03>  UNIQUE      Registered
>>>> ASLAN          <20>  UNIQUE      Registered     CAMPBELL       <00>
>>>> GROUP       Registered    CAMPBELL       <1E>  GROUP       Registered
>>>> MAC Address = 00-00-00-00-00-00*
>>>> Note that Aslan is mapped to IP address ...111 in NetBIOS.  This is
>>>> most likely the cause of the problems I have been seeing.
>>>>
>>>> Now to install a NetBIOS server on the Linux host and link it to DNS;
>>>> this should solve the problems.  I'll post again in a couple of hours.
>>>>
>>>> Matt
>>>>
>>>>
>>>> ---------
>>>> *Matthew Campbell*
>>>> Storage Solution Consultant
>>>> Storage Design and Engineering
>>>>
>>>> *Kaiser Permanente*
>>>> IMG-Systems Integration
>>>> 99 S. Oakland
>>>> Pasadena, CA 91101
>>>>
>>>> 626-564-7228 (office)
>>>> 8-338-7228 (tie-line)
>>>> 818-314-9897 (mobile phone)
>>>> Green Center 3-North, 031W29
>>>> ---------
>>>> *kp.org/thrive <http://kp.org/thrive>*
>>>>
>>>>
>>>> On Mon, Jan 27, 2014 at 8:39 AM, Matthew Campbell <dvdmatt at gmail.com>wrote:
>>>>
>>>>> Good suggestion Claude,
>>>>>
>>>>> Unfortunately turning it back on made no difference.  The issue is
>>>>> 'intermittent' which in this case means it's happening on every host until
>>>>> I fiddle with it then mysteriously gets better.  It sometimes gets beter on
>>>>> its own in 20 minutes or so even without fiddling.  It may have been
>>>>> coincidence that it started working in the same time span I was disabling
>>>>> IPV6.
>>>>>
>>>>> To disable IPV6 you have to edit the registry.  What I did was "Unbind
>>>>> IPv6 from a specific network adapter".  Mic, was this a valid test?
>>>>> http://support.microsoft.com/kb/929852
>>>>>
>>>>> Matt
>>>>>
>>>>>
>>>>> ---------
>>>>> *Matthew Campbell*
>>>>> Storage Solution Consultant
>>>>> Storage Design and Engineering
>>>>>
>>>>> *Kaiser Permanente*
>>>>> IMG-Systems Integration
>>>>> 99 S. Oakland
>>>>> Pasadena, CA 91101
>>>>>
>>>>> 626-564-7228 (office)
>>>>> 8-338-7228 (tie-line)
>>>>> 818-314-9897 (mobile phone)
>>>>> Green Center 3-North, 031W29
>>>>> ---------
>>>>> *kp.org/thrive <http://kp.org/thrive>*
>>>>>
>>>>>
>>>>> On Mon, Jan 27, 2014 at 1:48 AM, Claude Felizardo <
>>>>> cafelizardo at gmail.com> wrote:
>>>>>
>>>>>> Matthew, just to be sure, have you tried turning IPv6 back on to
>>>>>> confirm that the problem comes back?  Anything else change?  Reboot?
>>>>>>
>>>>>> I generally turn off IPv6 for now as I know some of my older equipment
>>>>>> and applications do not support it.
>>>>>>
>>>>>> I just checked my router, I have IPv6 enabled but looks like I only
>>>>>> have a four octet IP from my ISP so unless someone can give me a good
>>>>>> reason to try IPv6 I'll probably just leave things as is and let
>>>>>> others debug problems.
>>>>>>
>>>>>> Claude
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 27, 2014 at 1:32 AM, Matthew Campbell <dvdmatt at gmail.com>
>>>>>> wrote:
>>>>>> > The DNS server is bind on RHEL 6.4 with CENTOS 6.5 updates.
>>>>>> >
>>>>>> > Turning off IPV6 suddenly made the bad times go away.
>>>>>> >
>>>>>> > I have been fighting a ghost all weekend and thought I had things
>>>>>> fixed a
>>>>>> > number of times but they came back a couple of hours later.  I'll
>>>>>> take this
>>>>>> > as a good sign but won't start celebrating yet.
>>>>>> >
>>>>>> > Why did that work and what was going on?  How did you know this was
>>>>>> the
>>>>>> > problem?
>>>>>> >
>>>>>> > Was it intuition, prior experience or omniscience?
>>>>>> >
>>>>>> > Matt
>>>>>> >
>>>>>> >
>>>>>> > ---------
>>>>>> > Matthew Campbell
>>>>>> > Storage Solution Consultant
>>>>>> > Storage Design and Engineering
>>>>>> >
>>>>>> > Kaiser Permanente
>>>>>> > IMG-Systems Integration
>>>>>> > 99 S. Oakland
>>>>>> > Pasadena, CA 91101
>>>>>> >
>>>>>> > 626-564-7228 (office)
>>>>>> > 8-338-7228 (tie-line)
>>>>>> > 818-314-9897 (mobile phone)
>>>>>> > Green Center 3-North, 031W29
>>>>>> > ---------
>>>>>> > kp.org/thrive
>>>>>> >
>>>>>> >
>>>>>> > On Sun, Jan 26, 2014 at 11:34 PM, Mic Chow <zen at netten.net> wrote:
>>>>>> >>
>>>>>> >> Is your network running IPV6; if not then disable it in the
>>>>>> Windows box.
>>>>>> >> What flavor is the DNS server; Microsoft?
>>>>>> >>
>>>>>> >> Mic
>>>>>> >>
>>>>>> >>
>>>>>> >> On 01/26/2014 10:50 PM, Matthew Campbell wrote:
>>>>>> >>
>>>>>> >> Ok, I'm more than a little frustrated.
>>>>>> >>
>>>>>> >> I installed a new DHCP/DNS server Friday.  I washed all my Windows
>>>>>> and
>>>>>> >> can't do a thing with them:
>>>>>> >>
>>>>>> >> matt at Nala:201% ipconfig /flushdns
>>>>>> >> Windows IP Configuration
>>>>>> >> Successfully flushed the DNS Resolver Cache.
>>>>>> >>
>>>>>> >> matt at Nala:202% nslookup aslan
>>>>>> >> Server:  senge.campbell.littlelionstudios.com
>>>>>> >> Address:  172.28.1.2
>>>>>> >> Name:    aslan.campbell.littlelionstudios.com
>>>>>> >> Address:  172.28.2.100
>>>>>> >>
>>>>>> >> matt at Nala:203% ping aslan
>>>>>> >> Pinging aslan [172.28.2.111] with 32 bytes of data:
>>>>>> >> Reply from 172.28.2.111: bytes=32 time<1ms TTL=64
>>>>>> >> Reply from 172.28.2.111: bytes=32 time<1ms TTL=64
>>>>>> >>
>>>>>> >> matt at Nala:204%
>>>>>> >>
>>>>>> >>
>>>>>> >> WTF?!?  The IP address changed in the cache between the two calls
>>>>>> or what?
>>>>>> >> Of course things are not working.  Any suggestions on how to
>>>>>> diagnose?
>>>>>> >>
>>>>>> >>
>>>>>> >> Matt
>>>>>> >>
>>>>>> >> P.S.  Here's another example:
>>>>>> >>
>>>>>> >> matt at Nala:204% nslookup kiara
>>>>>> >> Server:  senge.campbell.littlelionstudios.com
>>>>>> >> Address:  172.28.1.2
>>>>>> >>
>>>>>> >> Name:    kiara.campbell.littlelionstudios.com
>>>>>> >> Address:  172.28.2.102
>>>>>> >>
>>>>>> >> matt at Nala:205% ssh kiara
>>>>>> >> ssh: Could not resolve hostname kiara: hostname nor servname
>>>>>> provided, or
>>>>>> >> not known
>>>>>> >>
>>>>>> >> matt at Nala:206%
>>>>>> >>
>>>>>> >>
>>>>>> >> And here's the ipconfig:
>>>>>> >>
>>>>>> >> matt at Nala:206% ipconfig /all
>>>>>> >> Windows IP Configuration
>>>>>> >>    Host Name . . . . . . . . . . . . : Nala
>>>>>> >>    Primary Dns Suffix  . . . . . . . :
>>>>>> >>    Node Type . . . . . . . . . . . . : Hybrid
>>>>>> >>    IP Routing Enabled. . . . . . . . : No
>>>>>> >>    WINS Proxy Enabled. . . . . . . . : No
>>>>>> >>    DNS Suffix Search List. . . . . . :
>>>>>> campbell.littlelionstudios.com
>>>>>> >> littlelionstudios.com
>>>>>> >>
>>>>>> >> Ethernet adapter Ethernet:
>>>>>> >>    Connection-specific DNS Suffix  . :
>>>>>> campbell.littlelionstudios.com
>>>>>> >>    Description . . . . . . . . . . . : Broadcom NetLink (TM)
>>>>>> Gigabit
>>>>>> >> Ethernet
>>>>>> >>    Physical Address. . . . . . . . . : BC-5F-F4-4B-96-76
>>>>>> >>    DHCP Enabled. . . . . . . . . . . : Yes
>>>>>> >>    Autoconfiguration Enabled . . . . : Yes
>>>>>> >>    Link-local IPv6 Address . . . . . :
>>>>>> >> fe80::6c04:e86b:ac8e:4d78%12(Preferred)
>>>>>> >>    IPv4 Address. . . . . . . . . . . : 172.28.2.122(Preferred)
>>>>>> >>    Subnet Mask . . . . . . . . . . . : 255.255.0.0
>>>>>> >>    Lease Obtained. . . . . . . . . . : Sunday, January 26, 2014
>>>>>> 10:43:04
>>>>>> >> PM
>>>>>> >>    Lease Expires . . . . . . . . . . : Monday, January 27, 2014
>>>>>> 10:43:03
>>>>>> >> PM
>>>>>> >>    Default Gateway . . . . . . . . . : 172.28.0.1
>>>>>> >>    DHCP Server . . . . . . . . . . . : 172.28.1.2
>>>>>> >>    DHCPv6 IAID . . . . . . . . . . . : 264003572
>>>>>> >>    DHCPv6 Client DUID. . . . . . . . :
>>>>>> >> 00-01-00-01-18-96-BE-84-BC-5F-F4-4B-96-76
>>>>>> >>    DNS Servers . . . . . . . . . . . : 172.28.1.2
>>>>>> >>                                        172.25.0.1
>>>>>> >>                                        8.8.8.8
>>>>>> >>    Primary WINS Server . . . . . . . : 172.28.1.2
>>>>>> >>    NetBIOS over Tcpip. . . . . . . . : Enabled
>>>>>> >>
>>>>>> >> Tunnel adapter isatap.campbell.littlelionstudios.com:
>>>>>> >>    Media State . . . . . . . . . . . : Media disconnected
>>>>>> >>    Connection-specific DNS Suffix  . :
>>>>>> campbell.littlelionstudios.com
>>>>>> >>    Description . . . . . . . . . . . : Microsoft ISATAP Adapter
>>>>>> >>    Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
>>>>>> >>    DHCP Enabled. . . . . . . . . . . : No
>>>>>> >>    Autoconfiguration Enabled . . . . : Yes
>>>>>> >>
>>>>>> >> Tunnel adapter Local Area Connection* 11:
>>>>>> >>    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:9d38:6ab8:cb6:220c:53e3:fd85(Preferred)
>>>>>> >>    Link-local IPv6 Address . . . . . :
>>>>>> >> fe80::cb6:220c:53e3:fd85%14(Preferred)
>>>>>> >>    Default Gateway . . . . . . . . . : ::
>>>>>> >>    NetBIOS over Tcpip. . . . . . . . : Disabled
>>>>>> >>
>>>>>> >> matt at Nala:205%
>>>>>> >>
>>>>>> >> Thanks for any ideas on how to tackle this.  The Linux upgrade
>>>>>> including
>>>>>> >> rebuilding 2 rack-mount servers from parts, OS installs, VM
>>>>>> installs, App
>>>>>> >> installs and configuration took 4 hours.  I lost all day Saturday
>>>>>> and all
>>>>>> >> day Sunday to this d*** windows quirk.
>>>>>> >>
>>>>>> >> Matt
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sgvlug.net/pipermail/sgvlug/attachments/20140129/85665634/attachment-0001.html>


More information about the SGVLUG mailing list