RE: does bind depends on system DNS settings for lookup?

-Original Message- > From: bind-users-boun...@lists.isc.org > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Dil Lee > Sent: Wednesday, 18 November 2015 3:42 PM > To: bind-users@lists.isc.org > Subject: does bind depends on system DNS settings for lookup? > Hi, > This is probably

RE: file descriptor exceeds limit

Just wondering. You mention you're using RHEL6; are you also getting messages in 'dmesg' about connection tracking tables being full? You may need some 'NOTRACK' rules in your iptables. STUART BROWNE Senior Unix Administrator, Network Administrator, Database Ad

RE: Not able to query from F.ROOT-SERVERS.NET over IPv6 -- FROM INDIA

sts.isc.org Subject: Re: Not able to query from F.ROOT-SERVERS.NET over IPv6 -- FROM INDIA I am trying to telnet (port 53)/ping/dig on 2001:500:2F::F address. Src address is 2405:8a00::/32. Trace is blocked at firewall end. If needed i wl try to get the same. Regards, Gaurav Kansal STUART BROW

RE: Suppress log entry...

>On 14.04.15 07:36, SH Development wrote: >>Like what? I’ve never had any issues. > >Like you uselessly flush all cached data, RTTs ... and you get unwanted log >line in the output. > >If you never had any issues with reconfig, use rndc reconfig. > >>> On Apr 13, 2015, at 12:27 PM, Emil Natan wro

[OFF-TOPIC] RE: com.google how did they do that

.ibm, .cisco, .apple, .google, .sucks, .melbourne and many hundreds of others have been applied for and hundreds already delegated into the root. '.hp' was deemed too short (must be at least 3 characters). See https://gtldresult.icann.org/application-result/applicationstatus for the new TLD's

RE: Automatic flushing of the jnl files

Bob, Some date and record number details from one of my systems, with 'max-journal-size: 100m'. Yes, I've changed the zone names.. ;) NOTE: Add/Del numbers show total / non-dnssec-or-soa related update numbers. 'zone1' is a monitoring test zone that has sub-zone delegation changes a few times

RE: AW: Disable DNSSEC Validation for selected Domains

> Unfortunately we can't sign the fictional TLD, since we are neither master > nor slave of the zone. > We are just forwarding our queries to a foreign authorative Server. > > Grüße, > Stefan If the zone isn't signed, it shouldn't be trying to validate it as there's nothing to validate. Unless

RE: Inline-signing feature request: Directly set the signed zone's serial number

> -Original Message- > From: bind-users-boun...@lists.isc.org [mailto:bind-users- > boun...@lists.isc.org] On Behalf Of Alan Clegg > Sent: Wednesday, 8 October 2014 8:35 AM > To: bind-users@lists.isc.org > Subject: Re: Inline-signing feature request: Directly set the signed > zone's serial

RE: Two domains reporting errors

> > Note that there are only relative names in my example. This could > > load as any zone name. You might want to use some fully-qualified > > names on the RHS, such as "root.covisp.net." as the SOA RNAME. > > Wait a second, so the zone name comes from the named.conf? Yes. > I could have, f

RE: Promoting slave to master DNS server with dynamic updates

> -Original Message- > From: bind-users-boun...@lists.isc.org [mailto:bind-users- > boun...@lists.isc.org] On Behalf Of Mark Andrews > Sent: Friday, 12 September 2014 8:58 AM > To: John Miller > Cc: Bind Users Mailing List > Subject: Re: Promoting slave to master DNS server with dynamic u

RE: Simple max-journal-size question

.. and somehow didn't answer your question, sorry. first thing in the morning. Just a 'rndc reconfig' should be sufficient to get the configuration change to act. Stuart > -Original Message----- > From: Stuart Browne > Sent: Thursday, 12 June 2014 9:17 AM >

RE: Simple max-journal-size question

This one is a bit of a fun one to understand. Whilst setting this seems to suggest "This will be the biggest size the journal will ever get to", it isn't. This suggests to bind to flush the journal when it reaches this size. If the journal is busy however, the flush will be delayed until such

RE: Generic reasons for recursive performance not to peg CPU?

Wouldn't it be something along the lines about recursive using cache-in-memory where the authoritative is using lookups of zone-in-memory? The algorithms are probably different. I've not looked at the code though. Stuart > -Original Message- > From: bind-users-bounces+stuart.browne=aus

RE: Performance Tuning RHEL 5 and Bind

> -Original Message- > From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org > [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org] > On Behalf Of brett smith > Sent: Sunday, 20 October 2013 12:35 PM > To: sth...@nethelp.no > Cc: bind-users@lists.is

[Off-Topic] RE: This list's prefix

> -Original Message- > From: bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org > [mailto:bind-users-bounces+stuart.browne=ausregistry.com...@lists.isc.org] > On Behalf Of Elmar K. Bins > Sent: Thursday, 6 June 2013 5:46 AM > To: bind-users@lists.isc.org > Subject: Re: This l

Throughput drop using smaller zones

Hi, I've been doing some throughput testing of BIND for both signed and non-signed zones of various sizes and have noticed some odd behaviour. Using the 'dnsperf' tool to perform the testing, I see that smaller (signed) zones perform considerably worse than larger zones when queried with +DO.