Thanks a lot Warren . Can you please write me the steps to make the bind only as a resolver . It will be great if you could send me if there is any document .
Rgds Simon On Wednesday, February 21, 2018, Warren Kumari <war...@kumari.net> wrote: > On Wed, Feb 21, 2018 at 3:06 PM, SIMON BABY <simonkb...@gmail.com> wrote: > > Hi, > > > > > > 1. Can I use BIND9, for implementing only the client resolve/validation > > part? My system has limited memory and CPU power. > > Yup, sure can. BIND isn't the smallest / lowest CPU software out > there, but you can definitely set it up to be just a DNSSEC validating > resolver (and not an authorative server). > > > 2. In the client resolution part, can i send the queries directly to any > of > > the root servers? Instead of any public name server. > > Your question is a bit vague, I'm assuming you mean "Have BIND do the > normal resolution (e.g for www.example.com ask the root, and then > follow the referral to example.com's name servers, and then asks them > for www.example.com (and not e.g forward to Google Public DNS)?" If > so, then, yes, definitely -- this is the default behavior. Having BIND > forward queries to another recursive (like 8.8.8.8, OpenDNS, Quad9) > requires special configuration (with the "forward" command). > > I'd suggest reading Cricket's "DNS and BIND" > (http://shop.oreilly.com/product/9780596100575.do) as a good intro to > this. > > W > > > > > > > Rgds > > Simon > > > > > > On Wed, Feb 21, 2018 at 11:09 AM, <bind-users-requ...@lists.isc.org> > wrote: > >> > >> Send bind-users mailing list submissions to > >> bind-users@lists.isc.org > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.isc.org/mailman/listinfo/bind-users > >> or, via email, send a message with subject or body 'help' to > >> bind-users-requ...@lists.isc.org > >> > >> You can reach the person managing the list at > >> bind-users-ow...@lists.isc.org > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of bind-users digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: questions on allow-query (Tony Finch) > >> 2. Re: questions on allow-query (Bob Harold) > >> 3. Re: questions on allow-query (Barry Margolin) > >> 4. Help (PENG, JUNAN) > >> 5. Re: Help (Tony Finch) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Wed, 21 Feb 2018 13:18:09 +0000 > >> From: Tony Finch <d...@dotat.at> > >> To: Evan Hunt <e...@isc.org> > >> Cc: "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com>, > >> "bind-users@lists.isc.org" <bind-users@lists.isc.org> > >> Subject: Re: questions on allow-query > >> Message-ID: <alpine.deb.2.11.1802211239220.30...@grey.csi.cam.ac.uk> > >> Content-Type: TEXT/PLAIN; charset=US-ASCII > >> > >> Evan Hunt <e...@isc.org> wrote: > >> > > >> > One thing to keep in mind, though, is that the two services will share > >> > each > >> > other's fates. If I were deploying a really big high-traffic server, > I > >> > might consider whether I wanted my recursive service to have to wait > for > >> > all the zones to load before it could function, or whether I wanted to > >> > have > >> > to update my authoritative server because it was vulnerable to a crash > >> > bug > >> > in the recursive code. > >> > >> On our recursive servers we have authoritative copies of all our local > >> zones so that they can give answers for on-site stuff even when bits of > >> the network are broken. (Downstream validating resolvers will probably > be > >> out of luck tho.) This is about 70 zones, average size about 2MB, > biggest > >> about 30MB. But, we also have RPZ and the biggest blocklist is about > half > >> a gig and this dominates the startup time (it takes nearly 20 seconds). > >> This isn't an availability problem, tho, because the recursive servers > are > >> in an HA cluster using keepalived and the health checker won't bring a > >> node into service until it has finished starting. > >> > >> Our authoritative servers are separate. Probably the main reason for not > >> turning them into views on the recursive servers is that the auth > servers > >> have to be more exposed to attack from the Internet. Our recursive > servers > >> can do things like firewall off external TCP connection attempts, to > avoid > >> connection pool exhaustion attacks. I've done less HA engineering on our > >> auth servers, and I'm relatively relaxed about patching them, because I > >> (foolishly?) trust other resolvers out on the Internet to make effective > >> use of my secondaries. > >> > >> Tony. > >> -- > >> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h > >> punycode > >> Rockall: Southerly, 5 at first in far southeast, otherwise 6 to gale 8, > >> increasing severe gale 9 at times, veering westerly 5 or 6 later in > >> northwest. > >> Rough or very rough, occasionally high in northwest. Rain or showers. > >> Moderate > >> or good. > >> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Wed, 21 Feb 2018 09:16:23 -0500 > >> From: Bob Harold <rharo...@umich.edu> > >> To: Tony Finch <d...@dotat.at> > >> Cc: Evan Hunt <e...@isc.org>, "bind-users@lists.isc.org" > >> <bind-users@lists.isc.org> > >> Subject: Re: questions on allow-query > >> Message-ID: > >> > >> <ca+nkc8dh77poocha8g7-fapokvjckt1y_cusfkrsnabnrtv...@mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> On Wed, Feb 21, 2018 at 8:18 AM, Tony Finch <d...@dotat.at> wrote: > >> > >> > Evan Hunt <e...@isc.org> wrote: > >> > > > >> > > One thing to keep in mind, though, is that the two services will > share > >> > each > >> > > other's fates. If I were deploying a really big high-traffic > server, > >> > > I > >> > > might consider whether I wanted my recursive service to have to wait > >> > > for > >> > > all the zones to load before it could function, or whether I wanted > to > >> > have > >> > > to update my authoritative server because it was vulnerable to a > crash > >> > bug > >> > > in the recursive code. > >> > > >> > On our recursive servers we have authoritative copies of all our local > >> > zones so that they can give answers for on-site stuff even when bits > of > >> > the network are broken. (Downstream validating resolvers will probably > >> > be > >> > out of luck tho.) This is about 70 zones, average size about 2MB, > >> > biggest > >> > about 30MB. But, we also have RPZ and the biggest blocklist is about > >> > half > >> > a gig and this dominates the startup time (it takes nearly 20 > seconds). > >> > This isn't an availability problem, tho, because the recursive servers > >> > are > >> > in an HA cluster using keepalived and the health checker won't bring a > >> > node into service until it has finished starting. > >> > > >> > Our authoritative servers are separate. Probably the main reason for > not > >> > turning them into views on the recursive servers is that the auth > >> > servers > >> > have to be more exposed to attack from the Internet. Our recursive > >> > servers > >> > can do things like firewall off external TCP connection attempts, to > >> > avoid > >> > connection pool exhaustion attacks. I've done less HA engineering on > our > >> > auth servers, and I'm relatively relaxed about patching them, because > I > >> > (foolishly?) trust other resolvers out on the Internet to make > effective > >> > use of my secondaries. > >> > > >> > Tony. > >> > -- > >> > >> > >> Likewise. My resolvers are stealth slaves for all my zones. Mainly > >> because they get updates faster - users do not have to wait for the old > >> data to expire its ttl before the resolver gets the new data. Also, > there > >> is no chance of cache poisoning for my zones, since they are slaved, not > >> cached. > >> > >> -- > >> Bob Harold > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> <https://lists.isc.org/pipermail/bind-users/ > attachments/20180221/1554fbdd/attachment-0001.html> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Wed, 21 Feb 2018 12:41:41 -0500 > >> From: Barry Margolin <bar...@alum.mit.edu> > >> To: comp-protocols-dns-b...@isc.org > >> Subject: Re: questions on allow-query > >> Message-ID: > >> <barmar-a1e5b3.12413721022...@reader.eternal-september.org> > >> > >> In article <mailman.13.1519170108.3031.bind-us...@lists.isc.org>, > >> "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote: > >> > >> > Other than the master server(s), where there is no choice but to be > >> > authoritative, at one end of the spectrum, and border resolvers, for > >> > which > >> > there is no choice but to be non-authoritative (since it's not > practical > >> > to > >> > replicate data for the vast diversity of namespaces on the Internet in > >> > which > >> > to resolve queries), at the other end of the spectrum, there is a > middle > >> > ground, where there is a real *choice* as to whether to be > authoritative > >> > (i.e. a slave, possibly a "stealth slave") for internal zones or not. > >> > The > >> > decision of whether to be authoritative or not, is driven by a number > of > >> > factors, such as worst-case-query-performance sensitivity, > availability > >> > requirements, query-frequency-versus-refresh-overhead, available > >> > bandwidth, > >> > DNSSEC, etc. It is perfectly reasonable, architecturally, for a given > >> > DNS > >> > instance to be a stealth slave for some zones and to either delegate, > >> > stub > >> > and/or forward for other zones, or for the default to be one or the > >> > other > >> > (auth-server as default implies having an internal root). Different > >> > zones > >> > have different requirements, different use cases, query patterns, etc. > >> > so why > >> > wouldn't a choice of different configurations for different zones be > >> > appropriate? > >> > >> Being authoritative for your own zones, and recursive for everything > >> else, is generally not a big problem. > >> > >> The problemat case is service providers being authoritative for customer > >> domains and using the same servers for caching. What often happens is > >> that a customer switches to another DNS provider, but doesn't inform > >> their old provider. As a result, all the other customers who use these > >> caching servers continue to get the obsolete version of this customer's > >> domains. > >> > >> When I worked at an ISP a couple of decades ago, I wrote a script that > >> periodically checked the delegations of all the domains we hosted, to > >> make sure they still pointed to us. > >> > >> -- > >> Barry Margolin > >> Arlington, MA > >> > >> > >> ------------------------------ > >> > >> Message: 4 > >> Date: Wed, 21 Feb 2018 19:02:24 +0000 > >> From: "PENG, JUNAN" <jp2...@att.com> > >> To: "bind-users@lists.isc.org" <bind-users@lists.isc.org> > >> Subject: Help > >> Message-ID: > >> > >> < > c1ce7b7db557e547bde88e3a45cb26fed93...@cafrfd1msgusrjf.itservices.sbc.com> > >> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hi > >> > >> I encountered a weir performance issue: > >> > >> > >> Virtual DNS running in VM - (Flavor 4 vCPU), in theory, the named > process > >> can reach to 400% > >> > >> Query Log is On: > >> > >> When Traffic is 35KQPS, Named Process CPU usage can reach to maximum > 260% > >> . but , Even if I increase the traffic to 70KQPS, the named process > CPU > >> usage can't be more than 260% (lot of failure). - still 260% CPU usage, > >> which impact DNS performance significantly. > >> Is there any parameter which impact the performance of DNS? -- No > >> recursive query during my performance test. > >> > >> > >> Query Log is off: > >> Named Process CPU usage can be more than 260%. > >> > >> > >> Why Query log off/on feature is impacting named CPU Usage ? > >> > >> > >> rndc status > >> version: BIND 9.10.5-S1 <id:041e344> (Unknown) > >> boot time: Tue, 13 Feb 2018 06:12:53 GMT > >> last configured: Tue, 13 Feb 2018 06:12:53 GMT > >> CPUs found: 4 > >> worker threads: 4 > >> UDP listeners per interface: 3 > >> number of zones: 102 > >> debug level: 0 > >> xfers running: 0 > >> xfers deferred: 0 > >> soa queries in progress: 0 > >> query logging is OFF > >> recursive clients: 0/900/1000 > >> tcp clients: 0/15000 > >> server is up and running > >> > >> > >> BR > >> Michael > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > >> <https://lists.isc.org/pipermail/bind-users/ > attachments/20180221/c27d2c7a/attachment-0001.html> > >> > >> ------------------------------ > >> > >> Message: 5 > >> Date: Wed, 21 Feb 2018 19:09:27 +0000 > >> From: Tony Finch <d...@dotat.at> > >> To: "PENG, JUNAN" <jp2...@att.com> > >> Cc: "bind-users@lists.isc.org" <bind-users@lists.isc.org> > >> Subject: Re: Help > >> Message-ID: <alpine.deb.2.11.1802211907230.30...@grey.csi.cam.ac.uk> > >> Content-Type: TEXT/PLAIN; charset=US-ASCII > >> > >> PENG, JUNAN <jp2...@att.com> wrote: > >> > > >> > Why Query log off/on feature is impacting named CPU Usage ? > >> > >> It has to serialize query processing in order to write to the log, and > >> that serialization barrier limits the parallelism that it can achieve > >> (due to Amdahl's law). > >> > >> Tony. > >> -- > >> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h > >> punycode > >> South Utsire: Northerly or northeasterly 4 or 5, becoming variable 3 or > 4. > >> Slight or moderate. Fair. Good. > >> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> bind-users mailing list > >> bind-users@lists.isc.org > >> https://lists.isc.org/mailman/listinfo/bind-users > >> > >> > >> ------------------------------ > >> > >> End of bind-users Digest, Vol 2842, Issue 2 > >> ******************************************* > > > > > > > > _______________________________________________ > > 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 > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf >
_______________________________________________ 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