Evan Hunt wrote:
>
> It is intentional; it spreads out the work of resigning over a longer
> period of time to reduce the load on the server. (And a lot of people
> prefer smaller IXFRs anyway.)
We have tweaked sig-signing-nodes and sig-signing-signatures to make
incremental signing work in large
liumingxing wrote:
> As we know, named Logging of all dynamic update transactions. In the
> update channel file, how I can know when the server receives update
> request?
Only at debug level 3, for example:
2015-09-01.11:25:55.851 client: debug 3: client 127.0.0.1#60986/key local-ddns:
view
I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
Both can resolve www.ietf.org
Only the 9.8.2 can resolve 0.centos.pool.ntp.org
I literally rsynced all the of the conf and zone files from the old to
the new, then changed all of the server name references. I have done
thi
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
John
On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz wrote:
> I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
>
> Both can resolve www.ietf.org
>
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this and I have some serious problems.
Part of my challenge is I am running the new server on an armv7 boa
Am 01.09.2015 um 15:31 schrieb Robert Moskowitz:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this and I have some serious problems.
Part of my challe
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote:
>
>
> On 09/01/2015 09:20 AM, John Miller wrote:
>>
>> If you check pcap, logs, etc., is the server's following delegation
>> for 0.centos.pool.ntp.org? Where do outbound packets stop?
>
>
> I don't believe this and I have some serious proble
Am 01.09.2015 um 16:28 schrieb John Miller:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe th
On Tue, Sep 1, 2015 at 10:38 AM, Reindl Harald
wrote:
>
> Am 01.09.2015 um 16:28 schrieb John Miller:
>
>> On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz
>> wrote:
>>
>>>
>>> On 09/01/2015 09:20 AM, John Miller wrote:
>>>
If you check pcap, logs, etc., is the server's following deleg
On 09/01/2015 09:36 AM, Reindl Harald wrote:
Am 01.09.2015 um 15:31 schrieb Robert Moskowitz:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this and
On 09/01/2015 10:28 AM, John Miller wrote:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believe this
On 09/01/2015 10:38 AM, Reindl Harald wrote:
Am 01.09.2015 um 16:28 schrieb John Miller:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz
wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where
On 01/09/15 17:46, Robert Moskowitz wrote:
>
> There will be a lot of arm IoT boxes in the next few years needing
> their time on boot. Of course booting will not be that frequent, but
> it will interesting to see how it plays out. And check devices like
> the esp8266, as $6 IoT device. It al
In article ,
Robert Moskowitz wrote:
> I will be looking more into this. Obvious when you get ones nose
> dragged into time wrong on boot. This is actually a broader problem on
> arm SoC booting. Your logs all have the wrong time for the boot
> messages until there is a network to get time
On 09/01/2015 12:16 PM, Sam Wilson wrote:
In article ,
Robert Moskowitz wrote:
I will be looking more into this. Obvious when you get ones nose
dragged into time wrong on boot. This is actually a broader problem on
arm SoC booting. Your logs all have the wrong time for the boot
messages
Hello,
I met a strange issue with adding a zone to BIND that I can't understand
for, :)
I have two nameservers, say they are:
ns1.example.com
ns2.example.com
There are dozens of zones resolved by these two.
But, the zone example.com itself is resolved by registrar's DNS servers.
For example
In message <55e64e21.8090...@runbox.com>, Ken Peng writes:
> Hello,
>
> I met a strange issue with adding a zone to BIND that I can't understand
> for, :)
>
> I have two nameservers, say they are:
>
> ns1.example.com
> ns2.example.com
>
> There are dozens of zones resolved by these two.
>
>
On 2015/9/2 星期三 9:34, Mark Andrews wrote:
* Did you read the logs on the servers and correct any errors reported?
Yes I watched the nameserver's log all the time when I did those.
They were nothing special happened.
* Did you check that they were actually serving the new zone?
I don't th
HI, FINCH,
In which level named log the receiving time and responding time of a update
request?
:)
Mingxing, Liu
email:liumingx...@cnnic.cn
tel:(010)58812467
From: Tony Finch
Date: 2015-09-01 18:34
To: liumingxing
CC: bind-users
Subject: Re: How does named log update request
liumingxing
19 matches
Mail list logo