Re: rndc-key has expired
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
and I am therefore blocks
any update is welcome
Le mercredi 23 mars 2011 à 02:30 +0100, fakessh @ a écrit :
I changed options
update-policy {
grant fakessh.eu. name fakessh.eu. A TXT;
};
since
update-policy {
grant * self * A TXT;
};
Le mardi 22 mars 2011 à 14:59 +0100, fakessh @ a écrit :
hi bind guru
It appears after the log that my signature rndc-key has expired. how to
update it
___
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
--
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7
signature.asc
Description: Ceci est une partie de message numériquement signée
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
Which script? What exactly does it say?
I'm guessing you might have enabled dynamic updates in a DNSSEC signed
zone, without BIND having access to the private keys needed to sign, but
that's a wild guess really.
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Reverse dns issue
Hi, I'm using a software which uses bind and I'm experiencing a problem with the reverse dns function of bind. I only have private adresses on my network but the nodes also have dns names. There is a server on this network, which is also a name server, that has internet through a gateway. When my nodes are doing a dns query to the server, eveything is ok and they get their corresponding (private) IP address. The problem occurs when a node is sending a reverse dns query to the server. The server should return the name that matches the IP address but instead I have this error in the bind log 21-Mar-2011 14:53:44.389 security: warning: client 10.100.2.129#61940: view internal: RFC 1918 response from Internet for 5.2.100.10.in- addr.arpa In this case 10.100.2.5 (or 5.2.100.10) is the server itself so it should able to get his own name This response from Internet seems weird to me because it should not ask an internet name server since it is private address. I checked with tcpdump and I didn't see any dns query going out of the server so it's not doing recursive lookups Anyone can help with this? Does bind have a special option for private addresses? I've seen that there is a reverse folder in /etc/namedb with files names like this 10.0.252.db, are these files used for the reverse dns resolution? I tried to add a file for the subnetwork I use (10.100.2) but this didn't change anything Here is a tcpdump of the communication between the node and the server showing the failing query 10:42:35.494523 IP 10.100.2.129.60331 boss.vlan100.domain: 42377+ PTR? 5.2.100.10.in-addr.arpa. (41) 10:42:35.494691 IP boss.vlan100.domain 10.100.2.129.60331: 42377 NXDomain 0/1/0 (118) 10:42:35.495019 IP 10.100.2.129.54934 boss.vlan100.domain: 42378+ A? UNKNOWN.vlan100. (33) 10:42:35.495090 IP boss.vlan100.domain 10.100.2.129.54934: 42378 NXDomain* 0/1/0 (86) 10:42:35.495416 IP 10.100.2.129.64666 boss.vlan100.domain: 42379+ A? UNKNOWN. (25) 10:42:35.495469 IP boss.vlan100.domain 10.100.2.129.64666: 42379 NXDomain 0/1/0 (100) Thanks in advance ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
I use and bind rndc and dlv isc for dnssec
my zone config like this
zone renelacroute.fr {
type master;
file /var/named/renelacroute.fr.hosts;
auto-dnssec maintain;
update-policy local;
key-directory /var/named/keys/;
allow-transfer { 213.251.*.*;87.98.*.*; 195.234.*.*;94.23.*.\
*; 193.223.*.*; };
};
and my log dnssec it is
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:18.244 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
I can not use the script to validate the answers (for dnssec ) I isc
SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
5.814:INFO Total answers: 3
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232
5.816:SUCCESS All DNSKEY responses are identical.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=62721 flags=256 alg=RSASHA1
AwEAAb20...UzDMzFplHk=
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=48793 flags=257 alg=RSASHA1
AwEAAbj7...WFfCkn7o38=
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
5.822:INFO VERIFY-DNSKEY: 0 keys found after filtering.
5.822:DEBUG VERIFY-DNSKEY: Using keys:
5.822:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
5.822:FAILURE VERIFY-DNSKEY: No keys found after filtering.
5.822:FAILURE DNSKEY signature did not validate.
5.822:FINAL_FAILURE FAILURE
Le mercredi 23 mars 2011 à 09:29 +0100, Eivind Olsen a écrit :
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
Which script? What exactly does it say?
I'm guessing you might have enabled dynamic updates in a DNSSEC signed
zone, without BIND having access to the private keys needed to sign, but
that's a wild guess really.
Regards
Eivind Olsen
--
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7
signature.asc
Description: Ceci est une partie de message numériquement signée
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: openssl pkcs#11 engine patch
Hi Emil, For me, I had the same problem. I'm running RHEL5, openssl-0.9.8l with the ISC patch and integrating with the AEP Keyper PKCS#11 lib. After applying the ISC patch, I found that this worked for me: # ./Configure linux-elf -m32 -pthread --pk11-libname=/opt/Keyper/PKCS11Provider/pkcs11.so --pk11-flavor=sign-only --prefix=/opt/pkcs11/usr # make # ./apps/openssl engine pkcs11 (pkcs11) PKCS #11 engine support (sign only) Regards Billy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
hi isc
hi list
hi guru of bind
errors continue to recur rndc-key expired
But I apply the command for create the key
dnssec-keygen -a HMAC-MD5 -b 512 -n HOST rndc-key
Le mercredi 23 mars 2011 à 16:24 +0100, fakessh @ a écrit :
I use and bind rndc and dlv isc for dnssec
my zone config like this
zone renelacroute.fr {
type master;
file /var/named/renelacroute.fr.hosts;
auto-dnssec maintain;
update-policy local;
key-directory /var/named/keys/;
allow-transfer { 213.251.*.*;87.98.*.*; 195.234.*.*;94.23.*.\
*; 193.223.*.*; };
};
and my log dnssec it is
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:18.244 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
I can not use the script to validate the answers (for dnssec ) I isc
SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
5.814:INFO Total answers: 3
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232
5.816:SUCCESS All DNSKEY responses are identical.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=62721 flags=256 alg=RSASHA1
AwEAAb20...UzDMzFplHk=
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=48793 flags=257 alg=RSASHA1
AwEAAbj7...WFfCkn7o38=
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
5.822:INFO VERIFY-DNSKEY: 0 keys found after filtering.
5.822:DEBUG VERIFY-DNSKEY: Using keys:
5.822:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
5.822:FAILURE VERIFY-DNSKEY: No keys found after filtering.
5.822:FAILURE DNSKEY signature did not validate.
5.822:FINAL_FAILURE FAILURE
Le mercredi 23 mars 2011 à 09:29 +0100, Eivind Olsen a écrit :
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
Which script? What exactly does it say?
I'm guessing you might have enabled dynamic updates in a DNSSEC signed
zone, without BIND having access to the private keys needed to sign, but
that's a wild guess really.
Regards
Eivind Olsen
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7
signature.asc
Description: Ceci est une partie de message numériquement signée
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
What is this??? To: fakessh @ fake...@fakessh.eu On Tue, Mar 22, 2011 at 02:59:22PM +0100, fakessh @ wrote: hi bind guru It appears after the log that my signature rndc-key has expired. how to update it -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 Are you running 'rndc' from the same server on which the 'named' is running? If not, make sure that both have the same time. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
hi guru I'm walking on the same server rndc and named Le mercredi 23 mars 2011 à 14:46 -0400, Joseph S D Yao a écrit : What is this??? To: fakessh @ fake...@fakessh.eu On Tue, Mar 22, 2011 at 02:59:22PM +0100, fakessh @ wrote: hi bind guru It appears after the log that my signature rndc-key has expired. how to update it -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 Are you running 'rndc' from the same server on which the 'named' is running? If not, make sure that both have the same time. -- /*\ ** ** Joe Yaoj...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
I can wait how long before this ends? Le mercredi 23 mars 2011 à 14:46 -0400, Joseph S D Yao a écrit : What is this??? To: fakessh @ fake...@fakessh.eu On Tue, Mar 22, 2011 at 02:59:22PM +0100, fakessh @ wrote: hi bind guru It appears after the log that my signature rndc-key has expired. how to update it -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 Are you running 'rndc' from the same server on which the 'named' is running? If not, make sure that both have the same time. -- /*\ ** ** Joe Yaoj...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- gpg --keyserver pgp.mit.edu --recv-key 092164A7 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x092164A7 signature.asc Description: Ceci est une partie de message numériquement signée ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse dns issue
In message 4d8a0386.3080...@laas.fr, Olivier Destras writes: Hi, I'm using a software which uses bind and I'm experiencing a problem with the reverse dns function of bind. I only have private adresses on my network but the nodes also have dns names. There is a server on this network, which is also a name server, that has internet through a gateway. When my nodes are doing a dns query to the server, eveything is ok and they get their corresponding (private) IP address. The problem occurs when a node is sending a reverse dns query to the server. The server should return the name that matches the IP address but instead I have this error in the bind log 21-Mar-2011 14:53:44.389 security: warning: client 10.100.2.129#61940: view internal: RFC 1918 response from Internet for 5.2.100.10.in- addr.arpa In this case 10.100.2.5 (or 5.2.100.10) is the server itself so it should able to get his own name Only if you have configured the reverse zone. You need to configure a zone with a 5.2.100.10.in-addr.arpa. PTR name. record. e.g. 10.in-addr.arpa. 5.2.100 PTR name. or 100.10.in-addr.arpa. 5.2 PTR name. or 2.100.10.in-addr.arpa. 5 PTR name. or 5.2.100.10.in-addr.arpa. @ PTR name. This response from Internet seems weird to me because it should not ask an internet name server since it is private address. I checked with tcpdump and I didn't see any dns query going out of the server so it's not doing recursive lookups Did you clear the cache before checking? Anyone can help with this? Does bind have a special option for private addresses? No. Named knows what the public servers for 10.in-addr.arpa return in the SOA record and warns if it see those values. 10.in-addr.arpa.10800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800 I've seen that there is a reverse folder in /etc/namedb with files names like this 10.0.252.db, are these files used for the reverse dns resolution? I tried to add a file for the subnetwork I use (10.100.2) but this didn't change anything Here is a tcpdump of the communication between the node and the server showing the failing query 10:42:35.494523 IP 10.100.2.129.60331 boss.vlan100.domain: 42377+ PTR? 5.2.100.10.in-addr.arpa. (41) 10:42:35.494691 IP boss.vlan100.domain 10.100.2.129.60331: 42377 NXDomain 0/1/0 (118) 10:42:35.495019 IP 10.100.2.129.54934 boss.vlan100.domain: 42378+ A? UNKNOWN.vlan100. (33) 10:42:35.495090 IP boss.vlan100.domain 10.100.2.129.54934: 42378 NXDomain* 0/1/0 (86) 10:42:35.495416 IP 10.100.2.129.64666 boss.vlan100.domain: 42379+ A? UNKNOWN. (25) 10:42:35.495469 IP boss.vlan100.domain 10.100.2.129.64666: 42379 NXDomain 0/1/0 (100) Thanks in advance ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Q on clients-per-query, max-clients-per-query
Hello, # The ARM says: # clients-per-query, max-clients-per-query These set the initial value (minimum) and maximum number of recursive simultaneous clients for any given query (qname,qtype,qclass) that the server will accept before dropping additional clients. named will attempt to self tune this value and changes will be logged. The default values are 10 and 100. If clients-per-query is set to zero, then there is no limit on the number of clients per query and no queries will be dropped. If max-clients-per-query is set to zero, then there is no upper bound other than imposed by recursive-clients. # Consider that I have: # clients-per-query 10 ; max-clients-per-query 20 ; # What I think this means in hypothetical situations: # 1. If I have 100 customer Windows machines requesting A record(s) for non-responsive-domain.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the likely process? 2. If I have 100 customer Windows machines requesting A record(s) for very-slow-to-respond.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the likely process? Let's say the name servers authoritative for this domain finally respond, then my bind server will respond to the 20 queries. Is this correct, or what is the likely process? Now that I have the A record for www.very-slow-to-respond.com in cache (say TTL is 24h) and it is likely that the 80 unsatisfied customer Windows machines will make another query attempt and, because I have this cached, finally get a response. Is this correct, or what is the likely process? It won't hurt my feeling if someone rather provide a better example that may demonstrate how these settings work. Thank you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rndc-key has expired
In message 1300893881.12273.67.camel@localhost.localdomain, fakessh @ write
s:
I use and bind rndc and dlv isc for dnssec=20
my zone config like this
zone renelacroute.fr {
type master;
file /var/named/renelacroute.fr.hosts;
auto-dnssec maintain;
update-policy local;
key-directory /var/named/keys/;
allow-transfer { 213.251.*.*;87.98.*.*; 195.234.*.*;94.23.*.\
*; 193.223.*.*; };
};
and my log dnssec it is
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:17.701 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
23-Mar-2011 16:18:18.244 dnssec: debug 2: tsig key 'rndc-key': signature
has expired
I can not use the script to validate the answers (for dnssec ) I isc
RNDC, TSIG and DNSSEC are *different* things.
TSIG is a transaction signature and by default it is valid for 5
minutes (tsig.fudge) from when it is computed. TSIG can be used
on zone transfers and to secure individual DNS transactions. The
format of TSIG log messages is tsig key '%s': %s and tsig key
'%s' (%s): %s. TSIG uses HMAC with private keys or it can use
public key cyptograhy similar to DNSSEC.
The DNS server and client being out of time sync can generate the
above messages. A slow TSIG signed zone transfer can also generate
the messages above even when the server and client are in sync if
it takes more than 5 minutes to send the signed messages in the
axfr/ixfr stream to the client.
RNDC, uses HMAC (private keys). It shares hmac keys with TSIG but
passes the expiry values differently. The format of its log messages
is invalid command from %s: %s
The above messages are not rndc related.
DNSSEC uses RRSIGs and they are valid for 30 days by default. DNSSEC
secures records in the transaction, not the transaction itself. You
have a secure transaction if all the components of the transaction are
secure and otherwise sensible.
The above messages are not DNSSEC related. The message below are
DNSSEC related.
Mark
SUCCESS 94.23.59.30 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.164.164 answered DNSKEY query with rcode NOERROR
5.814:SUCCESS 87.98.186.232 answered DNSKEY query with rcode NOERROR
5.814:INFO Total answers: 3
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.164.164
5.815:DEBUG COMPARE: Comparing results from 94.23.59.30 to 87.98.186.232
5.816:SUCCESS All DNSKEY responses are identical.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D62721 flags=3D256 alg=3DRSASHA1
AwEAAb20...UzDMzFplHk=3D
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:DEBUG VERIFY-DNSKEY: Checking tag=3D48793 flags=3D257 alg=3DRSASHA1
AwEAAbj7...WFfCkn7o38=3D
5.822:DEBUG VERIFY-DNSKEY: Ignoring key.
5.822:INFO VERIFY-DNSKEY: 2 DNSKEYs found.
5.822:INFO VERIFY-DNSKEY: 0 keys found after filtering.
5.822:DEBUG VERIFY-DNSKEY: Using keys:
5.822:DEBUG VERIFY-DNSKEY: To verify rrset type DNSKEY
5.822:FAILURE VERIFY-DNSKEY: No keys found after filtering.
5.822:FAILURE DNSKEY signature did not validate.
5.822:FINAL_FAILURE FAILURE
Le mercredi 23 mars 2011 =C3=A0 09:29 +0100, Eivind Olsen a =C3=A9crit :
I edit the file named.conf
modification
update-policy {
grant * self * A TXT;
};
to update-policy local;
it seems more logical.
but I'm still stuck on the validation of isc dlv. the script tells me
lost keys
=20
Which script? What exactly does it say?
=20
I'm guessing you might have enabled dynamic updates in a DNSSEC signed
zone, without BIND having access to the private keys needed to sign, but
that's a wild guess really.
=20
Regards
Eivind Olsen
=20
=20
--=20
gpg --keyserver pgp.mit.edu --recv-key 092164A7
http://pgp.mit.edu:11371/pks/lookup?op=3Dgetsearch=3D0x092164A7
--=-nHmVHAZDpObhKURw8YiG
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
=?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQBNihC5tXI/OwkhZKcRAq2dAJ0SsEztSh/rgrKCYyo3JerXzjsOxgCggvQv
5jISvLMReyxov6dURql1lw0=
=e9RP
-END PGP SIGNATURE-
--=-nHmVHAZDpObhKURw8YiG--
--===8954482665668778810==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--===8954482665668778810==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Q on clients-per-query, max-clients-per-query
In message 60834.75625...@web121403.mail.ne1.yahoo.com, Fr34k writes: Hello, # The ARM says: # clients-per-query, max-clients-per-query These set the initial value (minimum) and maximum number of recursive simultaneous clients for any given query (qname,qtype,qclass) that the serv er will accept before dropping additional clients. named will attempt to self tu ne this value and changes will be logged. The default values are 10 and 100. If clients-per-query is set to zero, then there is no limit on the number of clients per query and no queries will be dropped. If max-clients-per-query i s set to zero, then there is no upper bound other than imposed by recursive-clients. # Consider that I have: # clients-per-query 10 ; max-clients-per-query 20 ; # What I think this means in hypothetical situations: # 1. If I have 100 customer Windows machines requesting A record(s) for non-responsive-domain.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? 2. If I have 100 customer Windows machines requesting A record(s) for very-slow-to-respond.com, then my caching server will only recurs the first 20 of such requests and drop the other 80. Is this correct, or what is the like ly process? Let's say the name servers authoritative for this domain finally respond, the n my bind server will respond to the 20 queries. Is this correct, or what is the likely process? Now that I have the A record for www.very-slow-to-respond.com in cache (say T TL is 24h) and it is likely that the 80 unsatisfied customer Windows machines wi ll make another query attempt and, because I have this cached, finally get a response. Is this correct, or what is the likely process? It won't hurt my feeling if someone rather provide a better example that may demonstrate how these settings work. You have a empty cache. You get a query for google.com. You send a query to the root servers for google.com. Another query for google.com comes in. You add it to the existing query for google.com. You get the answer back from the root servers. You ask the com servers for google.com. You get another 3 query for google.com, you add these to the original query. You get a response from the com servers. You ask the google.com servers for google.com. You get more queries for google.com. You get a answer back from the google.com servers and you send the answers back to all the clients that asked you for google.com. Future queries for google.com will be answered from the cache until the record expires. Now if more than 10 clients ask you for google.com while this is happening you will just drop the new clients (they should retry). Named will remember that it dropped clients and as it got a answer it will increase the number of clients that it serve for the next query. It's a little more complicted than this but this will do for this explaination. This lets named adjust to the normal query rate and how far it is from the usual nameservers it talks to round trip wise. This normally take less than a second. Now lets say the servers for a zone are unreachable. Named will only queue up 10 clients before it starts dropping them. This stops the recursive client slots all being taken on queries talking to these servers. Similar a flash crowd of queries for the same name will be mostly dropped until the answer is received. Mark Thank you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
