In message <20100317172506.gb21...@isc.org>, Evan Hunt writes:
> > BIND <=9.5 doesn't know that it's supposed to pass them in a NXDOMAIN
> > response.
>
> Correct, and whoops. We should have backported at least that much
> knowledge of NSEC3.
Not really. You need a NSEC3 aware path between the
On Wed, 17 Mar 2010, Evan Hunt wrote:
No, not at all. Threaded works fine--I use it myself. It's just a little
touchy about file permissions. On linux, I'm given to understand, a
multi-threaded application can't relinquish its root privileges and then
get them back later if it needs to open a
> [Jack Tavares] So, for bind 9.6.x and 9.7.0 is the recommendation to run
> nonthreaded?
No, not at all. Threaded works fine--I use it myself. It's just a little
touchy about file permissions. On linux, I'm given to understand, a
multi-threaded application can't relinquish its root privileges
Well, the zone is publishing NS records that all return REFUSED when I
query them, so from my point of view the whole domain is broken.
The *best* approach here is to contact the domain admin and get them to
fix it.
In the absence of that, how to circumvent it? ns1.ecb.int apparently
doesn't
You said:
>On most operating systems, the default is threaded.
>On linux, the default is unthreaded, for historical reasons having t
>do with an odd interaction between linux threads and linux process
>privileges. I expect we'll correct this fairly soon; it's on the
>to-do list for 9.7.1.
[Jack
> BIND <=9.5 doesn't know that it's supposed to pass them in a NXDOMAIN
> response.
Correct, and whoops. We should have backported at least that much
knowledge of NSEC3.
> That said, I thought it would be possible to explicitely ask for TYPE50.
> But that seems not to work, either:
IIRC, RFC 51
On 16.03.10 15:18, Jack Tavares wrote:
> What is the default build on linux (2.6) with regard to threads.
> If I don't explicitly enable or disable threads, does named
> run threaded or unthreaded?
On most operating systems, the default is threaded.
On linux, the default is unthreaded, for histor
Stephane Bortzmeyer wrote:
> I cannot get the NSEC3 records through a BIND resolver if it is
> version <= 9.5:
>
> % dig +dnssec jhfgTCFGD564564.org
>
> If BIND >= 9.6, it works (or with Unbound). Yes, NSEC3 support was
> added in 9.6 but, for older BINDs, TYPE50 (NSEC3) shoul
I cannot get the NSEC3 records through a BIND resolver if it is
version <= 9.5:
% dig +dnssec jhfgTCFGD564564.org
; <<>> DiG 9.5.1-P3 <<>> +dnssec @dnssec.generic-nic.net jhfgTCFGD564564.org
; (2 servers found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode:
In article ,
Fabian Gut wrote:
> Hello
>
> How does BIND handle multiple masters in a slave zone definition? I know
> that if one master doesn't answer, a second one is checked for new zone
> data, but does BIND periodically check ALL master servers for new data?
It checks them all. If any
Hello
How does BIND handle multiple masters in a slave zone definition? I know
that if one master doesn't answer, a second one is checked for new zone
data, but does BIND periodically check ALL master servers for new data?
Best regards
Fabian Gut
--
Fabian Gut
Trainee
open systems ag
raeffe
On 16.03.10 15:18, Jack Tavares wrote:
> What is the default build on linux (2.6) with regard to threads.
> If I don't explicitly enable or disable threads, does named
> run threaded or unthreaded?
from the manpage for named(8):
-n #cpus
Create #cpus worker threads to take advan
> In message <20100316131539.ga10...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > It's apparently because DNS was designed to provide records that exist,
> > not those that do not.
On 17.03.10 09:22, Mark Andrews wrote:
> Actually it's designed to provide records that exist *and* to tell yo
13 matches
Mail list logo
