Joe Baptista wrote:
ORG and GOV and quite a lot of the ccTLD's are DNSSEC compatible, so I
don't actually think it'd be much of a horserace if compatibility is all
you're looking for.
I agree they are both DNSSEC compatible but .GOV has only deployed
DNSSEC in 20% of it's
On Thu, Feb 25, 2010 at 10:02:45AM +1100,
Mark Andrews ma...@isc.org wrote
a message of 68 lines which said:
Try this patch. It resets the scratch space 'data' used by
dns_dnssec_sign().
It works fine. Many thanks.
Sending update to ::1#8053
Outgoing update query:
;; -HEADER- opcode:
On 2010-02-24 14:09, Peter Andreev wrote:
2010/2/24 Alan Clegg acl...@isc.org mailto:acl...@isc.org
Peter Andreev wrote:
For example: if user asks for non-existent domain, caching
server
replies with some address and no-error rcode.
_Extremely_
On Tue, Feb 23, 2010 at 05:54:01PM +0100,
Stephane Bortzmeyer bortzme...@nic.fr wrote
a message of 18 lines which said:
OK, I upgrade:
% dnssec-settime -v 3 -f Ktoto.fr.+008+42555
dnssec-settime: toto.fr/RSASHA256/42555
But it changed nothing, ls -l shows that the file did not change
Stephane Bortzmeyer wrote:
Sam Wilson sam.wil...@ed.ac.uk wrote
Has anyone found any uz5* servers out there yet?
Zero for opendns.com, dnscurve.org, etc.
One:
dempsky.org. 259200 IN NS
uz5p4utwsxu5p3r9xrw0ygddw2hxh7bkhd0vdwtbt92lf058ny1p79.dempsky.org.
* Eugene Crosser:
Right now, as far as I am concerned, the main obstacle to more
widespread adoption on DNSSEC is the lack of procedure to establish
trust between your zone and the TLD.
There's no standard procedure for NS and glue management, either, and
it still seems to work quite well.
* Sam Wilson:
Has anyone found any uz5* servers out there yet?
node.pk, dempsky.org has such name servers. I thought there were
more. Has the magic prefix changed?
--
Florian Weimerfwei...@bfk.de
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100
Stephane Bortzmeyer wrote:
And strace (Debian/Linux box) shows that key files were opened only in
read-only and no file was opened for writing:
% strace dnssec-settime -f -v 3 Ktoto.fr.+008+42555 | grep open
Did anyone managed to use dnssec-settime -f ?
Yes. The key file format is
In article mailman.633.1267090950.21153.bind-us...@lists.isc.org,
Florian Weimer fwei...@bfk.de wrote:
* Sam Wilson:
Has anyone found any uz5* servers out there yet?
node.pk, dempsky.org has such name servers. I thought there were
more. Has the magic prefix changed?
OK. I found none
Hello,
I see that hosts that are not allowed to recurse are often generating
check-named errors.
I wonder if it wouldn't be better to check ACL's first and check-names just
after it?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail
On 02/24/10 18:50, Mike Chesney wrote:
Running Bind 9.6.1-P3
We run authorative DNS for 60k+ zones. One one network where we two
dns servers both running the same hardware on Centos 5.4
We see slow dns responses : example
for i in {1..250}; do dig example.com http://example.com @localhost
On 02/24/10 20:56, John Center wrote:
Hi Stace,
Sorry, I didn't think this was necessarily a Solaris problem. I'm running this
on Solaris 10 (SPARC 64bit), built with Sun Studio 12.1. Why did it occur on
OpenSolaris?
Hi John,
Interesting, I didn't see the issue on Solaris 10 but then
On Thu, Feb 25, 2010 at 10:47:58AM +0100,
Hauke Lampe list+bindus...@hauke-lampe.de wrote
a message of 55 lines which said:
For example, try:
dnssec-settime -P+0 -A+0 -f -v 3 Ktoto.fr.+008+42555
OK, it works, thanks.
___
bind-users mailing list
On 25.02.10 12:01, Matus UHLAR - fantomas wrote:
I see that hosts that are not allowed to recurse are often generating
check-named errors.
check-names it is.
I apparently too often use named so I do this king of mistypes.
I wonder if it wouldn't be better to check ACL's first and check-names
Hi,
I have question about “dig” command in IPV6.
I have bind-9.6.1-P3 compiled with ipv6 enable. So far it’s running great. But
when I use the “dig” command from 9.6.1-P3, I get the following error when
query record:
client ::1#33086: query (cache) 'dnssec12.datamtn.com//IN' denied
On Wed, Feb 24, 2010 at 10:23 PM, Alan Clegg acl...@isc.org wrote:
Joe Baptista wrote:
dnssec-enable yes;
and
dnssec-validation yes;
are the defaults since BIND 9.5
How do I turn it off.
Since you edited out the most important part of my post, I'll repeat
On Thu, 25 Feb 2010, Eugene Crosser wrote:
Right now, as far as I am concerned, the main obstacle to more widespread
adoption on DNSSEC is the lack of procedure to establish trust between your zone
and the TLD. Even if my zone is signed, and it's in .org which is signed too, I
have no
Or, if you think you might accidentally sign your zones or configure
trust anchors, you can:
dnssec-enable no;
dnssec-validation no;
OK - so if I do the above - will that prevent my recursive server from doing
DNSSEC if it gets information from a DNSSEC signed zone?
Yes,
In message 20100225123134.gb2...@fantomas.sk, Matus UHLAR - fantomas writes:
On 25.02.10 12:01, Matus UHLAR - fantomas wrote:
I see that hosts that are not allowed to recurse are often generating
check-named errors.
check-names it is.
I apparently too often use named so I do this king
19 matches
Mail list logo
