Re: File System Choice
2009/11/26 万善义 : > 500,000 domains, with the Ext3 file system, DNS service starts very slow and > therefore require several hours before they can work properly. For the bind > file system choices, there are any suggestions advice? Are you sure it's filesystem issue? ext3 has a feature, dir_index, which uses hashed b-trees to speed up lookups in large directories. It's activated by default (at least on RHEL & Ubuntu, should be the same on other modern distros). Try checking with "dumpe2fs -h" to make sure you have it. Also, you could organize the zone files (manually) so that they spread over many directories instead of one. -- Fajar ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
File System Choice
500,000 domains, with the Ext3 file system, DNS service starts very slow and therefore require several hours before they can work properly. For the bind file system choices, there are any suggestions advice? -- 万善义 2009-11-26 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation works with DLV, but not with just trusted-key
In message <200911252202.napm2asg000...@drugs.dv.isc.org>, Mark Andrews writes: > > Or one could use DLV to provide the trust linkage. > > dnssec-tools.org.dlv.isc.org. 3499 IN DLV 54556 5 1 > 11A4026F4E09B1C106AAF3AC81A37AA537B8A3E6 > dnssec-tools.org.dlv.isc.org. 3499 IN DLV 54556 5 2 > 6B026928292D452A5CC37B3EF327F27F50A29936CB31E664EB066D71 A476E > 282 Should have read the subject more closely. :-) In any case as Alan said, there needs to be a trusted path from a trust anchor to the data. DLV provides that trusted path. ORG will soon once they leave the "friends and family" stage. Mark -- 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: DNSSEC validation works with DLV, but not with just trusted-key
Or one could use DLV to provide the trust linkage. dnssec-tools.org.dlv.isc.org. 3499 IN DLV 54556 5 1 11A4026F4E09B1C106AAF3AC81A37AA537B8A3E6 dnssec-tools.org.dlv.isc.org. 3499 IN DLV 54556 5 2 6B026928292D452A5CC37B3EF327F27F50A29936CB31E664EB066D71 A476E282 -- 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: DNSSEC validation works with DLV, but not with just trusted-key
Hanno Böck wrote: Am Mittwoch 25 November 2009 schrieb Alan Clegg: There is no DS record for dnssec-tools.org in .org (chain of trust is broken), so you can't validate the response -- thus the data being passed back to you. Ok, that explains it. Are there any example domains with known-broken dnssec records with a full trust chain? I've been meaning to set some up, but at this moment, I'm not aware of any. Setting up your trust-anchor with the DNSKEY from dnssec-tools.org would be only one level worse than using the DNSKEY from .org Setting up validator using the key from dnssec-tools.org should be able to prove your point... AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation works with DLV, but not with just trusted-key
Am Mittwoch 25 November 2009 schrieb Alan Clegg: > There is no DS record for dnssec-tools.org in .org (chain of trust is > broken), so you can't validate the response -- thus the data being > passed back to you. Ok, that explains it. Are there any example domains with known-broken dnssec records with a full trust chain? -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de http://schokokeks.org - professional webhosting signature.asc Description: This is a digitally signed message part. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC validation works with DLV, but not with just trusted-key
Hanno Böck wrote: dig baddata-A.test.dnssec-tools.org @localhost There is no DS record for dnssec-tools.org in .org (chain of trust is broken), so you can't validate the response -- thus the data being passed back to you. AlanC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC validation works with DLV, but not with just trusted-key
Hi,
Maybe I'm getting something wrong here, but as far as I understand, when I
enable dnssec and dnssec-validation and have a zone with a trusted-key, bind
should not answer to requests for bad dnssec signatures.
This is my config:
trusted-keys {
org. 257 3 7
"AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDodnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1s
R3VvP/SR36mmGssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3AbSzBKC0v7uZrM6M2eoJn
l6id66rEUmQC2p9DrrDg9F6tXC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2mx7kEgU8e
6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rjCG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifr
H8KjDqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU=";
};
options {
directory "/var/bind";
listen-on-v6 { none; };
listen-on { 127.0.0.1; };
pid-file "/var/run/named/named.pid";
dnssec-enable yes;
dnssec-validation yes;
};
Now, a
dig baddata-A.test.dnssec-tools.org @localhost
gives me an answer:
;; ANSWER SECTION:
baddata-A.test.dnssec-tools.org. 86400 IN A 75.119.216.30
When I enable DLV-validation with
dnssec-lookaside . trust-anchor dlv.isc.org.;
it works and I get no A-record in the answer.
But that shouldn't be needed if I have a key for that zone.
Am I wrong or is bind wrong?
--
Hanno Böck Blog: http://www.hboeck.de/
GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de
http://schokokeks.org - professional webhosting
signature.asc
Description: This is a digitally signed message part.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Occasional errors from res_nsearch
On 11/25/09 05:44, Divakar Pratap Singh P wrote: Hi, I am using S olaris (5.10 Sparc as well as i386 ) server to run an application (written in C language) which uses B ind library client implementation (available on Solaris box by default, version 4.9.4) . On processing consecutive lookup requests using the function res_nsearch , many of the initial requests fail, and after some time, it starts resolving the requests . Error code returned is either 1 or 2, but after some time it starts working fine with eror code 0. Nslookup command works perfectly fine, resolving all valid domains correctly. We have nis service also configured on the servers. Could that be an issue here ? Because its calling res_nsearch() directly NIS shouldn't be an issue, though the NIS domainname would be used - set by res_ninit() - if one is not provided in resolv.conf(4). You should find setting environment variable RES_OPTIONS=debug useful in seeing what the resolver is doing. For further help please provide resolv.conf, output from command when RES_OPTIONS=debug is set and preferably the C code. Stacey Marshall. Sun Microsystems. Cumulative log of replies from res_nsearch ( for domain “ google.com ” ) : - function ret val: 1 Error Msg DNS lookup failed: Response is 'No address associated with name'. Resolved IP: function ret val: 1 Error Msg DNS lookup failed: Response is 'No address associated with name'. Resolved IP: function ret val: 1 Error Msg DNS lookup failed: Response is 'No address associated with name'. Resolved IP: function ret val: 1 Error Msg DNS lookup failed: Response is 'No address associated with name'. Resolved IP: function ret val: 1 Error Msg DNS lookup failed: Response is 'No address associated with name'. Resolved IP: function ret val: 0 Error Msg Resolved IP: 74.125.67.100 function ret val: 0 Error Msg Resolved IP: 74.125.53.100 function ret val: 0 Error Msg Resolved IP: 74.125.45.100 function ret val: 0 Error Msg Resolved IP: 74.125.67.100 function ret val: 0 Error Msg Resolved IP: 74.125.53.100 function ret val: 0 Error Msg Resolved IP: 74.125.45.100 function ret val: 0 Error Msg Resolved IP: 74.125.67.100 function ret val: 0 Error Msg Resolved IP: 74.125.53.100 - Thanks in anticipation, Divakar. ___ 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
