On Sep 22, 2011, at 3:50 PM, TMK wrote:
On 9/21/2011 5:00 PM, TMK wrote:
>>> I have couple of questions.
>>>
>>> bind cache memory limit is 4GB. can I increase it. or this is hard-coded
>>> limit.
>>>
>>> i'm running the x64 bit version.
>> You can _try_ to raise that limit above 4Gb (see the va
2011/9/23 Kevin Darcy :
> On 9/21/2011 10:01 PM, Drunkard Zhang wrote:
>>>
>>> Why are you going through all of these gyrations? The forwarding
>>> algorithm
>>> in BIND has for a long time been based on RTT, so if one forwarder, or a
>>> set
>>> of forwarders, stops working, the other(s) will be u
On Sep 23, 2011, at 01:32 GMT+02:00, David Miller wrote:
>>> "2001:20a0:4000:300::123" would become "2001-20a0-4000-300-69".
>> The result should of course be "2001-20a0-4000-300-123" (-:
>>
>> Sorry for the confusion.
> ...or should the result be 2001-20a0-4000-0300----0123 ?
Ideally
Message original
Sujet: Re: A few (too) simple questions about DNS records
Date : Fri, 23 Sep 2011 00:57:58 +0200
De :Yanek
Pour : bind-users@lists.isc.org
>>
>>> 3/ What is the bind format for a DKIM record, eg:
>> RFC 4871, section 3.6.2.
> That's let's obvious, but
Le 21/09/2011 08:44, Stephane Bortzmeyer a écrit :
> On Wed, Sep 21, 2011 at 02:55:08AM +0200,
> Yanek wrote
> a message of 42 lines which said:
>
>> 1/ What is the bind record format for the zone itself?
> Strictly speaking, it is not the BIND format but the standard format
> (RFC 1035, sectio
> On 9/21/2011 5:00 PM, TMK wrote:
>> I have couple of questions.
>>
>> bind cache memory limit is 4GB. can I increase it. or this is hard-coded
>> limit.
>>
>> i'm running the x64 bit version.
> You can _try_ to raise that limit above 4Gb (see the various
> configuration elements under "Operating
On Sep 23, 2011, at 00:09 GMT+02:00, Joachim Tingvold wrote:
> "2001:20a0:4000:300::123" would become "2001-20a0-4000-300-69".
The result should of course be "2001-20a0-4000-300-123" (-:
Sorry for the confusion.
--
Joachim
___
Please visit https://lis
Hi,
Is there any equivialent to the following syntax, that works with IPv6 DDNS?
if exists host-name {
ddns-hostname = lcase(option host-name);
} else {
ddns-hostname = binary-to-ascii(10, 8, "-", leased-address);
}
If the hostname the client provided already exists, it shou
There was some correspondence last year about this warning message, but
this seems to be caused by something new.
Since 2011-09-02 we have been seeing messages like this
Sep 22 16:38:52 authdns1.csx.cam.ac.uk named[646]: dnssec: warning:
client 149.20.58.131#52557: expected covering NSEC3, got a
On 22/09/11 17:34, Keith Burgoyne wrote:
> Here's the named.conf file from my name server.
The meat of your configuration seems to be in the (hidden)
included files.
Forcing the source of your outgoing queries always to be
port 53 is a well-documented bad idea. Yo
On 9/22/2011 6:03 AM, Drunkard Zhang wrote:
Oops, I misunderstood. But I want to resolve this problem: take
news.qq.com for example, I DID saw that it's unresolvable to one group
(they returned NXDomain), at meantime it's no problem to another
group, and "dig news.qq.com +trace" returned correct
On 9/21/2011 10:01 PM, Drunkard Zhang wrote:
Why are you going through all of these gyrations? The forwarding algorithm
in BIND has for a long time been based on RTT, so if one forwarder, or a set
of forwarders, stops working, the other(s) will be used automatically. In
other words, forwarder fai
Here's the named.conf file from my name server. It's pretty basic, and
creates a view for internal use, and external. It hosts internal DNS for
local machines that's used on two internal networks, and external DNS
for our hosted domains, recursive lookups from our public IP block, etc.
// {{{
>> Oops, I misunderstood. But I want to resolve this problem: take
>> news.qq.com for example, I DID saw that it's unresolvable to one group
>> (they returned NXDomain), at meantime it's no problem to another
>> group, and "dig news.qq.com +trace" returned correct answer on both
>> group. It seems
> Is it possible to have one IP in multiple zone files for forward
> lookups?
On 21.09.11 15:23, Adamiec, Lawrence wrote:
What I am looking at doing is the following.
www.existingdomain.edu 86400 A 192.0.0.1
www.existingdomain.newdomain.edu 86400 A 192.0.0.1
just do it.
--
Matus UHLAR - fa
Why are you going through all of these gyrations? The forwarding algorithm
in BIND has for a long time been based on RTT, so if one forwarder, or a set
of forwarders, stops working, the other(s) will be used automatically. In
other words, forwarder failover works without any special configuration.
On 22/09/11 01:02, Keith Burgoyne wrote:
> Any advice would be massively appreciated.
The +trace operation which you say is failing for you
works from my network -- at home, where I have to use NAT.
It looks as if either your network or the nameserver you're
using
17 matches
Mail list logo
