bind-users Digest, Vol 2842, Issue 2

SIMON BABY simonkbaby at gmail.com
Thu Feb 22 05:56:47 UTC 2018


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 <warren at kumari.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20180221/95c0c8a2/attachment-0001.html>


More information about the bind-users mailing list