RE: Strange DIG behavior on Windows 10: - SOLVED (sorta)
One machine had resolv.conf in ISC BIND 9\etc, the other didn't. So I suspect that in spite of the release notes about resolv.conf not being needed... it really is. Perhaps it isn't if you install the full BIND service but is needed if you only install the tools. -Original Message- From: bind-users On Behalf Of Timothy Metzinger Sent: Tuesday, October 23, 2018 8:13 PM To: bind-users@lists.isc.org Subject: RE: Strange DIG behavior on Windows 10: I see NO outgoing bits on the wire, bolstering my theory that DIG isn't finding name servers in the registry. NSLOOKUP works fine. There's no difference between the working and non working PC in the name servers listed in all the interfaces in ifconfig /all. Registry values for HKLM\system\currentcontrolset\services\tcpip\parameters\dhcpnameserver are identical. I've deinstalled and reinstalled BIND. This is so weird. -Original Message- From: bind-users On Behalf Of Grant Taylor via bind-users Sent: Tuesday, October 23, 2018 6:55 PM To: bind-users@lists.isc.org Subject: Re: Strange DIG behavior on Windows 10: On 10/23/2018 04:21 PM, Timothy Metzinger wrote: > At this point I'm stumped and welcome any suggestions. Trust the bits on the wire. What sort of outgoing DNS queries do you see when you run dig on the problematic system without specifying the DNS server? Can you find that server listed anywhere in the output of ifconfig /all? (I think that's the command, it's been too long.) -- Grant. . . . unix || die ___ Please visit https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C96b65a2a3a894aa4c70c08d639458cfd%7C84df9e7fe9f640afb435%7C1%7C0%7C636759368205811310sdata=Ub1YqLysdo6XTh%2FKN3npPF3rTSNL0JZmaqrRv5vrUQs%3Dreserved=0 to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C96b65a2a3a894aa4c70c08d639458cfd%7C84df9e7fe9f640afb435%7C1%7C0%7C636759368205811310sdata=Ub1YqLysdo6XTh%2FKN3npPF3rTSNL0JZmaqrRv5vrUQs%3Dreserved=0 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Strange DIG behavior on Windows 10:
I see NO outgoing bits on the wire, bolstering my theory that DIG isn't finding name servers in the registry. NSLOOKUP works fine. There's no difference between the working and non working PC in the name servers listed in all the interfaces in ifconfig /all. Registry values for HKLM\system\currentcontrolset\services\tcpip\parameters\dhcpnameserver are identical. I've deinstalled and reinstalled BIND. This is so weird. -Original Message- From: bind-users On Behalf Of Grant Taylor via bind-users Sent: Tuesday, October 23, 2018 6:55 PM To: bind-users@lists.isc.org Subject: Re: Strange DIG behavior on Windows 10: On 10/23/2018 04:21 PM, Timothy Metzinger wrote: > At this point I'm stumped and welcome any suggestions. Trust the bits on the wire. What sort of outgoing DNS queries do you see when you run dig on the problematic system without specifying the DNS server? Can you find that server listed anywhere in the output of ifconfig /all? (I think that's the command, it's been too long.) -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DIG behavior on Windows 10:
On 10/23/2018 04:21 PM, Timothy Metzinger wrote: At this point I’m stumped and welcome any suggestions. Trust the bits on the wire. What sort of outgoing DNS queries do you see when you run dig on the problematic system without specifying the DNS server? Can you find that server listed anywhere in the output of ifconfig /all? (I think that's the command, it's been too long.) -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DIG behavior on Windows 10:
That's a good Avenue to explore I will see if I can find any differences Tim Metzinger 703.963.3015 From: bind-users on behalf of Kevin Darcy Sent: Tuesday, October 23, 2018 6:44:52 PM To: bind-users@lists.isc.org Subject: Re: Strange DIG behavior on Windows 10: To be honest, I don't have a lot of experience running dig on Windows, but I assume it would use the same resolvers as everything else, in which case they're either statically defined (typically through Control Panel) or assigned via DHCP. One thing to consider, though: on Windows, resolvers tend to be assigned *per-interface*. It's possible that you have some interface that has assigned resolvers that you can't reach (due to firewall rules, routing issues, etc.). The resolvers that get chosen may then be dependent on the binding order of the interfaces, or other factors. For that matter, you might be trying to use IPv6 resolvers, even though IPv6 may not be routable from your LAN. Check out ipconfig /all. - Kevin On Tue, Oct 23, 2018 at 6:22 PM Timothy Metzinger mailto:tim.metzin...@outlook.com>> wrote: I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed. On one machine, entering “dig” by itself gives me back the root server list as expected. On the other machine, I get an error that says no name servers could be contacted. However, if I specify the local name server on that second machine by entering dig @192.168.1.250<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.1.250=02%7C01%7C%7C5791d242f3c348dc778908d639393a76%7C84df9e7fe9f640afb435%7C1%7C0%7C636759315284857689=uBRptuFKaxPxt9W5EBasx0iVcNuzXgBoV6K9s14Y2ZY%3D=0>, I get the root server list. My logic says that since I can talk to the recursive server, I don’t have a firewall issue. Instead, BIND is not finding the list of name servers (by reading the registry)? I tried putting in a resolv.conf file in c:\windows\system32\drivers\etc with contents: nameserver 192.168.1.250 nameserver 192.168.1.251 nameserver 8.8.8.8 And that made no difference. Running the command prompt as an administrator makes no difference. At this point I’m stumped and welcome any suggestions. Timothy Metzinger ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users=02%7C01%7C%7C5791d242f3c348dc778908d639393a76%7C84df9e7fe9f640afb435%7C1%7C0%7C636759315284857689=9aZx%2FciW4M%2FazGOHJn1J47FhjlkJzbG%2BZytRMPTaL%2F8%3D=0> to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org<mailto:bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-users=02%7C01%7C%7C5791d242f3c348dc778908d639393a76%7C84df9e7fe9f640afb435%7C1%7C0%7C636759315284857689=9aZx%2FciW4M%2FazGOHJn1J47FhjlkJzbG%2BZytRMPTaL%2F8%3D=0> ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange DIG behavior on Windows 10:
To be honest, I don't have a lot of experience running dig on Windows, but I assume it would use the same resolvers as everything else, in which case they're either statically defined (typically through Control Panel) or assigned via DHCP. One thing to consider, though: on Windows, resolvers tend to be assigned *per-interface*. It's possible that you have some interface that has assigned resolvers that you can't reach (due to firewall rules, routing issues, etc.). The resolvers that get chosen may then be dependent on the binding order of the interfaces, or other factors. For that matter, you might be trying to use IPv6 resolvers, even though IPv6 may not be routable from your LAN. Check out ipconfig /all. - Kevin On Tue, Oct 23, 2018 at 6:22 PM Timothy Metzinger wrote: > > > I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed. > On one machine, entering “dig” by itself gives me back the root server list > as expected. On the other machine, I get an error that says no name > servers could be contacted. > > > > However, if I specify the local name server on that second machine by > entering dig @192.168.1.250, I get the root server list. > > > > My logic says that since I can talk to the recursive server, I don’t have > a firewall issue. Instead, BIND is not finding the list of name servers > (by reading the registry)? I tried putting in a resolv.conf file in > c:\windows\system32\drivers\etc with contents: > > > > nameserver 192.168.1.250 > > nameserver 192.168.1.251 > > nameserver 8.8.8.8 > > > > And that made no difference. Running the command prompt as an > administrator makes no difference. At this point I’m stumped and welcome > any suggestions. > > > > Timothy Metzinger > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Strange DIG behavior on Windows 10:
I have two windows 10 pro boxes, both with Bind 9.12.3 tools installed. On one machine, entering "dig" by itself gives me back the root server list as expected. On the other machine, I get an error that says no name servers could be contacted. However, if I specify the local name server on that second machine by entering dig @192.168.1.250, I get the root server list. My logic says that since I can talk to the recursive server, I don't have a firewall issue. Instead, BIND is not finding the list of name servers (by reading the registry)? I tried putting in a resolv.conf file in c:\windows\system32\drivers\etc with contents: nameserver 192.168.1.250 nameserver 192.168.1.251 nameserver 8.8.8.8 And that made no difference. Running the command prompt as an administrator makes no difference. At this point I'm stumped and welcome any suggestions. Timothy Metzinger ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
Also need to ensure the allow-query-cache ACL on the recursive server allows the client. Otherwise, name resolution may work the first time (allow-recursion), but not the 2nd time (allow-query-cache) since the result is cached. Sent from my BlackBerry - Original Message - From: bind-users-bounces+gord.taylor=rbc@lists.isc.org bind-users-bounces+gord.taylor=rbc@lists.isc.org To: comp-protocols-dns-b...@isc.org comp-protocols-dns-b...@isc.org Sent: Sun Dec 20 22:59:12 2009 Subject: Re: strange dig behavior In article mailman.18.1261358139.21153.bind-us...@lists.isc.org, Pamela Rock prock...@yahoo.com wrote: I've got the following three scenarios The client can query a domain A residing on a recursive name server. What do you mean by a domain residing on a recursive nameserver? If a domain resides on a server, the server should be authoritative for that domain. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! Is that log on the recursive nameserver or the authoritative nameserver? If it's on the recursive server, is the client in the allow-recursion ACL on the server? If it's on the authoritative server, is the recursive server in the allow-query ACL? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courriel peut contenir des renseignements protégés et confidentiels. Lexpéditeur ne renonce pas aux droits et obligations qui sy rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements quil contient par une personne autre que le destinataire désigné est interdite. Si vous recevez ce courriel par erreur, veuillez men aviser immédiatement, par retour de courriel ou par un autre moyen. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
--- On Sun, 12/20/09, Barry Margolin bar...@alum.mit.edu wrote:
From: Barry Margolin bar...@alum.mit.edu
Subject: Re: strange dig behavior
To: comp-protocols-dns-b...@isc.org
Date: Sunday, December 20, 2009, 10:59 PM
In article mailman.18.1261358139.21153.bind-us...@lists.isc.org,
Pamela Rock prock...@yahoo.com
wrote:
I've got the following three scenarios
The client can query a domain A residing on a
recursive name server.
What do you mean by a domain residing on a recursive
nameserver? If a
domain resides on a server, the server should be
authoritative for that
domain.
The client can query a domain B on an authratative
name server.
When client queries domain B through the RNS, a
Status: refused results.
I don't know what is causing the refused. IP
tables is off everywhere, and
there are no ACL's on routers or firewalls.
The only error I'm seeing is the following in the
debug log
20-Dec-2009 19:21:09.443 query-errors: debug 3: client
172.16.0.5#41484:
query failed (REFUSED) for test.com/IN/A at
query.c:3882
I'm running bind 9.6.1 on RH ES 5 64 bit O/S.
Any ideas? Thanks!!
Is that log on the recursive nameserver or the
authoritative nameserver?
If it's on the recursive server, is the client in the
allow-recursion
ACL on the server?
I did not have allow-recursion turned on. I turned it on and it worked.
Thanks!! So recursion yes; was not enough. I also had to allow-recursion {
10.10.1.1; }' to the specific client IP as well.
Thanks!!
If it's on the authoritative server, is the recursive
server in the
allow-query ACL?
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the
group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
strange dig behavior
I've got the following three scenarios The client can query a domain A residing on a recursive name server. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
Pamela Rock wrote: I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. Has nothing to do with firewalls (or ACLs on routers). The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 Any chance you can post the config of the recursive server? Thanks, AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
In article mailman.18.1261358139.21153.bind-us...@lists.isc.org, Pamela Rock prock...@yahoo.com wrote: I've got the following three scenarios The client can query a domain A residing on a recursive name server. What do you mean by a domain residing on a recursive nameserver? If a domain resides on a server, the server should be authoritative for that domain. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! Is that log on the recursive nameserver or the authoritative nameserver? If it's on the recursive server, is the client in the allow-recursion ACL on the server? If it's on the authoritative server, is the recursive server in the allow-query ACL? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
