On Tue, Dec 30, 2008 at 08:28:06PM -0800, Paul B. Henson wrote:
> On Tue, 30 Dec 2008, [iso-2022-jp] JINMEI Tatuya / � wrote:
>
> > So, you at least need to fix one on-memory zone image that can be
> > dynamically updated. You'll then have to configure the other view where
> > the "shared"
On Jan 5 2009, John Wobus wrote:
[...] There is no nameserver operation
that dig could do to tell a caching nameserver to act differently
for one query. You could clear the nameserver's cache, or even
clear the one name you are interested in out of the cache.
I'm trying to install bind 9.5.1 on redhat as 4.5, but am having problems
with the configure statement:
STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure
--prefix=/home/named --enable-epoll --disable-threads --enable-largefile
--disable-ipv6 --with-openssl=yes CFLAGS='-static -march=penti
On Fri, 02 Jan 2009 16:16:35 -0800, wes wrote:
> --===3579383764054783402== Content-Type:
> multipart/alternative;
> boundary="=_Part_21674_19533272.1230941795123"
>
> --=_Part_21674_19533272.1230941795123 Content-Type: text/plain;
> charset=ISO-8859-1 Content-Transfer-E
bind user wrote:
Hi All: I installed 9.6.0 alongside FreeBSD7's default 9.4.2, and it's
working fine when i start it manually, but I'm having trouble getting it
to start automatically. I edited etc/rc.d/named
Don't do that. :) The rc.d system is designed to be configured with
rc.conf. You pro
I'm trying to install bind 9.5.1 on redhat as 4.5, but i am having problems
with the configure statement:
STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure
--prefix=/home/named --enable-epoll --disable-threads --enable-largefile
--disable-ipv6 --with-openssl=yes CFLAGS='-static -march=pen
On Mon, 05 Jan 2009 16:24:04 +, Chris Thompson wrote:
> On Jan 5 2009, John Wobus wrote:
>
>>[...] There is no nameserver
>>operation
>>that dig could do to tell a caching nameserver to act differently for
>>one query. Y
On Jan 3, 6:28 pm, Jonathan Petersson wrote:
> Thanks for your input
>
> /Jonathan
>
> On Jan 3, 2009, at 16:13, Mark Andrews wrote:
>
>
>
>
>
> > In message
> > ,
> > "Jonathan Petersson"
> > writes:
> >> Hi all,
>
> >> Hopefully this post wont cause as much SPAM as my last one. About a
> >> yea
I'm imagining you want a way to make dig act like the caching
nameserver and do what it would do and show you the answer.
dig +trace does something similar to this. There is no nameserver
operation
that dig could do to tell a caching nameserver to act differently
for one query. You could clear
I've been doing some testing lately on query times. What I did was
create a new zone and create a * record within it. Then, from a shell,
I do "dig @server $RANDOM.test.testdomain.com". For more randomness,
you can combine: "dig @server $RANDOM.$RANDOM.test.testdomain.com"
That's how I've wor
I've setup a secondary name server which works as a secondary or slave
name server for my zone or domain name. However, I have tested and
noticed that I can query for non-authoritative answers from my
secondary or slave name server from outside my network. That is, any
one can use my name server to
On 05.01.09 15:29, Chris Henderson wrote:
> I'm trying to implement some basic counter-measures against the
> Kaminsky bug. I have had to configure my switch to allow any incoming
> query to TCP and UDP port 53 on my slave DNS server. I was wondering
> if this is going to cause any problem as far a
On Mon, 5 Jan 2009, Stephen Ward wrote:
> On Mon, 05 Jan 2009 16:24:04 +, Chris Thompson wrote:
>
> > On Jan 5 2009, John Wobus wrote:
> >
> >>[...] There is no nameserver
> >>operation
> >>that dig could do to tell a ca
Running an awk or perl script along with checkzones should be able
to do this site-specific check (and others you might find helpful)
quite easily.
On Dec 30, 2008, at 7:51 PM, Mark Andrews wrote:
In message
<7227c6c70812300937s7a4be464h16db91c6ead84...@mail.gmail.com>, "Mike
Zupan" write
In general I would think that it isn't recommended unless it's
intended, you probably don't want random client querying your servers
for content you don't control.
To kill this add "recursion no;" in options, if you do want this
enables for certain prefixes have a look at "allow-recursion".
Good
I already tried ms-self and ms-subdomain. Unfortunately that doesn't
seem to make any difference.
Nico
On Tue, 2008-12-30 at 13:44 -0500, Rob Austein wrote:
> At Tue, 30 Dec 2008 16:05:10 +0100, Nico De Ranter wrote:
> >
> > update-policy {
> > grant TEST.NET krb
bind user wrote:
> Thanks for that detailed explanation, Doug...after years of running
> Unix/Bind blind (because it just worked), I'm finally understanding why
> things are the way they are. -AK
You're welcome, and I'll take the latter as a compliment. I try very
hard to make things "just work" f
At Thu, 01 Jan 2009 00:04:49 -0500,
Danny Mayer wrote:
> Personally, I'm not convinced that it will make a difference outside of
> Windows. The fix is to make sure a lock gets destroyed when done and the
> function exits. On Windows the lock gets created and memory is allocated
> for it outside o
At Thu, 1 Jan 2009 00:47:10 -0500,
Vinny Abello wrote:
> I just loaded up the BIND 9.5.1 port on FreeBSD 7.0 AMD64 with
> threads. I don't see the prominent memory leak present on my system
> any longer. I lost track of this thread and think two different
> changes might have been made, however.
At Thu, 1 Jan 2009 12:23:02 +0100,
Michelle Konzack wrote:
> Q 1:Which setting is missing?
>
> Q2: Can someone tell me how to update a TXT record?
Please show named.conf of the authoritative server (the one accepting
dynamic updates). It's also helpful to debug it to show log messages
At Mon, 5 Jan 2009 18:58:07 -0500,
Vinny Abello wrote:
> My basic question is: Is there any advantage to compiling BIND in
> the previous manner now that there is a fix in the BIND source code?
Do you mean compiling BIND with the memory leak fix and without the
FreeBSD port change by "in the pre
At Mon, 5 Jan 2009 19:52:54 +0800,
mingdawang wrote:
>
> [1.1 ]
> I'm trying to install bind 9.5.1 on redhat as 4.5, but am having problems
> with the configure statement:
>
> STD_CDEFINES='-DISC_MEM_USE_INTERNAL_MALLOC=1' ./configure
> --prefix=/home/named --enable-epoll --disable-threads --en
Doug Barton wrote:
> Vinny Abello wrote:
>> Just for clarification, is there any downside to this autoconf fix
>> vs. how it was previously working?
>
> It was not working correctly previously, so no.
>
>> Does autoconf still not understand AMD64 on FreeBSD
>
> You're confusing "autoconf" and "
23 matches
Mail list logo