Re: Should we remove the DLV code?
On Wed, May 22, 2019 at 12:41:05PM +0100, Jim Reid wrote: > ISC said DLV would go away once the root got signed. It's long outlived > its usefulness (DLV that is, not ISC). The root first got signed ~10 > years ago. That's more than enough time to make other arrangements and > have an orderly withdrawal from DLV. The ISC DLV service *has* gone away; dlv.isc.org is an empty zone. The lookaside validation code in BIND can still be used with a different lookaside zone, though, if someone wanted to for some reason. One possible reason is distribution of trust anchors for a private corporate domain. AIUI, there are some people doing that; I don't know how many. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
Re: Bind max socket/query per IP
On Wed, May 22, 2019 at 11:39:04PM +0200, Ict Security wrote: > Dear Klaus, > > >>btw - how high is the "extremely load"? > Without old DLZ module, Bind 9.12 scales to thousands and thousands of > queries. > If i include old DLZ module, with postgres, over about 1000 Qps Bind > start to slow down visibly, > > Do you think the old DLZ-Postgreqsl module might the bottleneck? > Any possible replacement, continuing using Postgresql (i made an > implementation to activate some custom filtering with a database). It might be. The dns_db API (which DLZ is an implementation of) is a synchronous API. When a named thread asks dns_db to find an answer for it, it will block until the dns_db API returns. This has almost no effect when using the in-memory zones/cache which is typical, but when you start using a database backend within dns_db which can block waiting for an answer, this can tie up all the worker threads, depending on the rate of response from the database. This would also cause queries to queue up on the listening socket. Use pstack when it appears to be stuck to see if the threads are stuck within the DLZ implementation. If that is the case, perhaps you can try increasing the number of worker threads greatly (named -n ###) to see if that helps mitigating the issue. In answer to your other question about why a query to another alias interface appears to work, it is a different queue that by your description has nothing waiting in it. Mukund ___ 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
Re: Bind max socket/query per IP
Dear Klaus, >>btw - how high is the "extremely load"? Without old DLZ module, Bind 9.12 scales to thousands and thousands of queries. If i include old DLZ module, with postgres, over about 1000 Qps Bind start to slow down visibly, Do you think the old DLZ-Postgreqsl module might the bottleneck? Any possible replacement, continuing using Postgresql (i made an implementation to activate some custom filtering with a database). Thank you, FC Il giorno mer 22 mag 2019 alle ore 21:40 Klaus Darilion ha scritto: > > Am 21.05.2019 um 22:31 schrieb Ict Security: > > Under heavy load, Bind becomes extremely load above a certain number of > > Qps but, if i query an alias IP address (where normally queries don't > > arrive), Bind answers immediately. > > btw - how high is the "extremely load"? > > Klaus > ___ > 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 ___ 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
Re: Bind max socket/query per IP
Am 21.05.2019 um 22:31 schrieb Ict Security: Under heavy load, Bind becomes extremely load above a certain number of Qps but, if i query an alias IP address (where normally queries don't arrive), Bind answers immediately. btw - how high is the "extremely load"? Klaus ___ 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
Re: BIND 9.10 fast only on alias IP
Am 20.05.2019 um 20:16 schrieb Ict Security: How could i increase the number of socket on a single IP address, since Bind is working perfectly on the secondary address, when the first one is stucked? If the incoming traffic is bursty it may happen that the receive queue of the socket is full and hence packets are dropped. You can try to increase the receive queue with sysctl (just google). But if you make it too big, you may queue too much requests and start to queue also retransmission. regards Klaus ___ 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
Re: Should we remove the DLV code?
Matthijs Mekking wrote: > > The BIND 9 development team has been discussing whether we should remove > the DLV code from the BIND 9 source. DLV as it currently works is not useful and it's a lot of complexity to carry around. However, with some tweaks it might be made useful. On the gripping hand the cost/benefit tradeoff probably does not justify working on it :-) The scenario is trust anchor distribution inside an enterprise. There are a few cases where you might want resolvers to be able to validate local zones without talking to the internet: * Business continuity in case of loss of external connectivity. Validation requires chasing the chain of trust from the root; if we only have to chanse down from the corporate domains then internal things still work when the backhoes do their thing. * RFC 1918 reverse DNS. * Private views with distinct keying. DLV is almost but not quite ideal for distributing trust anchors for internal zones, because it insulates validators from the details of most config changes. (A nice counterpart to catalog zones.) The DNS admin only needs to do RFC 5011 for the DLV zone and almost everything else takes care of itself. DLV does not work for this purpose because it is a fallback, whereas what I want is a source of trust anchors that takes higher priority than the public DNS. There are a few reasons why it probably is not worth the effort to adapt DLV in the way I suggest: * Shoudn't we work more on making your network more reliable instead of making the DNS more complicated? (Yes, we have, so in practice this isn't a big problem that needs solving.) * Who cares about DNSSEC validation for RFC 1918 reverse DNS? * There are other ways to allow for private views with different keys from public views (more DS records!), so we don't need a second way to solve this problem. Also my point of view is warped by working for a university where central IT acts a lot more like an ISP than corporate IT, so we don't have control over most system configurations. So that's my brain dump, take it or leave it, and I will still be happy if you go ahead and delete DLV. Tony. -- f.anthony.n.finchhttp://dotat.at/ Cape Wrath to Rattray Head including Orkney: West or northwest 5 or 6. Slight or moderate, becoming rough in northwest. Rain or showers. Moderate or good, occasionally poor. ___ 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
Re: nsupdate reject
@lbutlr wrote:
>
> If I remove "update-policy local; " the nsupdate works, but it seems
> like it should have worked with the update-policy since I was in fact
> local to the bind server.
The "local" keyword enables server-side support for `nsupdate -l`, which
makes dynamic updates really easy to use because you don't have to worry
about TSIG keys. (My production primary server pushes zone changes using
roughly `nsdiff | nsupdate -l`.)
But `update-policy local` actually means something kind of complicated and
subtle and what it means changed a bit last year to address some odd edge
cases (https://kb.isc.org/docs/aa-01599). I still need to delete some
config complication that was a result of this: my primary server zone
clauses have:
allow-update { !{ !localhost; any; }; key local-ddns; };
which is an alternative spelling of `update policy local` that's slightly
safer than the pre-2018 meaning.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: West or southwest 3 or
4, becoming variable 2 or 3 for a time. Smooth or slight becoming moderate in
far west. Fog patches overnight. Moderate or good, occasionally very poor
overnight.
___
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
Re: Forwarders with static-stub
TBH, I haven't worked specifically with "static-stub", but with the classic
"stub", one would put a "null forwarders" statement in the zone definition
to inhibit forwarding.
I.e.
forwarders { };
- Kevin
On Wed, May 22, 2019 at 8:16 AM Ben Lavender wrote:
> Hi,
>
> When I setup static-stub zones with the global forwarders options
> configured, BIND by design forwards the requests before using the stubs.
>
> What is the best way around this so the stubs and cache are consulted
> first?
>
> This is required for split-brain DNS.
>
> Thanks
>
> Regards
>
> Ben Lavender
> ___
> 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
>
___
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
Forwarders with static-stub
Hi, When I setup static-stub zones with the global forwarders options configured, BIND by design forwards the requests before using the stubs. What is the best way around this so the stubs and cache are consulted first? This is required for split-brain DNS. Thanks Regards Ben Lavender ___ 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
Re: Should we remove the DLV code?
> On 21 May 2019, at 16:00, Hugo Salgado-Hernández wrote: > > One important thing is that the "islands of security" concept > may be necessary in different places (companies? communities?) > and the DLV technique is not limited to the root. For the same > reason I consider that Bind's support is vital. This is unfortunate. And mistaken. Making a critical dependency on what was designed as a short-term ugly kludge was a bad idea. More so when it was known from the outset (or should have been known) that this kludge would one day go away. ISC said DLV would go away once the root got signed. It's long outlived its usefulness (DLV that is, not ISC). The root first got signed ~10 years ago. That's more than enough time to make other arrangements and have an orderly withdrawal from DLV. DLV must die. Two shots to the head, just to be sure. ___ 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
Re: Bind max socket/query per IP
Dear Mark, excellent reply, thank you. I found the problem: for legacy compatibility reason, i still need to use the old Bind-DLZ Driver, with Postgresql. I have remove the Driver, used for SQL-filtering reasons, Bind work like a charm. I can remove DLZ for "emergencies periods", but i still need to re-add it again. Is there a way to improve that DLZ driver? Maybe putting SQL Database on another machine, different from the resolver? Or, using the new DLZ driver, is it still possible to use similar queries like old DLZ? Thank you so much for everything you did for me, very best regards! FC Il giorno mer 22 mag 2019 alle ore 00:41 Mark Andrews ha scritto: > > You really need to read up on queuing theory. The fairest way to queue is to > have a single queue and to process off the end of that. Unfortunately > interfaces > don’t form a single queue, they form multiple queues. This sort of behaviour > is expected with multiple queues. The main address is the long queue and the > alias is the short queue. Different clients get different response rates > (unfair) > but the overall rate is the same. This is the reason banks often have a > single > queue that feeds multiple tellers. That way every client gets fair treatment > w.r.t. the amount of time they wait. > > Additionally there been bugs where the current client has not been replaced to > read the next request when named has had to fetch/forward packets which just > stalls the queue processing for those queues. If you are not up to date you > may be running a version with those bugs and have a query pattern that > triggers > them. There are no known instances of this class of bug in the current code. > > > > > On 22 May 2019, at 6:31 am, Ict Security wrote: > > > > Hi guys, > > > > I am experiencing a very strange problem. > > > > Under heavy load, Bind becomes extremely load above a certain number of Qps > > but, if i query an alias IP address (where normally queries don't arrive), > > Bind answers immediately. > > > > I was wondering if there is a kind of limitation on a single IP address due > > to socket or something elss. > > > > I have increased and tuned kernel parameters, but problem still persist. > > > > Thank you, cheers! > > FC > > ___ > > 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 > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ 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
