On Thu, Jan 22, 2015 at 03:25:38PM +0800, Jackie Lui wrote:
> I have installed bind 9.10.1 and enable GeoIP features. This works fine
> except the EDNS feature.
>
> When I dig Google DNS server with +subnet parameter, Google DNS server can
> respond the CLIENT-SUBNET value. However, when I dig my
I have installed bind 9.10.1 and enable GeoIP features. This works fine
except the EDNS feature.
When I dig Google DNS server with +subnet parameter, Google DNS server can
respond the CLIENT-SUBNET value. However, when I dig my DNS server, it
can't show the CLIENT-SUBNET value. It seems that my se
In message <00b101d035f0$ff0d76c0$fd286440$@aliyun.com>, "RunxiaWan" writes:
>
> Hi everyone,
> I am writing to ask if bind support long lived tcp connection which can be
> reused by multiple transactions?
Named has always supported multiple queries over TCP sockets.
Mark
--
Mark Andrews, ISC
Hi everyone,
I am writing to ask if bind support long lived tcp connection which can be
reused by multiple transactions?
---
Runxia Wan(Brian)
Research Engineer
BII Lab
Beijing Internet Institute(BII)
rx...@biigroup.cn
___
Please vi
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
Yes, an IXFR is a series of deletes and adds, which both quote whole records.
If you re-sign a zone the IXFR can be nearly twice what an AXFR would be! But
in fact the factor of two in my patch comes from the journal compaction logic,
which halves the size of the journal. So my patch allows the
I like that solution.
I assume that "twice the zone file size" is because half of the entries are
deletes? Do deletes get sent in IXFR? Or is it that typically half of the
journal entries are SOA records?
I just took a peek at my journal files and I see one that is 100 times the
zone file size.
I got annoyed by having to manually tune max-journal-size so I had a hack
at the problem:
https://git.csx.cam.ac.uk/x/ucs/ipreg/bind9.git/commitdiff/c8f083b797f9810f
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Viking: Southeast, veering south or southwest later, 4 or 5, increasing 6 at
times.
Oh, well that's good to know. :)
-Christopher
On 1/21/15, 12:18 PM, "Chris Thompson" wrote:
>On Jan 21 2015, Howard, Christopher wrote:
>
>>The journal files get flushed to the zone file periodically, but old
>>transactions don't get removed so the journal file will continue to grow
>>forever
On Jan 21 2015, Howard, Christopher wrote:
The journal files get flushed to the zone file periodically, but old
transactions don't get removed so the journal file will continue to grow
forever. If you're like me and on virtual machines with limited hard disk
capacity, you can limit the journal
The journal files get flushed to the zone file periodically, but old
transactions don't get removed so the journal file will continue to grow
forever. If you're like me and on virtual machines with limited hard disk
capacity, you can limit the journal file size with the max-journal-size
configurat
On 21/01/15 15:46, eric.berthiaume.exter...@banque-france.fr wrote:
So it it does seem to be rolling the changes but jnl files still
persist. It’s not terribly bothering but I would like to know if this
is the normal behavior.
It's normal. The .jnl files contain the data required to perform
Hello bind-users,
Tried to find the info on my own but couldn’t get accurate understanding of jnl
files flushing mechanism.
Bind-9.10.0-02.P2
RHEL 5.7
Master DNS server, Chrooted env, receiving updates via nsupdate.
Maybe I didn’t catch the memo but I thought the standard way bind handled the
13 matches
Mail list logo
