On 01.08.14 09:56, Xuan Hung wrote:
I think this problem of me, need have version new of Bind.
I think resolver of Bind.9.9.5 have problem when response for customer.
If recusive client of My DNS increase to 4000 then resolver response servfail.
you apparently need to tune max-recursive-clients
7;t use is the
way to go instead make is secure with other switches
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.isc.org/pipermail/bind-users
there are no features
rndc could provide and so disable something you don't use is the
way to go instead make is secure with other switches
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP d
Almost certainly not running BIND. Almost certainly is running a
"creative" load balancing solution.
hth,
Doug
On 07/31/2014 12:56 PM, Ray Van Dolson wrote:
Not BIND-related specifically... (though the server below could be
running BIND I suppose).
This seems weird. Why is this authoritati
Am 31.07.2014 um 21:56 schrieb Ray Van Dolson:
Not BIND-related specifically... (though the server below could be
running BIND I suppose).
This seems weird. Why is this authoritative server returning *some*
answers with decrementing TTL's?
zone delegation as example
in that case it may be a
The "never changes" TTLs are from zones for which the server is authoritative.
Otherwise, the TTL is the decrementing time-in-cash-before-required-refetchng.
hth,
Len
On Thursday, July 31, 2014 12:56 PM, Ray Van Dolson wrote:
Not BIND-related specifically... (though the server below coul
Not BIND-related specifically... (though the server below could be
running BIND I suppose).
This seems weird. Why is this authoritative server returning *some*
answers with decrementing TTL's?
$ dig @ns1.dtra.mil dtra.mil NS
; <<>> DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 <<>> @ns1.dtra.mil dtra.mil
On 7/31/2014 3:08 PM, /dev/rob0 wrote:
On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
i am doing reloads of named with "killall -HUP named" just
because i disabled rndc comp
Am 31.07.2014 um 21:08 schrieb /dev/rob0:
> On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
>> don't get me wrong but if someone creates *any* bind
>> configuration and zone-files with self developed software
>
> ... that someone is almost surely doing it wrong. "Zone files"?
>
On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
> Am 31.07.2014 um 17:41 schrieb /dev/rob0:
> > On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
> >> i am doing reloads of named with "killall -HUP named" just
> >> because i disabled rndc completly for security reasons
Am 31.07.2014 um 20:51 schrieb /dev/rob0:
> On Thu, Jul 31, 2014 at 12:11:40PM -0400, Kevin Darcy wrote:
>> kill -HUP is way more disruptive than necessary for a mere
>> interface scan. It's overkill.
>
> Furthermore, on a server with lots of zones, it could cause a DoS
> while zones are reload
On Thu, Jul 31, 2014 at 12:11:40PM -0400, Kevin Darcy wrote:
> kill -HUP is way more disruptive than necessary for a mere
> interface scan. It's overkill.
Furthermore, on a server with lots of zones, it could cause a DoS
while zones are reloading, and named is unable to answer.
--
http://rob0
On 7/31/2014 11:56 AM, Reindl Harald wrote:
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
i am doing reloads of named with "killall -HUP named" just because
i disabled rndc completly for security reasons and configurations
are generate
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
> On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
>> i am doing reloads of named with "killall -HUP named" just because
>> i disabled rndc completly for security reasons and configurations
>> are generated with own software only needs nam
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
> i am doing reloads of named with "killall -HUP named" just because
> i disabled rndc completly for security reasons and configurations
> are generated with own software only needs named to reload
Hmm, rndc is securable. You don't
9.10 also has "rndc scan" for platforms without a routing socket
or if you want to do it manually.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
In message , Johannes Kastl writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everyone,
>
> in the quest to use a master behind a Router with changing IPs, I set
> up a VPN and told bind on both sides to listen on the additional VPN-IPs.
>
> But, sometimes they are not available
Am 31.07.2014 um 13:24 schrieb Johannes Kastl:
> in the quest to use a master behind a Router with changing IPs, I set
> up a VPN and told bind on both sides to listen on the additional VPN-IPs.
>
> But, sometimes they are not available at bind startup or the VPN loses
> connection. So, when the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 31.07.14 13:29 Tony Finch wrote:
> Have you tried it to see if it just works automatically without an
> explicit poke from rndc?
I guess I made a problem where there is none. At least if the option
below works...
I'll give it a try...
> The ARM
Johannes Kastl wrote:
>
> in the quest to use a master behind a Router with changing IPs, I set
> up a VPN and told bind on both sides to listen on the additional VPN-IPs.
>
> But, sometimes they are not available at bind startup or the VPN loses
> connection. So, when the VPN connection is ready
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
in the quest to use a master behind a Router with changing IPs, I set
up a VPN and told bind on both sides to listen on the additional VPN-IPs.
But, sometimes they are not available at bind startup or the VPN loses
connection. So, when t
On 24/07/2014 01:35, Matthew Calder wrote:
> At the moment I'm limited to using 2 UDP listeners per interface. When
> stress testing I can see that only 2 out of 4 CPUs are being used, I'm
> guessing because I'm limited to 2 listeners. Any suggestions for what
> could be limiting BIND from using a
22 matches
Mail list logo
