Host/nslookup/dig queries wrong server
Hi, In certain versions of linux I have noticed that the host/nslookup and dig command query the wrong server. For instance if the following command is run it should return ;; connection timed out; no servers could be reached # host google.co.uk 123.123.123.1 However on certain versions of linux it decides almost instantly since it can't connect to the server specified it will use the name servers in resolv.conf, in this case that is the local host. # host google.co.uk 123.123.123.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: google.co.uk has address 66.102.11.99 google.co.uk has address 66.102.11.104 google.co.uk mail is handled by 10 google.com.s9a1.psmtp.com. google.co.uk mail is handled by 10 google.com.s9a2.psmtp.com. google.co.uk mail is handled by 10 google.com.s9b1.psmtp.com. google.co.uk mail is handled by 10 google.com.s9b2.psmtp.com. This is clearly not expected behaviour and would therefore appear to be a bug. The problem can be reproduced in CentOS release 5.4 (Final) and Fedora 10, which appear to use bind versions 9.3.6-4.P1.el5_4.2 and 9.5.1-2.P2.fc10.i386. Early and later versions of Fedora work as expected and return an error. I had expected both would be running the same version of bind and am surprised that they are so different. Any idea how the correct behaviour can be reinstated and why it is happening. Apologies if this is the wrong place to ask but it would appear to be a bind issue. Thanks Duncan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Host/nslookup/dig queries wrong server
How do I check which one it is? I can't see any option to tell me. It should be which ever one comes with Fedora 10 or Centos 5.4 and appears to be the following on Centos bind-libs-9.3.6-4.P1.el5_4.2 bind-9.3.6-4.P1.el5_4.2 bind-utils-9.3.6-4.P1.el5_4.2 bind-chroot-9.3.6-4.P1.el5_4.2 And the following on Fedora 10 bind-9.5.1-2.P2.fc10.i386 bind-libs-9.5.1-2.P2.fc10.i386 bind-utils-9.5.1-2.P2.fc10.i386 bind-chroot-9.5.1-2.P2.fc10.i386 Duncan > -Original Message- > From: bind-users-bounces+duncan=dcl.co...@lists.isc.org > [mailto:bind-users-bounces+duncan=dcl.co...@lists.isc.org] On > Behalf Of Matus UHLAR - fantomas > Sent: 03 February 2010 11:00 > To: bind-users@lists.isc.org > Subject: Re: Host/nslookup/dig queries wrong server > > > On 03.02.10 10:07, Duncan Berriman wrote: > > In certain versions of linux I have noticed that the > host/nslookup and dig > > command query the wrong server. > > > > For instance if the following command is run it should > return ;; connection > > timed out; no servers could be reached > > > > # host google.co.uk 123.123.123.1 > > > > However on certain versions of linux it decides almost > instantly since it > > can't connect to the server specified it will use the name > servers in > > resolv.conf, in this case that is the local host. > > > > # host google.co.uk 123.123.123.1 > > Using domain server: > > Name: 127.0.0.1 > > Address: 127.0.0.1#53 > > Aliases: > [...] > > there are two "host" commands, one comes from bind, one from > dunnowhere. > check which one do you have installed. > > -- > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ > Warning: I wish NOT to receive e-mail advertising to this address. > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. > My mind is like a steel trap - rusty and illegal in 37 states. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Host/nslookup/dig queries wrong server
# rpm -q -f `which host` bind-utils-9.3.6-4.P1.el5_4.2 Thanks Duncan > -Original Message- > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > Sent: 03 February 2010 13:12 > To: Duncan Berriman > Cc: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org > Subject: Re: Host/nslookup/dig queries wrong server > > > On Wed, Feb 03, 2010 at 11:42:19AM -, > Duncan Berriman wrote > a message of 75 lines which said: > > > How do I check which one it is? I can't see any option to tell me. > > which host > rpm -q -f `which host` > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Host/nslookup/dig queries wrong server
Problem is I am specifying the server on the command line, it is supposed to use only that server, not randomly decide because it can't connect to that server to try any others it feels like. Even the -s option makes no difference. It should even been looking at files or dns Duncan > -Original Message- > From: Lightner, Jeff [mailto:jlight...@water.com] > Sent: 03 February 2010 15:04 > To: Duncan Berriman; bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > > rpm -qa |grep bind > > Will tell you all the BIND packages you have installed via RPM. > > The reason commands check resolv.conf in UNIX/Linux is > typically due to > how you've setup /etc/nsswitch.conf. A line is contained in > it similar > to the following: > hosts: files dns > > The above line says to first check files (/etc/hosts > typically) for the > name and if not found there then try to use dns (/etc/resolv.conf > defines settings for dns lookups). There are other options > for the file > such as nis which would say to look at nis. > > If you don't want to use dns for lookups you can remove "dns" from the > hosts line in nsswitch.conf. > > Note that lookup commands are often designed specifically for name > services so won't necessarily respond from /etc/hosts even if > the entry > is there. The way to verify it's reading /etc/hosts is to do > a ping on > it after the lookup. If the ping works and the lookup appeared not to > then it means it likely found the answer in /etc/hosts. (HP-UX is an > exception - their implementation of nslookup actually retruns entries > from /etc/hosts as well.) > > -Original Message----- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] > On Behalf > Of Duncan Berriman > Sent: Wednesday, February 03, 2010 9:45 AM > To: bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > # rpm -q -f `which host` > bind-utils-9.3.6-4.P1.el5_4.2 > > Thanks > Duncan > > > > -Original Message- > > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > > Sent: 03 February 2010 13:12 > > To: Duncan Berriman > > Cc: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org > > Subject: Re: Host/nslookup/dig queries wrong server > > > > > > On Wed, Feb 03, 2010 at 11:42:19AM -, > > Duncan Berriman wrote > > a message of 75 lines which said: > > > > > How do I check which one it is? I can't see any option to tell me. > > > > which host > > rpm -q -f `which host` > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > Proud partner. Susan G. Komen for the Cure. > > Please consider our environment before printing this e-mail > or attachments. > -- > CONFIDENTIALITY NOTICE: This e-mail may contain privileged or > confidential information and is for the sole use of the > intended recipient(s). If you are not the intended recipient, > any disclosure, copying, distribution, or use of the contents > of this information is prohibited and may be unlawful. If you > have received this electronic transmission in error, please > reply immediately to the sender that you have received the > message in error, and delete it. Thank you. > -- > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Host/nslookup/dig queries wrong server
Whats odd is FC8,9 and 11 are ok. 10 uses 9.5.1 Centos uses 9.3.6 It appears therefore that Redhat are somehow causing the issue when building certain versions. Thanks for your help proving what it is at least I can look at upgrading or downgrading to solve the issue. > -Original Message- > From: Lightner, Jeff [mailto:jlight...@water.com] > Sent: 03 February 2010 15:37 > To: Duncan Berriman; bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > > Interesting. > > On checking a CentOS5 and a RHEL5 system I found I had > bind-utils-9.3.4-10.P1.el5_3.3 and running host with specifying server > did what it should (what you expected). > > I then updated the CentOS5 to bind-utils-9.3.6-4.P1.el5_4.2 > and now have > the issue you're talking about so it appears to be an issue with the > 9.3.6 as released by RedHat (and Fedora - CentOS uses RedHat sources). > > -Original Message- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] > On Behalf > Of Duncan Berriman > Sent: Wednesday, February 03, 2010 10:05 AM > To: bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > Problem is I am specifying the server on the command line, it is > supposed to > use only that server, not randomly decide because it can't connect to > that > server to try any others it feels like. > > Even the -s option makes no difference. > > It should even been looking at files or dns > > Duncan > > > -Original Message- > > From: Lightner, Jeff [mailto:jlight...@water.com] > > Sent: 03 February 2010 15:04 > > To: Duncan Berriman; bind-users@lists.isc.org > > Subject: RE: Host/nslookup/dig queries wrong server > > > > > > rpm -qa |grep bind > > > > Will tell you all the BIND packages you have installed via RPM. > > > > The reason commands check resolv.conf in UNIX/Linux is > > typically due to > > how you've setup /etc/nsswitch.conf. A line is contained in > > it similar > > to the following: > > hosts: files dns > > > > The above line says to first check files (/etc/hosts > > typically) for the > > name and if not found there then try to use dns (/etc/resolv.conf > > defines settings for dns lookups). There are other options > > for the file > > such as nis which would say to look at nis. > > > > If you don't want to use dns for lookups you can remove > "dns" from the > > hosts line in nsswitch.conf. > > > > Note that lookup commands are often designed specifically for name > > services so won't necessarily respond from /etc/hosts even if > > the entry > > is there. The way to verify it's reading /etc/hosts is to do > > a ping on > > it after the lookup. If the ping works and the lookup > appeared not to > > then it means it likely found the answer in /etc/hosts. > (HP-UX is an > > exception - their implementation of nslookup actually > retruns entries > > from /etc/hosts as well.) > > > > -Original Message- > > From: bind-users-bounces+jlightner=water@lists.isc.org > > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] > > On Behalf > > Of Duncan Berriman > > Sent: Wednesday, February 03, 2010 9:45 AM > > To: bind-users@lists.isc.org > > Subject: RE: Host/nslookup/dig queries wrong server > > > > # rpm -q -f `which host` > > bind-utils-9.3.6-4.P1.el5_4.2 > > > > Thanks > > Duncan > > > > > > > -Original Message- > > > From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] > > > Sent: 03 February 2010 13:12 > > > To: Duncan Berriman > > > Cc: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org > > > Subject: Re: Host/nslookup/dig queries wrong server > > > > > > > > > On Wed, Feb 03, 2010 at 11:42:19AM -, > > > Duncan Berriman wrote > > > a message of 75 lines which said: > > > > > > > How do I check which one it is? I can't see any option > to tell me. > > > > > > which host > > > rpm -q -f `which host` > > > > > > -- > > > This message has been scanned for viruses and > > > dangerous content by MailScanner, and is > > > believed to be clean. > > > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https
RE: Host/nslookup/dig queries wrong server
Now filed as bug 561299 Whats the easiest way to upgrade/downgrade bind and bind utils on Fedora and Centos? Thanks Duncan > -Original Message- > From: Lightner, Jeff [mailto:jlight...@water.com] > Sent: 03 February 2010 15:59 > To: Duncan Berriman; bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > > You might want to file a bug report with RedHat. > > I just looked through the notifications I got last year from RedHat > regarding various bug and security updates to the bind > packages and none > of them mention this change. > > Can others on the list verify the default (non-RedHat) bind-utils > package's host command should NOT resolve if server is > specified and the > specified server doesn't resolv? > > -Original Message- > From: bind-users-bounces+jlightner=water@lists.isc.org > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] > On Behalf > Of Duncan Berriman > Sent: Wednesday, February 03, 2010 10:48 AM > To: bind-users@lists.isc.org > Subject: RE: Host/nslookup/dig queries wrong server > > Whats odd is FC8,9 and 11 are ok. > > 10 uses 9.5.1 > Centos uses 9.3.6 > > It appears therefore that Redhat are somehow causing the issue when > building > certain versions. > > Thanks for your help proving what it is at least I can look > at upgrading > or > downgrading to solve the issue. > > > -Original Message- > > From: Lightner, Jeff [mailto:jlight...@water.com] > > Sent: 03 February 2010 15:37 > > To: Duncan Berriman; bind-users@lists.isc.org > > Subject: RE: Host/nslookup/dig queries wrong server > > > > > > Interesting. > > > > On checking a CentOS5 and a RHEL5 system I found I had > > bind-utils-9.3.4-10.P1.el5_3.3 and running host with > specifying server > > did what it should (what you expected). > > > > I then updated the CentOS5 to bind-utils-9.3.6-4.P1.el5_4.2 > > and now have > > the issue you're talking about so it appears to be an issue with the > > 9.3.6 as released by RedHat (and Fedora - CentOS uses > RedHat sources). > > > > -Original Message- > > From: bind-users-bounces+jlightner=water@lists.isc.org > > [mailto:bind-users-bounces+jlightner=water@lists.isc.org] > > On Behalf > > Of Duncan Berriman > > Sent: Wednesday, February 03, 2010 10:05 AM > > To: bind-users@lists.isc.org > > Subject: RE: Host/nslookup/dig queries wrong server > > > > Problem is I am specifying the server on the command line, it is > > supposed to > > use only that server, not randomly decide because it can't > connect to > > that > > server to try any others it feels like. > > > > Even the -s option makes no difference. > > > > It should even been looking at files or dns > > > > Duncan > > > > > -Original Message- > > > From: Lightner, Jeff [mailto:jlight...@water.com] > > > Sent: 03 February 2010 15:04 > > > To: Duncan Berriman; bind-users@lists.isc.org > > > Subject: RE: Host/nslookup/dig queries wrong server > > > > > > > > > rpm -qa |grep bind > > > > > > Will tell you all the BIND packages you have installed via RPM. > > > > > > The reason commands check resolv.conf in UNIX/Linux is > > > typically due to > > > how you've setup /etc/nsswitch.conf. A line is contained in > > > it similar > > > to the following: > > > hosts: files dns > > > > > > The above line says to first check files (/etc/hosts > > > typically) for the > > > name and if not found there then try to use dns (/etc/resolv.conf > > > defines settings for dns lookups). There are other options > > > for the file > > > such as nis which would say to look at nis. > > > > > > If you don't want to use dns for lookups you can remove > > "dns" from the > > > hosts line in nsswitch.conf. > > > > > > Note that lookup commands are often designed specifically for name > > > services so won't necessarily respond from /etc/hosts even if > > > the entry > > > is there. The way to verify it's reading /etc/hosts is to do > > > a ping on > > > it after the lookup. If the ping works and the lookup > > appeared not to > > > then it means it likely found the answer in /etc/hosts. > > (HP-UX is an > > > exception - their implementation of nslookup act
RE: Host/nslookup/dig queries wrong server
I just verified this bug on a new install of Centos 5.4 I then downloaded the source bind-9.3.6-P1.tar.gz And built it with ./configure --with-openssl --prefix=/usr --sysconfdir=/etc --localstatedir=/var/named make Even without actually installing it (just running host from the build area) I can see the host command built from source works correctly. Not sure how Redhat have managed to break it. Duncan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Host/nslookup/dig queries wrong server
Thanks adam - Agreed its just host and nslookup, dig is fine. Duncan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: COM/NET/EDU nameserver changes
I noticed this posting with interest as it's the first I've heard of it. Whilst I can see the change could you explain it a bit more simply so I can understand the affects. I understand how glue works but not entirely sure how this change will cause failures. We've already had one customer have a problem today - we don't manage their dns I hasten to add, and its badly configured but it looks like they have been hit by this change as their dns has 'suddenly' started to fail this morning. I'd like to understand more as to exactly what implications the change has so I can explain to irate customers why its their issue and not ours! Thanks Duncan > -Original Message- > From: bind-users-bounces+duncan=dcl.co...@lists.isc.org > [mailto:bind-users-bounces+duncan=dcl.co...@lists.isc.org] On > Behalf Of Mark Andrews > Sent: 01 March 2010 23:14 > To: bind-us...@isc.org > Subject: Re: COM/NET/EDU nameserver changes > > > > The gtld nameservers are being upgraded this week. They will no > longer return glue as a answer. This will mean that some broken > delegations that "worked" last week will no longer work by the end > of this week. In particular "glue only" delegations will be much > more visible. > > Below is what the new referrals look like. Note the answer section > is empty. > > ; <<>> DiG 9.3.6-P1 <<>> ns1.google.com @l.gtld-servers.net +norec > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57145 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > > ;; QUESTION SECTION: > ;ns1.google.com. IN A > > ;; AUTHORITY SECTION: > google.com. 172800 IN NS ns1.google.com. > google.com. 172800 IN NS ns2.google.com. > google.com. 172800 IN NS ns3.google.com. > google.com. 172800 IN NS ns4.google.com. > > ;; ADDITIONAL SECTION: > ns1.google.com. 172800 IN A 216.239.32.10 > ns2.google.com. 172800 IN A 216.239.34.10 > ns3.google.com. 172800 IN A 216.239.36.10 > ns4.google.com. 172800 IN A 216.239.38.10 > > ;; Query time: 203 msec > ;; SERVER: 192.41.162.30#53(192.41.162.30) > ;; WHEN: Tue Mar 2 10:08:41 2010 > ;; MSG SIZE rcvd: 164 > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE:+61 2 9871 4742 INTERNET: m...@isc.org > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: COM/NET/EDU nameserver changes
Ignore this request. I found the explanation. https://www.verisign.com/domain-name-services/domain-information-center/dns- behavior/index.html It matches my customer issue so I'm glad to be able to confirm to him the problem and why it has suddenly appeared. Thanks Duncan > -Original Message- > From: bind-users-bounces+duncan=dcl.co...@lists.isc.org > [mailto:bind-users-bounces+duncan=dcl.co...@lists.isc.org] On > Behalf Of Duncan Berriman > Sent: 03 March 2010 10:46 > To: 'Mark Andrews'; bind-us...@isc.org > Subject: RE: COM/NET/EDU nameserver changes > > > I noticed this posting with interest as it's the first I've > heard of it. > > Whilst I can see the change could you explain it a bit more > simply so I can > understand the affects. I understand how glue works but not > entirely sure > how this change will cause failures. > > We've already had one customer have a problem today - we > don't manage their > dns I hasten to add, and its badly configured but it looks > like they have > been hit by this change as their dns has 'suddenly' started > to fail this > morning. > > I'd like to understand more as to exactly what implications > the change has > so I can explain to irate customers why its their issue and not ours! > > Thanks > Duncan > > > > -Original Message- > > From: bind-users-bounces+duncan=dcl.co...@lists.isc.org > > [mailto:bind-users-bounces+duncan=dcl.co...@lists.isc.org] On > > Behalf Of Mark Andrews > > Sent: 01 March 2010 23:14 > > To: bind-us...@isc.org > > Subject: Re: COM/NET/EDU nameserver changes > > > > > > > > The gtld nameservers are being upgraded this week. They will no > > longer return glue as a answer. This will mean that some broken > > delegations that "worked" last week will no longer work by the end > > of this week. In particular "glue only" delegations will be much > > more visible. > > > > Below is what the new referrals look like. Note the answer section > > is empty. > > > > ; <<>> DiG 9.3.6-P1 <<>> ns1.google.com @l.gtld-servers.net +norec > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57145 > > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 > > > > ;; QUESTION SECTION: > > ;ns1.google.com.IN A > > > > ;; AUTHORITY SECTION: > > google.com. 172800 IN NS ns1.google.com. > > google.com. 172800 IN NS ns2.google.com. > > google.com. 172800 IN NS ns3.google.com. > > google.com. 172800 IN NS ns4.google.com. > > > > ;; ADDITIONAL SECTION: > > ns1.google.com. 172800 IN A 216.239.32.10 > > ns2.google.com. 172800 IN A 216.239.34.10 > > ns3.google.com. 172800 IN A 216.239.36.10 > > ns4.google.com. 172800 IN A 216.239.38.10 > > > > ;; Query time: 203 msec > > ;; SERVER: 192.41.162.30#53(192.41.162.30) > > ;; WHEN: Tue Mar 2 10:08:41 2010 > > ;; MSG SIZE rcvd: 164 > > > > Mark > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: m...@isc.org > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > > -- > > This message has been scanned for viruses and > > dangerous content by MailScanner, and is > > believed to be clean. > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Negative Cache won't go!
Not unusual in my experience. Probably find the dns is badly configured - at a guess different ns records at root servers or missing/badly configured ns records. Check the dns of the domain out with dnsstuff.com and fix any errors. Probably find it works then. Duncan Alans wrote: Hi everyone, There is a website that was returning servfail but works fine with +trace. AFAIK, negative cache default value is 3 hrs, and I haven't set max-ncache-ttl, also domain owner says he used default TTL in his zone files. I waited for 1 day and the website didn't work till I restarted named. Also I used rndc flushname domainname.com (with and without www.). Is there any other way to solve this issue without restarting named? And any clue why named isn't purging it? I'm using Bind v9.4.2 on Centos 5.2. Regards, Alans ___ 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
