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