Hi,

1. Can I use  BIND9, for implementing only the client resolve/validation
part?  My system has limited memory and CPU power.
2. In the client resolution part, can i send the queries directly to any of
the root servers? Instead of any public name server.


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-
> g...@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:
>         <C1CE7B7DB557E547BDE88E3A45CB26FED936B4@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

Reply via email to