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