Re: how to proper include DS record on key dnssec
Dnia 2011-01-14 03:11 fakessh @ napisał(a): >hello bind network and hello dnssec network admin. > > >thank you for answered, >I think I found a solution to my problem. >$INCLUDE directive is that I have to handle > > >example: > $INCLUDE /var/named/keys/dsset-fakessh.eu. fakessh.eu YOU don't do it. This goes into the PARENT zone. Unless you manage the parent zone as well, but even in that case it goes into a different file. >$INCLUDE /var/named/keys/keyset-fakessh.eu. fakessh.eu This is OK, although when you have an $INCLUDE and do dnssiec-signzone it automatically resolves it, so generated signed zone does not habe $INCLUDE >and perform a complete resignatures area zone >this should enable me to have the flag DS and DS sign, DLV and DLV sign Err, both the DS (as stated before) and DLV go into different zones. To sum up: DNSKEY goes to fakessh.eu DS goes to .eu, and I don't have any idea if registrars already permit it DLV goes to dlv.isc.net or any other dlv repository you want. That's three different zones, and three different signers. >in my area zone > >its right > >thanks for your return many return are welcome > > >Le jeudi 13 janvier 2011 à 12:36 -0500, Paul Wouters a écrit : >> On Thu, 13 Jan 2011, fakessh @ wrote: >> >> > I correctly configure my server centos dnssec on with as a >> > representative of encryptions dlv isc. my question is relevant and was >> > already asked but I have not found the complete answer on google. my >> > question is how to include the DS record in the Keys. my keys are in a >> > separate folder. the DS record is already generated in >> >> The DS record goes into the parent zone, not the zone itself. >> >> > I also wonder the utility of this good record given that my signatures >> > are marked as good on dlv >> >> Use any public DNS server with dlv configured. eg nssec.xelerance.net: >> >> dig +dnssec -t ds yourzone @nssec.xelerance.net >> >> > what file in the include directive must be accomplished and realize how >> > well inclusion of the DS record (what should be the proper syntax on how >> > to declare dlv isc) how to re-sign after the keys >> >> You give your DS via http://dlv.isc.org/ >> >> Paul >-- >gpg --keyserver pgp.mit.edu --recv-key 092164A7 >http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
2011/1/13 Alan Clegg :
> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>
>> I've executed
>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1"; };'
>>
>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>>
>> The question was: can I force rndc addzone to use specific file (for
>> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>
> No. The file is a hash of the view in which the data resides.
>
> "it's automated, just leave it alone and it won't hurt anyone" :)
>
> AlanC
Thank you very much, Alan. Could you describe why it was made so?
I asking because this feature could be very helpful for me, but such
restriction does its completely useless.
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
--
AP
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: how to proper include DS record on key dnssec
... > DNSKEY goes to fakessh.eu > DS goes to .eu, and I don't have any idea if registrars already permit it The .eu zone will accept the DS information (that is : registrar should inform us of the ksk or ksk's (plural)) Our system performs extra checks on DNSSEC information, trying to make sure that the introduction of DS information does not result in a broken chain-of-trust ! > DLV goes to dlv.isc.net or any other dlv repository you want. Is this still necessary ? Using DLV if the top-level-domain has full chain-of-trust ? > > That's three different zones, and three different signers. One observation though : All auth NS's have serial : 2011011301, but ns0.xname.org. and ns2.xname.org. (unofficial auth NS) have no RRSIG information ! (you might check if the DNS software on those name servers is capable of/configured for DNSSEC !) (if you are working with the registrar, You can also consult help pages on EURid.eu website, accessible to registrars only) Kind regards, Marc Lampo Security Officer EURid Woluwelaan 150 1831 Diegem - Belgium TEL.: +32 (0) 2 401 3030 MOB.:+32 (0)476 984 391 marc.la...@eurid.eu http://www.eurid.eu Want a .eu web address in your own language? Find out how so you dont miss out! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
On 14/01/11 9:57 AM, "Peter Andreev" wrote:
> 2011/1/13 Alan Clegg :
>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>
>>> I've executed
>>> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1"; };'
>>>
>>> and have got the file /etc/namedb/3bf305731dd26307.nzf:
>>> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>>>
>>> The question was: can I force rndc addzone to use specific file (for
>>> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>>
>> No. The file is a hash of the view in which the data resides.
>>
>> "it's automated, just leave it alone and it won't hurt anyone" :)
>>
>> AlanC
>
> Thank you very much, Alan. Could you describe why it was made so?
> I asking because this feature could be very helpful for me, but such
> restriction does its completely useless.
I believe it was related to the difference between legal file names and
legal view names. Thus to avoid problems, the view name is hashed.
I can't think of a situation where you would not know your view name and
that view name would change over time. So if you wish to edit the file in a
script, you can still do so, just use the hashed name. But there seems to be
a general preference not to change anything in that file by hand or script.
And the file naming scheme may change in future releases, if my change log
memory is correct.
However, I'm curious regarding your requirements and why this restriction
causes them to be broken? For myself I can think of some occasions:
1. Moving from secure to insecure (due to operational changes like transfers
between registrars).
2. ACL changes
Ideally there would be an "rndc editzone" with similar syntax to addzone.
Thus allowing you to update the zone statement without hand/script editing
the file. And protecting you from future file name changes.
>>
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
--
Kal Feher
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
2011/1/14 Kalman Feher :
>
>
>
> On 14/01/11 9:57 AM, "Peter Andreev" wrote:
>
>> 2011/1/13 Alan Clegg :
>>> On 1/13/2011 11:08 AM, Peter Andreev wrote:
>>>
I've executed
rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1";
};'
and have got the file /etc/namedb/3bf305731dd26307.nzf:
zone test.test { type master; file "/etc/namedb/master/test.1"; };
The question was: can I force rndc addzone to use specific file (for
example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
>>>
>>> No. The file is a hash of the view in which the data resides.
>>>
>>> "it's automated, just leave it alone and it won't hurt anyone" :)
>>>
>>> AlanC
>>
>> Thank you very much, Alan. Could you describe why it was made so?
>> I asking because this feature could be very helpful for me, but such
>> restriction does its completely useless.
> I believe it was related to the difference between legal file names and
> legal view names. Thus to avoid problems, the view name is hashed.
>
> I can't think of a situation where you would not know your view name and
> that view name would change over time. So if you wish to edit the file in a
> script, you can still do so, just use the hashed name. But there seems to be
> a general preference not to change anything in that file by hand or script.
> And the file naming scheme may change in future releases, if my change log
> memory is correct.
You haven't understood. I have several includes within one default
view and I need to add zones to them. Different zones to different
includes. For me name of view doesn't matter.
I believe that much more flexible and convenient way is to allow users
to specify file than such non-transparent mechanism which has been
realised.
And I don't like idea that bind user must have permissions to write to
namedb directory. For now without such permissions I get "permission
denied" error when trying to delete zone.
>
> However, I'm curious regarding your requirements and why this restriction
> causes them to be broken? For myself I can think of some occasions:
> 1. Moving from secure to insecure (due to operational changes like transfers
> between registrars).
> 2. ACL changes
>
> Ideally there would be an "rndc editzone" with similar syntax to addzone.
> Thus allowing you to update the zone statement without hand/script editing
> the file. And protecting you from future file name changes.
>>>
>>> ___
>>> bind-users mailing list
>>> bind-users@lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>
>>
>
> --
> Kal Feher
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
--
AP
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RT-Number?
I just read the release notes from Bind 9.7.2-P3 and noticed that behind every short description of a change there is a number beginning with RT. I hope this is some kind of ticket number were more detailed information about this change could be found? My question: Were do I find these tickets? (wouldn't make much sense to publish their numbers if the tickets themself couldn't be read, but I couldn't find them on the ISC homepage) -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
On 14/01/11 12:51 PM, "Peter Andreev" wrote:
> 2011/1/14 Kalman Feher :
>>
>>
>>
>> On 14/01/11 9:57 AM, "Peter Andreev" wrote:
>>
>>> 2011/1/13 Alan Clegg :
On 1/13/2011 11:08 AM, Peter Andreev wrote:
> I've executed
> rndc addzone test.test '{ type master; file "/etc/namedb/master/test.1";
> };'
>
> and have got the file /etc/namedb/3bf305731dd26307.nzf:
> zone test.test { type master; file "/etc/namedb/master/test.1"; };
>
> The question was: can I force rndc addzone to use specific file (for
> example "/etc/namedb/includes/file2") instead of 3bf305731dd26307.nzf?
No. The file is a hash of the view in which the data resides.
"it's automated, just leave it alone and it won't hurt anyone" :)
AlanC
>>>
>>> Thank you very much, Alan. Could you describe why it was made so?
>>> I asking because this feature could be very helpful for me, but such
>>> restriction does its completely useless.
>> I believe it was related to the difference between legal file names and
>> legal view names. Thus to avoid problems, the view name is hashed.
>>
>> I can't think of a situation where you would not know your view name and
>> that view name would change over time. So if you wish to edit the file in a
>> script, you can still do so, just use the hashed name. But there seems to be
>> a general preference not to change anything in that file by hand or script.
>> And the file naming scheme may change in future releases, if my change log
>> memory is correct.
>
> You haven't understood. I have several includes within one default
> view and I need to add zones to them. Different zones to different
> includes. For me name of view doesn't matter.
Bear in mind that includes make no sense in the context of rndc addzone
functionality. Since include functionality is only relevant when
parsing/reparsing the configuration file. Since the addzone feature bypasses
this to make adding zones not require parsing named.conf, it is circular to
use the include feature applicable to said parsing.
You can still use both methods to add a zone. Just not both to add the same
zone.
Consider why you use those includes, then reconsider those reasons in light
of the addzone function. Most people use includes to:
1.organise files and configs to keep them sane.
2.allow an external system to drop/ configs in a directory
without touching the main config file.
With rndc addzone:
1. Is somewhat improved and worsened. Your zone statements are together and
formatted neatly in a separate file. But comments are absent and zones are
all listed together, without any groupings you may find convenient.
2. The external system would now have to use rndc addzone/delzone to add and
remove the domain.
2.a Since the domain is now dynamic, editing the zone file is now replaced
with nsupdate. The caveat being that the zone statement itself is not
editable as far as I can see. At least not in a manner guaranteed to work in
future releases.
If using nsupdate to edit zone contents or adding domains using rndc, break
your current system or way of doing things, then the feature is not for you.
What were you hoping this feature would give you? Perhaps there is already a
way to achieve it without using the addzone feature..
> I believe that much more flexible and convenient way is to allow users
> to specify file than such non-transparent mechanism which has been
> realised.
>
> And I don't like idea that bind user must have permissions to write to
> namedb directory. For now without such permissions I get "permission
> denied" error when trying to delete zone.
>
>>
>> However, I'm curious regarding your requirements and why this restriction
>> causes them to be broken? For myself I can think of some occasions:
>> 1. Moving from secure to insecure (due to operational changes like transfers
>> between registrars).
>> 2. ACL changes
>>
>> Ideally there would be an "rndc editzone" with similar syntax to addzone.
>> Thus allowing you to update the zone statement without hand/script editing
>> the file. And protecting you from future file name changes.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
>>>
>>>
>>
>> --
>> Kal Feher
>>
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
--
Kal Feher
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
> You haven't understood. I have several includes within one default > view and I need to add zones to them. Different zones to different > includes. For me name of view doesn't matter. The zones added using "addzone" and removable using "delzone" aren't going to show up in your include files. They will be in the BIND created (and thus maintained) version. If you want to move your existing zones into "management" by BIND, you can create a zone using addzone (thus creating the crazy-named file), shut down BIND, move your zone definitions into the created file (removing them from their existing INCLUDED file) and then restart BIND. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RT-Number?
On 14/01/11 1:26 PM, "Tom Schmitt" wrote: > I just read the release notes from Bind 9.7.2-P3 and noticed that behind every > short description of a change there is a number beginning with RT. > I hope this is some kind of ticket number were more detailed information about > this change could be found? I think it stands for Request Tracker. ISC's internal tracking system. I recall there being a statement on the website somewhere that the information is not made public. I hope I'm wrong on this. > > My question: > Were do I find these tickets? > (wouldn't make much sense to publish their numbers if the tickets themself > couldn't be read, but I couldn't find them on the ISC homepage) Reposting this to the list, since I replied directly accidently. -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
Now I see, I really was mistaken about addzone. Kalman, Alan, thank you very much for explanation. I think, I won't break working things and continue with includes and scripts :) 2011/1/14 Alan Clegg : > >> You haven't understood. I have several includes within one default >> view and I need to add zones to them. Different zones to different >> includes. For me name of view doesn't matter. > > The zones added using "addzone" and removable using "delzone" aren't > going to show up in your include files. > > They will be in the BIND created (and thus maintained) version. > > If you want to move your existing zones into "management" by BIND, you > can create a zone using addzone (thus creating the crazy-named file), > shut down BIND, move your zone definitions into the created file > (removing them from their existing INCLUDED file) and then restart BIND. > > AlanC > > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- -- AP ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RT-Number?
> I recall there being a statement on the website somewhere that the > information is not made public. I hope I'm wrong on this. You're not wrong. People who submit bug reports sometimes include confidential information, so we'e kept the bug database for BIND 9 closed. This may change in the future; we've had some discussions of alternatives, but I don't expect anything to happen very soon. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
nsupdate to all servers
Hello, My bind servers are hosting with many zones, and many views. Due to the complication, I won't run the master/slave with TSIG keys for replication. I want to run nsupdate to all servers separately for the records update. Is this a good idea? Thanks Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate to all servers
p...@mail.nsbeta.info wrote: > > Hello, > My bind servers are hosting with many zones, and many views. > Due to the complication, I won't run the master/slave with TSIG keys > for replication. > I want to run nsupdate to all servers separately for the records update. > Is this a good idea? Thanks > Regards. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users nsupdate is a utility to make changes in a dynamic dns zone. It has nothing to do with replication of zone data from master to slave. One of the reason TSIG keys were created was to help with the replication of views. You have a complex setup and IMHO, you need to use the normal replication built into BIND using the TSIG keys to move around between views. Yes, it's complicated, but so is your setup. Just move forward in that direction slowly and carefully and IMHO, you will end up with a stable and well running system without any hacks to trip over later. Lyle Giese LCR Computer Services, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc addzone and file name
On 1/14/2011 4:06 PM, Timothe Litt wrote:
>>> You can use the 'named-checkconf -p' to create a fully "expanded"
>>> version of the running configuration file as needed for bug reports, etc.
>
> ?? Including zones added by "addzone"? How does checkconf find them?
Well, it _should_ find them the same way that BIND does when it starts.
I've just discovered that named-checkconf does not find them (for
either the -p or the -z options) and have opened a bugs ticket.
>>> Agreed. Removing and re-adding is a pain. This is something that is
> being looked at.
>
> It's not just a pain; it takes the zone offline for the duration. That's
> not acceptable in most environments.
Yep.
On the other hand, how often do you change the options in the "zone {};"
section? Nothing is stopping you from editing the .nzf file and
doing a reconfig (the "old way").
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
help with rndc fail
Hello gurus,
my rndc related commands in bind master with multi-views run fail,but in
slave it's running correctly.
# rndc status
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized, or
* the key is invalid.
Here is the named.conf for master.
Please help,thanks in advance.
-
options {
directory "/var/cache/bind";
recursion no;
};
# ACLs begin
include "/etc/bind/tel.acl";
include "/etc/bind/uni.acl";
include "/etc/bind/edu.acl";
# ACLs end
# views for ISP begin
view "uni" {
match-clients {
key "unikey";
UNI;
};
allow-update {key "unikey";};
allow-transfer { key "unikey"; };
server 202.104.186.180 { keys "unikey"; };
# zone begin uni
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.uni.db";
};
# zone end uni
};
view "edu" {
match-clients {
key "edukey";
EDU;
};
allow-update {key "edukey";};
allow-transfer { key "edukey"; };
server 202.104.186.180 { keys "edukey"; };
# zone begin edu
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.edu.db";
};
# zone end edu
};
view "tel" {
match-clients {
key "telkey";
any;
};
allow-update {key "telkey";};
allow-transfer { key "telkey"; };
server 202.104.186.180 { keys "telkey"; };
# zone begin tel
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.tel.db";
};
# zone end tel
};
# views for ISP end
# rndc key begin
key "rndc-key" {
algorithm hmac-md5;
secret "SUpgZRkpZVeteRiTIxQw6w==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# rndc key end
# customized keys begin
key "edukey" {
algorithm hmac-md5;
secret "***";
};
key "unikey" {
algorithm hmac-md5;
secret "***";
};
key "telkey" {
algorithm hmac-md5;
secret "***";
};
# customized keys end
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: help with rndc fail
And, the named version is:
# named -v
BIND 9.6.1-P2
I'm pretty sure the secret in both named.conf and rndc.conf are the same.
Thanks.
p...@mail.nsbeta.info writes:
Hello gurus,
my rndc related commands in bind master with multi-views run fail,but in
slave it's running correctly.
# rndc status
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized, or
* the key is invalid.
Here is the named.conf for master.
Please help,thanks in advance.
-
options {
directory "/var/cache/bind";
recursion no;
};
# ACLs begin
include "/etc/bind/tel.acl";
include "/etc/bind/uni.acl";
include "/etc/bind/edu.acl";
# ACLs end
# views for ISP begin
view "uni" {
match-clients {
key "unikey";
UNI;
};
allow-update {key "unikey";};
allow-transfer { key "unikey"; };
server 202.104.186.180 { keys "unikey"; };
# zone begin uni
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.uni.db";
};
# zone end uni
};
view "edu" {
match-clients {
key "edukey";
EDU;
};
allow-update {key "edukey";};
allow-transfer { key "edukey"; };
server 202.104.186.180 { keys "edukey"; };
# zone begin edu
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.edu.db";
};
# zone end edu
};
view "tel" {
match-clients {
key "telkey";
any;
};
allow-update {key "telkey";};
allow-transfer { key "telkey"; };
server 202.104.186.180 { keys "telkey"; };
# zone begin tel
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.tel.db";
};
# zone end tel
};
# views for ISP end
# rndc key begin
key "rndc-key" {
algorithm hmac-md5;
secret "SUpgZRkpZVeteRiTIxQw6w==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# rndc key end
# customized keys begin
key "edukey" {
algorithm hmac-md5;
secret "***";
};
key "unikey" {
algorithm hmac-md5;
secret "***";
};
key "telkey" {
algorithm hmac-md5;
secret "***";
};
# customized keys end
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: help with rndc fail
RNDC is only allowed from localhost, so the only place these would work would be from a command shell on the server that is the master. You did not specify where you were running rndc. I run it on master. Here is the -V output: # rndc -V status create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get default key get config key list decode base64 secret status post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect create message render message schedule recv send message rndc: recv failed: connection reset ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: help with rndc fail
RNDC is only allowed from localhost, so the only place these would work would be from a command shell on the server that is the master. You did not specify where you were running rndc. Hello, I'm running it in master. Here is the -V output: # rndc -V status create memory context create socket manager create task manager create task create logging context setting log tag creating log channel enabling log channel create parser get default key get config key list decode base64 secret status post event using server 127.0.0.1 (127.0.0.1#953) create socket bind socket connect create message render message schedule recv send message rndc: recv failed: connection reset ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
queryperf for stress test
run queryperf on the same server and got a not bad number at around 60,000 qps, however, the cpu and memory are far from used up, what else could be the limiting factors for getting higher qps numbers? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: queryperf for stress test
ju wusuo writes: run queryperf on the same server and got a not bad number at around 60,000 qps, however, the cpu and memory are far from used up, what else could be the limiting factors for getting higher qps numbers? rebuild bind and enable the threads? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: help with rndc fail
I don't know what's the problem.
Just copied the config files to another host and run bind master on it,
everything works fine, including the zone transfer for multi-views.
Thanks.
p...@mail.nsbeta.info writes:
And, the named version is:
# named -v
BIND 9.6.1-P2
I'm pretty sure the secret in both named.conf and rndc.conf are the same.
Thanks.
p...@mail.nsbeta.info writes:
Hello gurus,
my rndc related commands in bind master with multi-views run fail,but in
slave it's running correctly.
# rndc status
rndc: connection to remote host closed
This may indicate that
* the remote server is using an older version of the command protocol,
* this host is not authorized to connect,
* the clocks are not synchronized, or
* the key is invalid.
Here is the named.conf for master.
Please help,thanks in advance.
-
options {
directory "/var/cache/bind";
recursion no;
};
# ACLs begin
include "/etc/bind/tel.acl";
include "/etc/bind/uni.acl";
include "/etc/bind/edu.acl";
# ACLs end
# views for ISP begin
view "uni" {
match-clients {
key "unikey";
UNI;
};
allow-update {key "unikey";};
allow-transfer { key "unikey"; };
server 202.104.186.180 { keys "unikey"; };
# zone begin uni
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.uni.db";
};
# zone end uni
};
view "edu" {
match-clients {
key "edukey";
EDU;
};
allow-update {key "edukey";};
allow-transfer { key "edukey"; };
server 202.104.186.180 { keys "edukey"; };
# zone begin edu
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.edu.db";
};
# zone end edu
};
view "tel" {
match-clients {
key "telkey";
any;
};
allow-update {key "telkey";};
allow-transfer { key "telkey"; };
server 202.104.186.180 { keys "telkey"; };
# zone begin tel
zone "test.nsbeta.info" {
type master;
file "test.nsbeta.info.tel.db";
};
# zone end tel
};
# views for ISP end
# rndc key begin
key "rndc-key" {
algorithm hmac-md5;
secret "SUpgZRkpZVeteRiTIxQw6w==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# rndc key end
# customized keys begin
key "edukey" {
algorithm hmac-md5;
secret "***";
};
key "unikey" {
algorithm hmac-md5;
secret "***";
};
key "telkey" {
algorithm hmac-md5;
secret "***";
};
# customized keys end
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
