Re: Installing 9.7?
Daniel Morgan wrote: This may seem like a retarded question. Following advice to update I've downloaded the 9.7 source and built it as per the readme: Was there a question somewhere? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Installing 9.7?
Apologies - my mailer half sent the post Following advice on a duplicate query issue, I've downloaded and built 9.7 from source as per the readme: "To build, just ./configure make" This completed just fine - but what I can't find is any details on how to physically install it after building. I'm used to things like 'make install', but I don't want to blindly run random commands that may cause carnage. I note that it's created plenty of files - some for the Win platform(?) and I'm confused as to what I have to put where. I'm running a Debian based system and I appear to have the most recent packaged version already - hence the source option. I can see an install-sh script but that gives me: ./install-sh install:no input file specified Is there an install DOC that I can't find? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Installing 9.7?
This may seem like a retarded question. Following advice to update I've downloaded the 9.7 source and built it as per the readme: ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Duplicating queries??
On Sun, 2010-02-21 at 17:23 -0800, Doug Barton wrote: > On 02/19/10 23:07, Daniel Morgan wrote: > > I have a couple of BIND servers that I have inherited. I'm getting some > > upstream complaints that one of them is issuing duplicate queries on > > occasions - probably about a dozen times a day. > > You didn't mention what version of BIND you're running. I'm guessing > that it's an older version from before the time when this bug was fixed. > If you're not using an up to date version, upgrade to at least 9.6.1-P3 > and see if that solves your problems. > > > hth, > > Doug > Sorry: ;; ANSWER SECTION: VERSION.BIND. 0 CH TXT "9.5.0-P2.1" However, I have an older version on a secondary box "9.5.0-P2" which does not suffer with the problem. I'll look at upgrading, but this will require change management and the headache that goes with it :-( ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Different handling of referrals by dig and nslookup
On 02/20/10 08:54, kalpesh varyani wrote: > Thanks Dave for pointing this out. > > the first server did not fail, it behaved as per its configuration. > But for a stub resolver, which cannot follow referrals, isnt it logical > for it to detect referrals and move on to the next name server in the list? No. What you're describing is the function of a resolving name server, not a stub resolver. If you think that the stub resolver should behave differently you need to take that up with your OS vendor. Good luck, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Duplicating queries??
On 02/19/10 23:07, Daniel Morgan wrote: > I have a couple of BIND servers that I have inherited. I'm getting some > upstream complaints that one of them is issuing duplicate queries on > occasions - probably about a dozen times a day. You didn't mention what version of BIND you're running. I'm guessing that it's an older version from before the time when this bug was fixed. If you're not using an up to date version, upgrade to at least 9.6.1-P3 and see if that solves your problems. hth, Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Different handling of referrals by dig and nslookup
In message , kalpe sh varyani writes: > Hi Doug, > > Please find my response inline. > > > On Sun, Feb 14, 2010 at 8:53 AM, Doug Barton wrote: > > > On 02/13/10 18:42, kalpesh varyani wrote: > > > >> Hi Rick, > >> > >> I am aware that it is a somewhat odd (but not incorrect, am I right ?) > >> to put a non-recursive name server in the resolv.conf > >> > > > > There are certain very specific circumstances where you might want to do > > this, but in general I can't see any reason to do this, and would not > > recommend it. > > > > but I am not able > >> to understand the behavioral difference of ping/dig and nslookup. > >> > > > > What is it that you want to understand? You seem quite focused on figuring > > out why they are behaving differently, is there some reason why you need to > > put a non-resolving name server in resolv.conf? > > > > > > I guess, I am in one of those specific circumstances. > The reason I prefer to have non-resolving name server in resolv.conf is as > follows: > > Name server A (the first name server with "recursion no;") was not present > earlier, and has been newly configured as a name server. Name server B, > which was previously handling all the name resolution part has "recursion > yes;" > > Also, I would like my 3rd linux system (from where I try resolving names) to > send queries to its root servers, only in case my first name server fails to > resolve the name and sends back a referral. This would ensure that my 3rd > linux system doesnot send queries to its name server, which could have been > handled by the name server B (that was specified in resolv.conf). This would > ensure that the root name server's network wont have unnecesary DNS > traffic. > > > > > But logically shouldn't it be moving to the next name server when the > >> first one fails even in the case of ping and dig. This is what, I think, > >> one would expect from a resolver. > >> > > > > dig is a DNS diagnostic tool. You asked for an answer, you got an answer. > > The fact that it didn't move on is not a mystery. nslookup is designed to > > get its answers from the system resolver, so the real question is, why did > > ping and nslookup behave differently? But that's really a question for your > > linux distro. > > > > My basic concern is that, if my 3rd linux system can resolve a name using > any of the name servers specified in the resolv.conf, then it effectively > means that the remote system (for which name resolution was done) is > reachable from my linux system. And if that is the case, then a ping to > that system should not fail in the name resolution part. > > > > Regards, > Kalpesh ALL the nameservers listed in resolv.conf need to be to answer ALL of the question put to them. Multiple nameservers in resolv.conf are for redundancy. In practice to achieve this the servers listed in resolv.conf need to be recursive. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
