Ok, but still RIPE domain object is just an informational record? I
mean DNS servers don't use RIPE domain object data, do they? So
basically nothing happens if I don't create(or update) domain object
in RIPE database when I delegate a zone file..
Martin
KuupƤeval 20. detsember 2011 19:37 kirjut
We believe this patch will fix this issue. It has been committed to be
released as part of BIND 9.9.1.
Mark
diff --git a/bin/named/client.c b/bin/named/client.c
index 2f4130c..ae13795 100644
--- a/bin/named/client.c
+++ b/bin/named/client.c
@@ -240,7 +240,7 @@ ns_client_recursing(ns_client_t *c
On Tue, Mar 13, 2012 at 9:33 AM, hugo hugoo wrote:
> Thanks for this interesting feedback.
> Now I have the problem to detect this kind of bad configuration.
>
> If I have:
>
> Zone toto.be:
>
> toto.be.
>
> NS ns1.xxx.be
>
> + some records
>
>
> Zone titi.toto.be:
>
>
> titi.to
On 14/03/12 10:11, Eivind Olsen wrote:
>> In BIND 9.9.0(CentOS 4.6)
>>
>> Mar 9 06:58:51 X named[17533]: general: critical: client.c:318:
>> INSIST(client->newstate <= 3) failed, back trace
Zitat von Romgo :
All right.
this seems to correct the issue.
But that's the first time I had to open the firewall for a packet answer.
weird.
It is a somewhat special case. UDP by itself is not stateful at all so
any stateful firewall have to use some timeout values to decide if the
"co
> In BIND 9.9.0(CentOS 4.6)
>
> Mar 9 06:58:51 X named[17533]: general: critical: client.c:318:
> INSIST(client->newstate <= 3) failed, back trace
This looks like a crash I just had here,
On 13/03/12 20:46, Mark Andrews wrote:
>
> In message , Daniel McDonald
> writ
> es:
>>
>> On 3/13/12 8:20 AM, "hugo hugoo" wrote:
>>
>>> ==> do I have to create in zone "toto.be" the following NS record:
>>>
>>> titi.toto.be. TTL IN NSns1.xxx.be
>>>
>>>
>>> I ha
7 matches
Mail list logo