bind-users Digest, Vol 2842, Issue 2
Warren Kumari
warren at kumari.net
Thu Feb 22 03:53:58 UTC 2018
On Wed, Feb 21, 2018 at 3:06 PM, SIMON BABY <simonkbaby at 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-request at lists.isc.org> wrote:
>>
>> Send bind-users mailing list submissions to
>> bind-users at 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-request at lists.isc.org
>>
>> You can reach the person managing the list at
>> bind-users-owner at 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 <dot at dotat.at>
>> To: Evan Hunt <each at isc.org>
>> Cc: "Darcy Kevin (FCA)" <kevin.darcy at fcagroup.com>,
>> "bind-users at lists.isc.org" <bind-users at lists.isc.org>
>> Subject: Re: questions on allow-query
>> Message-ID: <alpine.DEB.2.11.1802211239220.30577 at grey.csi.cam.ac.uk>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>
>> Evan Hunt <each at 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 <dot at 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 <rharolde at umich.edu>
>> To: Tony Finch <dot at dotat.at>
>> Cc: Evan Hunt <each at isc.org>, "bind-users at lists.isc.org"
>> <bind-users at lists.isc.org>
>> Subject: Re: questions on allow-query
>> Message-ID:
>>
>> <CA+nkc8Dh77PoOcHa8G7-fapOkVJCKT1y_cusFkrSNaBnRTV-gw at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Wed, Feb 21, 2018 at 8:18 AM, Tony Finch <dot at dotat.at> wrote:
>>
>> > Evan Hunt <each at 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 <barmar at alum.mit.edu>
>> To: comp-protocols-dns-bind at isc.org
>> Subject: Re: questions on allow-query
>> Message-ID:
>> <barmar-A1E5B3.12413721022018 at reader.eternal-september.org>
>>
>> In article <mailman.13.1519170108.3031.bind-users at lists.isc.org>,
>> "Darcy Kevin (FCA)" <kevin.darcy at 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" <jp2111 at att.com>
>> To: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
>> Subject: Help
>> Message-ID:
>>
>> <C1CE7B7DB557E547BDE88E3A45CB26FED936B4 at 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 <dot at dotat.at>
>> To: "PENG, JUNAN" <jp2111 at att.com>
>> Cc: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
>> Subject: Re: Help
>> Message-ID: <alpine.DEB.2.11.1802211907230.30577 at grey.csi.cam.ac.uk>
>> Content-Type: TEXT/PLAIN; charset=US-ASCII
>>
>> PENG, JUNAN <jp2111 at 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 <dot at 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 at 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 at 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
More information about the bind-users
mailing list