<div dir="ltr">Hi,<div><br></div><div><br></div><div>1. Can I use BIND9, for implementing only the client resolve/validation part? My system has limited memory and CPU power. <br>2. In the client resolution part, can i send the queries directly to any of the root servers? Instead of any public name server.</div><div><br></div><div><br></div><div>Rgds</div><div>Simon</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 21, 2018 at 11:09 AM, <span dir="ltr"><<a href="mailto:bind-users-request@lists.isc.org" target="_blank">bind-users-request@lists.isc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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" rel="noreferrer" 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.<wbr>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.<wbr>1802211239220.30577@grey.csi.<wbr>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 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 have<br>
> to update my authoritative server because it was vulnerable to a crash 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/" rel="noreferrer" target="_blank">http://dotat.at/</a> - I xn--zr8h 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 northwest.<br>
Rough or very rough, occasionally high in northwest. Rain or showers. 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>
<<a href="mailto:CA%2Bnkc8Dh77PoOcHa8G7-fapOkVJCKT1y_cusFkrSNaBnRTV-gw@mail.gmail.com">CA+nkc8Dh77PoOcHa8G7-<wbr>fapOkVJCKT1y_cusFkrSNaBnRTV-<wbr>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, 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>
<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: <<a href="https://lists.isc.org/pipermail/bind-users/attachments/20180221/1554fbdd/attachment-0001.html" rel="noreferrer" 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.<wbr>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@<wbr>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.<wbr>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 which<br>
> there is no choice but to be non-authoritative (since it's not practical to<br>
> replicate data for the vast diversity of namespaces on the Internet in 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. 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 bandwidth,<br>
> DNSSEC, etc. It is perfectly reasonable, architecturally, for a given DNS<br>
> instance to be a stealth slave for some zones and to either delegate, stub<br>
> and/or forward for other zones, or for the default to be one or the other<br>
> (auth-server as default implies having an internal root). Different zones<br>
> have different requirements, different use cases, query patterns, etc. 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>
<<a href="mailto:C1CE7B7DB557E547BDE88E3A45CB26FED936B4@CAFRFD1MSGUSRJF.ITServices.sbc.com">C1CE7B7DB557E547BDE88E3A45CB2<wbr>6FED936B4@CAFRFD1MSGUSRJF.<wbr>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 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% . 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.<br>
Is there any parameter which impact the performance of DNS? -- No 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: <<a href="https://lists.isc.org/pipermail/bind-users/attachments/20180221/c27d2c7a/attachment-0001.html" rel="noreferrer" 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.<wbr>1802211907230.30577@grey.csi.<wbr>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/" rel="noreferrer" target="_blank">http://dotat.at/</a> - I xn--zr8h 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" rel="noreferrer" 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>
</blockquote></div><br></div>