Re: response case in-sensitivity?

2015-07-29 Thread Hauke Lampe
On 30.07.2015 03:02, Mathew Ian Eis wrote:

 My reading of that article suggests the RFC compliant behavior is to preserve 
 the case in the response, is this correct? 
 https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.html

I never quite understood DNS compression rules but I can confirm what
you see with BIND 9.10.2 and that the ACL mentioned in the comments
changes the behaviour.

The responses matches the case of the cached entry:

SRV? _xmpp-server._TCP.hauke-lampe.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2

SRV? _xMpP-ServeR._tCp.haukE-lampE.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2


with no-case-compress { any; };:

SRV? _xmpp-server._TCP.hauke-lampe.de. (61)
1/4/9 _xmpp-server._TCP.hauke-lampe.de. SRV jabber2

SRV? _xMpP-ServeR._tCp.haukE-lampE.de. (61)
1/4/9 _xMpP-ServeR._tCp.haukE-lampE.de. SRV jabber2

[This new ACL is going to be available in 9.10.0 (noted already as
being in 9.10.0b1), 9.9.6, and 9.8.8, as well as in subscription
versions of BIND.]


Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Again question about edns (like swupdl.adobe.com)

2014-10-22 Thread Hauke Lampe
On 22.10.2014 12:30, IDS Submit wrote:

 with www.acer.it I have the same problem as swupdl.adobe.com

Indeed, I the same on a BIND 9.10.1 resolver with SIT requests enabled:

 $ dig swupdl.wip4.adobe.com
[...]
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 2510
[...]
 wip4.adobe.com.   30  IN  SOA sj1gtm001.adobe.com. 
 hostmaster.sj1gtm001.adobe.com. 1288 10800 3600 604800 60

As the SIT option uses an experimental OPT code for now, you should
expect strange behaviour from a few servers if the option collides with
other experimental code. For example, NSD 2.x responds to BIND's SIT
request with RCODE 17 (BADKEY).


Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Cannot chroot bind: ENGINE_by_id failed (crypto failure)

2014-06-26 Thread Hauke Lampe
On 26.06.2014 22:53, Matthew Washington wrote:

 May 20 16:32:15 fortress named[6034]: error:260B6084:engine 
 routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:450:
 May 20 16:32:15 fortress named[6034]: error:2606A074:engine 
 routines:ENGINE_by_id:no such engine:eng_list.c:418:id=gost
 May 20 16:32:15 fortress named[6034]: initializing DST: crypto failure

libssl tries to load the GOST engine from a platform-specific path.
I used strace to find it:
strace named -f -c /etc/named.conf -t /svc/name -u named 21|grep gost

|open(/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/libgost.so,
|O_RDONLY) = -1 ENOENT (No such file or directory)

Alternatively, the Debian package patched named and moved the SSL init
code before the chroot:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696661


Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Most specific match on PTR records

2013-02-21 Thread Hauke Lampe

On 21.02.2013 19:20, Nikita Koshikov wrote:

I haven't tested this in detail but here's what I would try:


I'm trying to cut /24 network from the scope of /8 network, here is
example:

 zone 11.2.10.in-addr.arpa {
 type forward;
 forwarders { 192.168.1.23; 192.168.1.24; };
 };

 zone 10.in-addr.arpa {
 type master;
 file master/int/10.in-addr.arpa;
 };



The local authoritative data takes precedence over a forward zone.


10.in-addr.arpa is just a file that returns NXDOMAIN for any 10.0.0.0/8 ip
address. But I need to forward requests for 10.2.11.0/24 net to other dns
servers and the above config not working.


The easiest way might be to delegate the subdomain with a static-stub:

  zone 11.2.10.in-addr.arpa {
  type static-stub;
  server-addresses { 192.168.1.23; 192.168.1.24; };
  };

  zone 10.in-addr.arpa {
  type master;
  file master/int/10.in-addr.arpa;
  };

This is a synthetic delegation. There could be a problem if a client 
queries 2.10.in-addr.arpa. The NXDOMAIN response (instead of nodata) can 
be interpreted as *.2.10.in-addr.arpa. doesn't exist. A real 
delegation in the zone file is probably better.


If your version of BIND is older than 9.8, you could try to move the 
master zone into a view and configure 10.in-addr.arpa as another forward 
zone in the client's view.



Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Querying directly a nameserver works, while forwarding not

2012-12-05 Thread Hauke Lampe

On 05.12.2012 10:23, Daniele Imbrogino wrote:


I restarted BIND9 and then I tried, for example, 'dig www.apple.com'
obtaining connection timed out; no servers could be reached.
But if I try 'dig @10.0.2.3 www.apple.com' it works correctly and I obtain
the correct answer.

Why? How can I resolve this problem?


Look at your resolv.conf and make sure that it actually directs queries 
to your newly installed BIND.


Check the log for mentions of rejected queries, even though those 
shouldn't result in a timeout. The default configuration allows 
recursive queries from localhost and your local network.


If all else fails, trace the query packets with tcpdump and find out 
where they end up.



Hauke.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Querying directly a nameserver works, while forwarding not

2012-12-05 Thread Hauke Lampe

On 05.12.2012 14:59, Daniele Imbrogino wrote:


resolv.conf contains only 127.0.0.1 as nameserver.

The syslog contains a lot of errors as insecurity proof failed, no valid
RRSIG, got insecure response that I don't understand.


Your forwarder probably doesn't handle DNSSEC responses well. Therefore 
your BIND cannot validate the answers and returns a failure code.


Either update the forwarder/enable DNSSEC (older versions of BIND 9 
require dnssec-enable yes; in the options clause), or disable DNSSEC 
validation in your local BIND (set dnssec-validation no;).




Hauke

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: dnssec-keygen not responding

2011-12-01 Thread Hauke Lampe

Jan-Piet Mens wrote:

- Original message -
 Would you be willing to give us a few more details, such as the name of
 the USB random source generator (is it an Entropy Key) ? 
 
 Of course
, if you do tell us what hardware you're using, the next thing
 will be we'll want a copy of your unofficial little daemon ... ;-)

I don't know what Mark uses but I am quite satisfied with Entropy Key's USB key 
with ekeyd as source and distributing entropy via VPN to remote egd clients:
http://www.entropykey.co.uk/download/

Keep in mind, that while the ekey daemon goes to great lengths to protect the 
entropy stream on the USB interface, the egd TCP connection is not encrypted or 
signed in any way. A middleman can record the raw entropy stream mixed into a 
server's pool and maybe even replace it with a know pattern.


Hauke

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: about the A and PTR for sending mail

2011-11-10 Thread Hauke Lampe
On 10.11.2011 02:57, 风河 wrote:

 I have two server IPs, the A records for them are:
 
 mail.dnsbed.com.300 IN  A   74.117.233.4
 mail.dnsbed.com.300 IN  A   74.117.232.204
 
 The corresponding PTR records are:
 
 4.233.117.74.in-addr.arpa. 36466 IN PTR dnsbed.com.
 204.232.117.74.in-addr.arpa. 36453 IN   PTR dnsbed.com.

The forward lookup for dnsbed.com returns:;
173.245.61.41
173.245.61.115

The reverse entries for your nameserver don't have to match your
mailserver name but they must be consistent, i.e. the reverse must
resolve forward to the IP address.

mail.dnsbed.com - 74.117.233.4 - dnsbed.com - 74.117.233.4 would be a
consistent reverse/forward loop.

mail.dnsbed.com - 74.117.233.4 - dnsbed.com - 173.245.61.41 is not

Maybe the easiest way would be to change the PTRs of
4.233.117.74.in-addr.arpa. and 204.232.117.74.in-addr.arpa to
mail.dnsbed.com, so you don't have to move the A records of dnsbed.com


HTH,
Hauke.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named resolution problem

2011-10-05 Thread Hauke Lampe
On 05.10.2011 12:58, Roberto Bosticardo wrote:

 If you ask a resolver/cache server running named the resolution of name
 www.myspace.fr it returns (SERVFAIL), if you ask the same to a
 dnscache server it correctly resolves to the ip address.

BIND doesn't like NS records resolving to CNAMEs:

The domain is delegated to two servers:
myspace.fr. 60  IN  NS  ns1.myspace.com.
myspace.fr. 60  IN  NS  ns2.myspace.com.

Resolving the server names reveals CNAMEs:
ns1.myspace.com.60  IN  CNAME   DNS11.COTDNS.net.
ns2.myspace.com.60  IN  CNAME   DNS12.COTDNS.net.

That is a configuation error at myspace.com and BIND returns SERVFAIL.
Unbound and dnscache are more forgiving in this case.


Hauke.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Hauke Lampe
On 30.09.2011 03:32, 刘明星:) wrote:

 How does ISP use a proxy to filters answers and returns whatever they want to 
 the customer?

BIND can do that for you with Response Policy Zones (DNS RPZ).
See
http://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-using-response-policy-zones-rpz/


Hauke.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NXDOMAIN redirection in BIND 9.9

2011-09-30 Thread Hauke Lampe
On 29.09.2011 23:06, Bill Owens wrote:

 *except that perhaps those who enable this feature will use it as an excuse 
 to avoid enabling validation, which would be a very bad result, IMO. . .

My reading of the docs says that BIND's NXDOMAIN redirections won't
break DNSSEC-signed results:

If the client has requested DNSSEC records (DO=1) and the NXDOMAIN
response is signed then no substitution will occur.

I didn't get it to work, yet, though. After enabling the redirect zone,
BIND goes into an endless loop of zone_timer/zone_maintenance/zone_settimer.

I'll try 9.9.0a2 later today.


Hauke.




signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: auto-dnssec maintain stoped working again...

2011-09-30 Thread Hauke Lampe
On 01.10.2011 00:09, Michelle Konzack wrote:

 I run my three NS with DNSSEC and now I have encountered,  that  it  has
 stoped maintaining the Zone since  september  and  has  not  changed  to
 october.

Do you mean expired signatures or no signatures at all?
In the latter case, have you checked that the zone's keys are readable
by named and still active?

Try dnssec-settime -p all /path/to/keys/Kexample.com.+005+12345.key and
look for Activate: and Inactive:

There have been a few bugfixes to automatic signing between 9.7.3 and
9.8. Maybe you hit one of those bugs.


Hauke.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC not populating parent zone files with DS records

2011-09-30 Thread Hauke Lampe
On 01.10.2011 02:48, Jeff Reasoner wrote:
 Hmm, I see an A record using the same query:
 [foo@dns1 ~]$ dig +dnssec extended.nau.edu a

I get a SERVFAIL response for the first query and NXDOMAIN for
subsequent request:

named: client 127.0.0.1#54707: query: extended.nau.edu IN A +ED (127.0.0.1)
named: createfetch: extended.nau.edu A
named: createfetch: extended.nau.edu DNSKEY
named: createfetch: extended.nau.edu DS
named: createfetch: nau.edu DNSKEY
named: createfetch: nau.edu DS
named: createfetch: edu DNSKEY
named: createfetch: nau.edu.dlv.isc.org DLV
named:   validating @0x7f36f7f17680: nau.edu SOA: no valid signature found
named:   validating @0x7f36f7eed410: nau.edu NSEC: no valid signature found
named:   validating @0x7f36f7eed410: ewb.nau.edu NSEC: no valid
signature found
named: error (broken trust chain) resolving
'extended.nau.edu/DNSKEY/IN': 134.114.138.3#53
named: error (broken trust chain) resolving 'extended.nau.edu/A/IN':
134.114.96.4#53
named: client 127.0.0.1#54707: query failed (SERVFAIL) for
extended.nau.edu/IN/A at query.c:6302
named: client 127.0.0.1#55872: query: extended.nau.edu IN A +ED (127.0.0.1)

Unbound resolves the record on the first try.

Aside from the missing DS, I don't see why BIND complains about the
NXDOMAIN response at first and then returns that cached record set in
response to later queries for the same name. dig +sigchase validates it,
if provided with the nau.edu DNSKEY:

 nau.edu.  86400   IN  SOA ns3.nau.edu. 
 DNS-Contact.nau.edu. 4779 1800 900 604800 86400
 nau.edu.  86400   IN  RRSIG   SOA 5 2 86400 20111030191258 
 20110930181258 7485 nau.edu. 
 xoY5c8d+UnJfXA0ZZDv2Zz5tht4ZspTOeGvEGcQr+XIOMH39krpWR6T9 
 fUy5O/XnURz5nDGWR4QIKQMgAu+qfyGzA9Yzb5S5CkAWd4IDjKmznrXI 
 G3beth9Dcr/fJxusMxGuhZWZftQBrHBn14Wqx8YKOOIwQZx/PSm8XONA tHc=
 nau.edu.  86400   IN  NSEC_tcp.nau.edu. A NS SOA MX TXT 
 RRSIG NSEC DNSKEY TYPE65534
 nau.edu.  86400   IN  RRSIG   NSEC 5 2 86400 20111020001752 
 20110919233312 7485 nau.edu. 
 GizWBgmH1B7n0TuBjRgUEiu0XOCvrncyKR1iSSWJIrWKn4aZ9djBazdP 
 /JEWGY73IIZ4j/i3yO6MSw1gJRe0ane3lZjpHFnFdaPPEcYHVWy3h7Zk 
 UccnBd0ggkkLrHoG/CbRoVrF+90CDJymeAnYcWDycKQW84cNibj/tXxb CRk=
 ewb.nau.edu.  86400   IN  NSECfacdevnet.nau.edu. CNAME RRSIG 
 NSEC
 ewb.nau.edu.  86400   IN  RRSIG   NSEC 5 3 86400 20111019222812 
 20110919220129 7485 nau.edu. 
 SfCIx42kzjbTV5sDH/OwIKGRRxfJaM8EgaX74/RbD+BJjJhP7o28dR1U 
 VHRuO6arK8FXF0vCIZ5lpqaWFRkaCwEftrjX3ktdWUNfhRlD9qqHF+cV 
 00icFXkasql9f8Yk9XgTeZ63CkH/8H9acjTuVlunqZDL1CVtaKTJfKKq uMs=
 ;; Received 710 bytes from 134.114.96.4#53(134.114.96.4) in 189 ms



Hauke.



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bug in bind 9.7.3?

2011-05-26 Thread Hauke Lampe

I can't get my 9.8.0-P1 resolvers to crash. The response from the
federalreserve.gov servers looks strange, though:

dig +dnssec +ignore +norec federalreserve.gov soa @ns5.frb.gov
;; Warning: Message parser reports malformed message packet.
;; WARNING: Messages has 57 extra bytes at end


Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stub zone vs forward zone

2011-03-18 Thread Hauke Lampe
On 18.03.2011 10:17, Marc Haber wrote:

 Which it doesn't in the forward setup, it just immediately returns NXDOMAIN.

Do you include zones.rfc1918 in your configuration? What SOA RR does the
NXDOMAIN return?

| zone 0.10.in-addr.arpa {
| type forward;
| forwarders { 10.0.0.2; };
| };
|
| include /etc/bind/zones.rfc1918;

The dummy zone overrides the forward declaration:

| $ dig -x 10.0.0.3
| ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 59555
|
| ;; AUTHORITY SECTION:
| 10.in-addr.arpa.  86400   IN  SOA localhost. root.localhost. 1 
604800
86400 2419200 86400



Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: BIND 9.8.0b1 Released Today

2011-01-24 Thread Hauke Lampe
On 24.01.2011 15:54, Paul Wouters wrote:

 I meant, if you have a zone example.tld. And tld. is not signed, but
 you have a testbed for a signed tld. at IP 1.2.3.4, if static-stub
 would allow you to configure a resolving bind to perform DNSSEC on
 1.2.3.4 with a loaded trusted-key. So yes, the de (or ca) testbed
 hook.

Yes, it works.
No more DNS format error [...] non-improving referral.

See the attached diff to DeNIC's testbed configuration
https://www.secure.denic.de/fileadmin/public/events/DNSSEC_testbed/dnssec-testbed-muster-bind.txt


Hauke.
--- dnssec-testbed-muster-bind.txt.old	2010-10-01 09:05:49.0 +0200
+++ dnssec-testbed-muster-bind.txt	2011-01-24 16:37:06.0 +0100
@@ -12,16 +12,15 @@
 //   ``zone Statement Definition and Usage''
 
 zone de {
-	type forward;
+	type static-stub;
 	// Die Reihenfolge der beiden Adressen kann beliebig gewaehlt
 	// werden
-	forwarders {
+	server-addresses {
 		81.91.161.228;	// auth-fra.dnssec.denic.de
 		87.233.175.25;	// auth-ams.dnssec.denic.de
 		// IPv6 nur bei geeigneter Konnektivität aktivieren
 		// 2A02:568:0:1::53;	// auth-fra.dnssec.denic.de
 	};
-	forward first;
 };
 
 // WICHTIG: Diese Liste muss regelmaessig gepflegt werden und


signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC auto-dnssec issue bind-9.7.2-P3

2011-01-19 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19.01.2011 15:59, Zbigniew Jasiński wrote:

 like i wrote in my previous email I've checked the journal file and
 there are updates with RRSIG records but still named is returning
 answers without signatures

Another thing you might check:

With dnssec-enable no; in named.conf, BIND still does its automatic
DNSSEC signing but won't add RRSIG to responses.

I ran across such a configuration lately. Your problem sounds similar.


Hauke.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk03IXIACgkQKIgAG9lfHFN0GgCfQssE0Gjl1iVH0EvX3K0RdXNQ
XUsAn1yeCOeolCfNmCEfOozhCKvgUOLW
=sDdG
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Telling rndc Which IP Address to Use

2011-01-19 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 19.01.2011 22:13, Barry Finkel wrote:

 Is there a
 way on the master to run rndc and tell rndc which IP address to use?

rndc -h doesn't show it. The option is apparently only documented in the
man page:

 -b source-address
  Use source-address as the source address for the connection to the
  server. Multiple instances are permitted to allow setting of both
  the IPv4 and IPv6 source addresses.



Hauke


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk03VrUACgkQKIgAG9lfHFO6SgCfSP8jGQi4vPqGG6nHxUSL/MAm
w2UAnjnRwCs9mEiedzQ+tHE9oSj7Ghlx
=TmFX
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Unable to query the nameserver

2010-10-05 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05.10.2010 20:35, Dotan Cohen wrote:

I think the problem is that your two servers return different
answers to the same question:

dig +norec sharingcenter.de ns @178.63.65.171:
 ;; ANSWER SECTION:
 sharingcenter.de. 86400   IN  NS  ns1.sharingcenter.de.
 sharingcenter.de. 86400   IN  NS  ns2.sharingcenter.de.

@88.198.27.251:
 ;; ANSWER SECTION:
 sharingcenter.de. 86400   IN  NS  ns2.sharingcenter.de.

That result matches the two zone files you show, with same SOA serial
number but different content. The comment in the SOA record indicates
that you don't slave the zone to ns2 and instead edit two distinct zone
files.

Either sync the zone files or set up the second server as slave and you
should be fine. You can check with DeNIC's pre-delegation test here:
http://nast.denic.de/


Hauke.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyre6AACgkQKIgAG9lfHFPGDwCfQo8RjhJNYYA6WG/9iAII0z9c
Yg8AoJRoCOnRQqYpTY60QdDvi12MeFf7
=AVXa
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Notice regarding BIND 9.7.2

2010-09-27 Thread Hauke Lampe


 Were there ... more information on these developments early next week?

I was just about to ask the same question. ;)

I noticed the absence of 9.7.2 on ftp.isc.org, read the announcement here a day 
later and rolled back my 9.7.2rc1 servers to 9.7.1-P2.

It would be good to know the nature of the bug, though. The complete removal of 
9.7.2* from the ftp site left me a bit worried.


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Verizon Users Can't See Site

2010-09-14 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14.09.2010 19:32, cybers...@comcast.net wrote:

 Today I was given access to a Linux box on the Verizon network that is using 
 their DNS server 71.252.0.12, which is affected by this problem.

Your nameserver software is case-sensitive where it should not be:

dig +norec www-mbclive.mbc.irides.com. @216.250.250.136
- - correct answer

dig +norec www-mbclive.mbc.irides.COM. @216.250.250.136
- - NODATA answer

If Verizon's DNS resolvers use 0x20[1] or modify the character case in
any way, they cannot find the right answer.

You should complain to your DNS LB vendor. Their implementation appears
to be too minimalistic.

dig +norec version.bind txt ch @216.250.250.136
;; Question section mismatch: got version.bind/TXT/IN
;; connection timed out; no servers could be reached



Hauke.


[1] Use of Bit 0x20 in DNS Labels to Improve Transaction Identity
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkyP3pAACgkQKIgAG9lfHFMnlwCfaySh4IgRYz/gxDsRwxdolheH
uNsAoL7VdmEZpSJFXn3eNeS0XLT0oHQJ
=Le9O
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: «tsig verify failure» only on some zones

2010-08-17 Thread Hauke Lampe

Joachim Tingvold wrote:

 During initial startup of NS3, most zones gets «tsig verify failure»,    
 but some zones are successfully transferred. All zones uses the same    
 transfer-key.

 Could this be an issue with different BIND-versions, or are there    
 other matters that could cause this?

What TSIG algorithms do you use and how long are the keys?

It could be that you hit an interoperability bug in BIND that was fixed in 
9.7.0, although it doesn't fit the symptoms exactly:

http://www.mail-archive.com/bind-users@lists.isc.org/msg04663.html

This is just hunch. I'd have no other explanation yet.


Hauke.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: new webserver ip

2010-08-03 Thread Hauke Lampe
Dwayne Hottinger wrote:

 I made the entry for the new website's ip (174.143.193.47).   But when   
 I do a dig, it still comes back with 204.111.40.10.

From what I can see here, your ns1 returns SERVFAIL, while your ns2 still 
serves an old zone with SOA serial 2009111201.

I'd suggest you look for errors in the logfiles at ns1 or test your zone file 
with named-checkzone.

Apparently, your new zone file contained some errors and BIND did not load it. 
The secondary nameserver continues to serve the old zone content until it 
expires 28 days after the last refresh.

Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Migrating to a New Cryptographic Suite

2010-07-26 Thread Hauke Lampe

- Original message -
 At present, i
 use the algorithm RSASHA-1 for DNSKEY, but i want migrate the RSASHA-1 to
 RSASHA-256, when i resigning the zone,it failed. so i wonder if   DNSSEC
 supporting migrating RSASHA-1   to RSASHA-256 smoothly?

Yes, it does. Smoothness depends on the timing. You might find this summary 
useful:
http://snad.ncsl.nist.gov/dnssec/download/DNSSEC_Algorithm_rollover.pdf

Did you create a new key with the appropriate algorithm ID? dnssec-signzone can 
only sign the zone with algorithms present in the DNSKEY set.

The actual error message would be helpful, too.

If you have registered DS records with your parent zone, you must update them 
to include the new key(s).


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Validating the root: translation of ICANN XML file

2010-07-20 Thread Hauke Lampe
On 07/18/2010 12:01 AM, Stephane Bortzmeyer wrote:

 you should add the -o option to wget, otherwise you may have  asecurity risk 

That should be -O. In older versions of wget (1.10.2/Debian Etch),
this option does not works together with -nc. The empty output file is
created first, therefore -nc never downloads anything.

Another thing I noticed is that newer wget always sets a downloaded
file's mtime to the timestamp received in the headers, with no apparent
way to disable it.

 Fixed on my local copy as well. Apart from that, does it work for you?

It does work for me. I attached a modified version that also outputs
root-anchors.mkey with the key wrapped in BIND's managed-keys clause.

Thanks Stéphane. With your Makefile and XSLT, it's very easy to verify
and convert the root anchors from IANA for use with Unbound an BIND.

root-anchors.txt for unbound and (auto-)trust-anchor-file.
root-anchors.mkey for RFC5011 mangement with BIND.
root-anchors.dnskey for static trusted-keys configuration.


Hauke
KEYFLAGS=257
HASHALG=2 # For dnssec-dsfromkey

all: root-anchors.txt root-anchors.dnskey root-anchors.mkey

root-anchors.xml:
-wget -nc -O root-anchors.xml 
https://data.iana.org/root-anchors/root-anchors.xml  touch root-anchors.xml
-wget -nc -O root-anchors.asc 
https://data.iana.org/root-anchors/root-anchors.asc  touch root-anchors.asc
gpg --verify root-anchors.asc root-anchors.xml || \
sh -c 'echo Invalid root-anchors.xml; rm -f root-anchors.xml 
root-anchors.asc; exit 1;'
@echo OK, root-anchors.xml is correct

root-anchors.txt: root-anchors.xml
xsltproc -o root-anchors.txt anchors2ds.xsl root-anchors.xml
dig DNSKEY . | grep -w ${KEYFLAGS}  untrusted.key
# Verify the key
# Thanks to Kazunori Fujiwara for the idea
dnssec-dsfromkey -${HASHALG} untrusted.key  untrusted.ds
cut -d' ' -f1-6 untrusted.ds | tr '\n' ' '  root-anchors.tmp
cut -d' ' -f7- untrusted.ds | sed 's/ //g' | tr '\n' ' '  
root-anchors.tmp
echo  root-anchors.tmp
@diff root-anchors.txt root-anchors.tmp || \
sh -c 'echo Invalid DNSKEY, deleting temporary files; rm -f 
root-anchors.txt root-anchors.tmp untrusted.key untrusted.ds; exit 1;'
@echo OK, root-anchors.txt is correct

root-anchors.dnskey: root-anchors.txt
awk  '{ORS=; print  $$1   $$5   $$6   $$7   \; for (i = 8; 
i = NF-1; i++) printf $$i  \n\t\t; print $$NF \;\n  }' untrusted.key 
root-anchors.dnskey;

root-anchors.mkey: root-anchors.txt
awk  '{ORS=; print managed-keys {\n\t $$1  initial-key  $$5   
$$6   $$7   \; for (i = 8; i = NF-1; i++) printf $$i  \n\t\t; print 
$$NF \;\n};\n  }' untrusted.key root-anchors.mkey

clean:
rm -f root-anchors.txt untrusted.key untrusted.ds root-anchors.tmp

realclean: clean
rm -f root-anchors.xml root-anchors.asc root-anchors.dnskey 
root-anchors.mkey


signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

How do I get from IANA's root-anchors.xml to managed-keys{}?

2010-07-16 Thread Hauke Lampe

Greetings, everyone.

Now that the signed root is finally in production, how do I initialize BIND's 
RFC5011 key management from the XML file published by IANA?

I downloaded the files and checked the PGP signature:

http://data.iana.org/root-anchors/root-anchors.xml
http://data.iana.org/root-anchors/root-anchors.asc

The XML file contains a DS hash of the root KSK, but BIND needs a public key in 
the managed-keys clause.

Are there any tools to retrieve the DNSKEY and validate it with the hash? Or 
even process the XML directly?

So far I used unbound to bootstrap the key but I am looking for a simpler way.



Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: zone syntax question

2010-07-14 Thread Hauke Lampe

- Original message -
 example.com.               IN SOA   
[...]
                   IN           NS           ns.example.com.
                   IN           MX 10     ns.example.com.

The A record for ns.example.com is missing from your zone.

 Will my proposed set up work on the old bind version..

Which old version?

 and it is syntactically correct ??

BIND comes with a tool named-checkzone that can do the syntax and integrity 
checks for you.


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Configure bind to reflect ip addresses (ala whoami.ultradns.net)

2010-06-23 Thread Hauke Lampe

Ricardo Oliveira wrote:

 Did anyone configured/hacked bind to reflect the ip address of the   
 querying resolver as whoami.ultradns.net is doing? 

I'd use scapy[1] and its AnsweringMachine module. It's probably easiest to use 
and adapt, although quite slow.

BIND could possibly serve the feature you want with a DLZ backend. PowerDNS 
also offers dynamic responses using its PipeBackend. I never used those 
features, though, and can't tell if that really works.


Hauke.


[1] http://www.secdev.org/projects/scapy/

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec zone signing problem

2010-05-20 Thread Hauke Lampe
On 05/20/2010 09:10 PM, itservices88 wrote:

 Verifying the zone using the following algorithms: RSASHA1.
 Missing RSASHA1 signature for . NSEC

You seem to have a record for . somewhere in your zone file.

Did you load the unsigned zone into BIND before? It should have logged a
warning about that record.

dnssec-enable yes;
dnssec-validation yes;
//  dnssec-lookaside . trust-anchor DLV.ISC.ORG;
 With the trust-anchor uncommented, as soon as i enable and reload bind, dig
 gives timeout, while dig has no issues with first two commands enabled.

Do you have a firewall in the path that would block large DNS responses
or fragments?


Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Fwd: Re: Dig 9.7 DNSSEC output

2010-05-09 Thread Hauke Lampe
On 05/09/2010 05:24 PM, Peter Janssen wrote:

 ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 9

 The issue I have with this is, dig announces 9 additional section entries,
 while 3 A, 1  and 4 RRSIG, in my book sums up to 8.

The additional section also contains the EDNS0 OPT record.


Hauke.





signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: T_ANY

2010-03-23 Thread Hauke Lampe
Kevin Darcy wrote:

 But I believe the QTYPE was
 _originally_ intended to be a robust mechanism for fetching multiple
 RRsets at a time.It just didn't work out that way...

PowerDNS Recursor uses ANY to retrieve both A and  records in one query:

http://lwn.net/Articles/275823/

| * Full IPv6 parity. If configured to use IPv6 for outgoing queries
|   (using query-local-address6=::0 for example), IPv6 and IPv4 addresses
|   are finally treated 100% identically, instead of 'mostly'. This
|   feature is implemented using 'ANY' queries to find A and 
|   addresses in one query, which is a new approach. Treat with caution.

I didn't test it enough yet to see any difference in performance or
problems with this approach.


Hauke



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NSEC3 records not available through a BIND resolver = 9.5?

2010-03-17 Thread Hauke Lampe
Stephane Bortzmeyer wrote:

 I cannot get the NSEC3 records through a BIND resolver if it is
 version = 9.5:
 
 % dig +dnssec jhfgTCFGD564564.org   
 
 If BIND = 9.6, it works (or with Unbound). Yes, NSEC3 support was
 added in 9.6 but, for older BINDs, TYPE50 (NSEC3) should be an 
 unknown RR type and should be transmitted as is, no?

BIND =9.5 doesn't know that it's supposed to pass them in a NXDOMAIN
response.

That said, I thought it would be possible to explicitely ask for TYPE50.
But that seems not to work, either:

 ha...@snorri:~$ dig +dnssec jhfgTCFGD564564.org |grep IN NSEC3 @127.0.0.1
 h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 142 IN NSEC3 1 1 1 D399EAAB 
 H9RSFB7FPF2L8HG35CMPC765TDK23RP6 NS SOA RRSIG DNSKEY NSEC3PARAM

 ha...@snorri:~$ dig +dnssec h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. NSEC3 
 @10.0.0.2
[...]
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 6265
[...]
 ;; QUESTION SECTION:
 ;h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. IN NSEC3
[...]
 ;; AUTHORITY SECTION:
 org.  732 IN  SOA a0.org.afilias-nst.info. 
 noc.afilias-nst.info. 2009057797 1800 900 604800 86400
 org.  732 IN  RRSIG   SOA 7 1 900 20100331154136 
 20100317144136 4193 org. 
 i2L/6m7SknlPyZSPm3+9WrSqq+FAKjJLlSu/ec0gKRR2efoRwOY7Qa/8 
 cbvFpVEm5h9z9ntCCbGPmejhks/N+mPQP4H/hecnff59N/utzzWuBCZ0 
 edIT1LA/Iu6KFMgDK0xdEfH4GPhtgFJwZc+K2TURhQewiOPUY42xHuG6 +IY=

I tested this against a much older version, though:

 version.bind. 0   CH  TXT 9.3.4-P1.2


Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

2010-02-25 Thread Hauke Lampe
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.
 dempsky.org.  259200  IN  NS  ns1.everydns.net.
 dempsky.org.  259200  IN  NS  ns2.everydns.net.
 dempsky.org.  259200  IN  NS  ns3.everydns.net.
 dempsky.org.  259200  IN  NS  ns4.everydns.net.

From what I know about DNSCurve, an average of one in five lookups for
this zone would use encrypted transport.

Anyway, bind-users is probably not the right mailing list for this
topic, unless a more formal protocol description for DNSCurve appears.

There's a similar thread on dnsops, so I suggest everyone interested in
DNSCurve subscribe and participate there:
https://lists.dns-oarc.net/mailman/listinfo/dns-operations



Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Cannot use dnssec-settime with old keys

2010-02-25 Thread Hauke Lampe
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 upgraded on write operations only.

For example, try:
 dnssec-settime -P+0 -A+0 -f -v 3 Ktoto.fr.+008+42555


Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Poblem with ZONE (subdomain)

2010-01-19 Thread Hauke Lampe
Michelle Konzack wrote:

 Jan 19 18:56:42 samba3 named[18333]: 19-Jan-2010 18:56:42.920 general: error: 
 dns_master_load: /etc/bind/net.tamay-dogan.debian:18: 
 lists.debian.tamay-dogan.net: CNAME and other data
 This give an error?

Yes. Look at line 18. lists is duplicate.

 [ '/etc/bind/net.tamay-dogan.debian' ]--
 lists   IN MX   10  mail.tamay-dogan.net.
 lists   IN CNAMEvserver3.tamay-dogan.net.


Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Logging problems on Bind9

2010-01-11 Thread Hauke Lampe
Autuori Gianluigi wrote:

 I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
 Named runs as bind user and in my named.conf.local I wrote:

Ubuntu uses AppArmor (http://en.wikipedia.org/wiki/AppArmor)

You need to edit the profile for usr.sbin.named in /etc/apparmor.d/ if
you want named to write files outside the allowed directories.

The easier way would be to move your query.log to /var/log/named/ as
this directory is allowed by default.

/etc/apparmor.d/usr.sbin.named:

/usr/sbin/named {
[...]
  # some people like to put logs in /var/log/named/ instead of having
  # syslog do the heavy lifting.
  /var/log/named/** rw,
  /var/log/named/ rw,
}


HTH,
Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC Bogus NXDOMAIN survives authenticating RR

2009-12-09 Thread Hauke Lampe
[I finally gave up on trying to get Thunderbird *not* to wrap long
lines. Prefixing them with  seems to be the only way, even if confusing]

Niobos wrote:

 dig +dnssec removed.dnssec.dest-unreach.be
 Even though I have added your DNSKEY as trusted key, I get SERVFAIL on
 the first query and NXDOMAIN on the second, without BIND doing any
 additional outgoing queries.
 This is the same behavior I'm observing.

I think I see it clearer now.

The inner workings of the NSEC/3 mechanisms are a bit of a mystery to
me, so the following is mostly based on guesswork.

Maybe I broke my test zone in a different way and that's why we don't
see the same results. Your SOA record validates, mine doesn't:

 validating @0xb91c7968: fnord.dnstest.hauke-lampe.de SOA: no valid signature 
 found

And there lies the problem.
The signatures on your SOA and NSEC3 records in the NXDOMAIN response
are all valid. It's their meaning, the proof of nonexistence for the
removed record, that cannot be established:

 validating @0xb4e01470: removed.dnssec.dest-unreach.be A: attempting negative 
 response validation
   validating @0xb4e01ee0: dnssec.dest-unreach.be SOA: verify rdataset 
 (keyid=33827): success
   validating @0xb8e98b60: 
 67152CME7SOELFT0OOTFB03FQ968LOM1.dnssec.dest-unreach.be NSEC3: verify 
 rdataset (keyid=33827): success
   validating @0xb8e98b60: 
 OKIU30OTQ4ETK8K4VP0L3MM20HUNI5R2.dnssec.dest-unreach.be NSEC3: verify 
 rdataset (keyid=33827): success
 validating @0xb4e01470: removed.dnssec.dest-unreach.be A: NSEC3 proves name 
 exists (owner) data=1
 validating @0xb4e01470: removed.dnssec.dest-unreach.be A: nonexistence 
 proof(s) not found

BIND seems to cache the validation state of the signatures, not the
failed nonexistence proof. At least it doesn't re-validate cached answers:

 client 127.0.0.1#47401: UDP request
 client 127.0.0.1#47401: using view '_default'
 client 127.0.0.1#47401: request is not signed
 client 127.0.0.1#47401: recursion available
 client 127.0.0.1#47401: query
 client 127.0.0.1#47401: query (cache) 'removed.dnssec.dest-unreach.be/A/IN' 
 approved
 client 127.0.0.1#47401: send
 client 127.0.0.1#47401: sendto
 client 127.0.0.1#47401: senddone
 client 127.0.0.1#47401: next
 client 127.0.0.1#47401: endrequest

So, while the first query returns SERVFAIL as expected, subsequent
responses from the cache even have the AD flag set. This is the one
thing that *really* puzzled me (otherwise I probably wouldn't have begun
looking at long debug logs ;)

 ha...@pope:~$ dig +dnssec removed.dnssec.dest-unreach.be 
[...]
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 46781
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

The response doesn't validate:

 ha...@pope:~$ dig +sigchase +trusted-key=./dnskey-dnssec.dest-unreach.be 
 +dnssec removed.dnssec.dest-unreach.be 
[...]
 ;; Impossible to verify the Non-existence, the NSEC RRset can't be validated: 
 FAILED

I think this is a bug in BIND's resolver part. You should forward a bug
report to bind9-b...@isc.org.

Unbound returns SERVFAIL to all queries for
removed.dnssec.dest-unreach.be and keeps logging the failed NSEC3 test:

 unbound: [968:0] debug: Validating a nxdomain response
 unbound: [968:0] debug: nsec3: keysize 1024 bits, max iterations 150
 unbound: [968:0] info: start nsec3 nameerror proof, zone 
 dnssec.dest-unreach.be. TYPE0 CLASS0
 unbound: [968:0] info: ce candidate removed.dnssec.dest-unreach.be. TYPE0 
 CLASS0
 unbound: [968:0] debug: nsec3 proveClosestEncloser: proved that qname 
 existed, bad
 unbound: [968:0] debug: nsec3 nameerror proof: failed to prove a closest 
 encloser
 unbound: [968:0] debug: NameError response failed nsec, nsec3 proof was 
 sec_status_bogus
 unbound: [968:0] info: validate(nxdomain): sec_status_bogus


 Do I understand the error correctly like this: BIND failed to prove
 the domain to be insecure, hence, the NXDOMAIN response should have a
 correct signature, hence, the response it got is bogus?

Yes, domains below a trust anchor (configured manually or through DLV)
must either be signed or proven to be insecure at the delegation point.

 What did you change for the removed record? Did you remove only the
 A and RRSIG? Or also the corresponding NSEC3?

I removed A and RRSIG only.

Here's what I did, using 9.7 defaults and smart-signing feature:

dnssec-keygen -r /dev/urandom -3 -f ksk $zone;
dnssec-keygen -r /dev/urandom -3 $zone;
dnssec-signzone -x -S -3 - -o $zone db.test

(/dev/urandom because it's faster and this was only a test zone)

Then I edited db.test.signed, changed the changed record and removed
removed and its RRSIG.

Why we see different kinds of failures, I don't know. It's probably got
to do with some of the signey-wimey DNSSEC voodoo stuff I hope I never
have to understand in all its details.


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: DNSSEC Bogus NXDOMAIN survives authenticating RR

2009-12-08 Thread Hauke Lampe
Niobos wrote:

 When requesting a lookup of removed, I get a SERVFAIL as well. However, 
 every subsequent request for removed gets an NXDOMAIN. (dig outputs below)
 Flushing the caches on the RR with rndc flush causes the first request to 
 be a SERVFAIL again.

I cannot reproduce this behaviour with BIND 9.7.0b3. I get a SERVFAIL
for all lookups to changed/removed records.

Maybe you can try these with 9.6.1-P1:

dig +dnssec normal.fnord.dnstest.hauke-lampe.de
should return 127.0.0.1 and the AD flag (if you use DLV with either
dlv.isc.org or dnssec.iks-jena.de).

dig +dnssec changed.fnord.dnstest.hauke-lampe.de
should return SERVFAIL and log error (no valid RRSIG) for the A record.

dig +dnssec removed.fnord.dnstest.hauke-lampe.de
should return SERVFAIL and log validation failures for the SOA as well
as the A record (because removing the record disrupted the NSEC3 chain).



Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC Bogus NXDOMAIN survives authenticating RR

2009-12-08 Thread Hauke Lampe
Niobos wrote:

 As soon as I activate DLV (besides the manual SEP I entered), the removed 
 behaviour changes:
 * First lookup still returns SERVFAIL
 * Subsequent lookups now return NXDOMAIN with the AD flag *set*! (log 
 confirms that my domain is not in the DLV and hence is insecure)

That is weird. I haven't seen that before and have no good explanation
at hand.

 Could you try this lookup?
 dig +dnssec removed.dnssec.dest-unreach.be

I see now what you mean.

Even though I have added your DNSKEY as trusted key, I get SERVFAIL on
the first query and NXDOMAIN on the second, without BIND doing any
additional outgoing queries.

One of your name servers returns unsigned NXDOMAIN responses with a
higher serial number than the master server:

| $ dig +dnssec removed.dnssec.dest-unreach.be @sdns1.ovh.net.
|
| ;; Got answer:
| ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 32510
| ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
| ;; WARNING: recursion requested but not available
|
| ;; OPT PSEUDOSECTION:
| ; EDNS: version: 0, flags: do; udp: 4096
| ;; QUESTION SECTION:
| ;removed.dnssec.dest-unreach.be.  IN  A
|
| ;; AUTHORITY SECTION:
| dest-unreach.be.  3600IN  SOA serv02.imset.org.
hostmaster.dest-unreach.be. 2009111619 3600 3600 604800 3600

serv02.imset.org returns a signed NXDOMAIN response with serial 2009081781.

That corresponds to BIND's error message:

| error (insecurity proof failed) resolving
'removed.dnssec.dest-unreach.be/A/IN': 213.251.188.140#53

 Could the problem be that the authenticating RR somehow considers this domain 
 to be insecure when looking up removed?

That might well be the case, although I would expect BIND not to return
unsigned queries for names below a manually configured trust anchor.

Maybe others have an idea what's happening here and why BIND returns
NXDOMAIN responses.


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Split view logging?

2009-11-19 Thread Hauke Lampe
Gregory Hicks wrote:

 First, create a 'pipe' in the /var/log directory with the name of the
 logging file.  (You probably want to do this in the named startup
 script.)  Log absolutely EVERYTHING to the log file.

Your method reminds me that I wanted to take a look at rsyslog filters
for a while now. It's the default syslog daemon in Debian Lenny, I just
never used its advanced features before.

This is what I use with BIND and rsyslog now:

$AddUnixListenSocket /var/cache/bind/dev/log   # inside chroot
:msg, contains, : view authoritative: query: 
/var/log/bind/queries-auth.log
:msg, contains, : view recursive-local: query: 
/var/log/bind/queries-recursive-local.log




Hauke.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Modifying Mixed Case Mid-level Domain Names to be all Lower Case

2009-11-14 Thread Hauke Lampe
Martin McCormick wrote:

 Is there a way using nsupdate to change a $origin directive in a
 zone file?

$origin is a preprocessor statement. It's not an attribute of a zone, so
you cannot change it directly.

When BIND writes zone files, it uses $origin to group records that share
a common base name. Just update delete/add all records and the mixed
case $origin disappears.


HTH,
Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.7.0a3: dnssec-signzone signs with passive keys?

2009-09-16 Thread Hauke Lampe


I currently explore the new DNSKEY metadata and dnssec-signzone -S with
BIND 9.7.0a3. This feature definitely helps making key management easier
and will motivate more operators to sign their zones. Thank you for that.


For this test, I created a zone with one manually timed KSK, one active
ZSK and another published ZSK with an activation date in the future.

When I sign the zone from an unsigned zone file, dnssec-signzone works
as expected and signs the records only with the active ZSK.

Re-signing the signed zone file, however, also includes signatures from
the passive ZSK, *unless* I remove the DNSKEY records from the zone file
before signing. I guess this is due to the keys already in the signed
zone file overriding the -S switch:

|key
|Specify which keys should be used to sign the zone.
|If no keys are specified, then the zone will be examined for
|DNSKEY records at the zone apex. If these are found and
|there are matching private keys, in the current directory,
|then these will be used for signing.

(No Fetching [...] from key repository when re-signing)


My question is: Is this the supposed behaviour (ie. keys already
included in a zone don't have their metadata checked, so I would need to
remove DNSKEY records), did I miss an option to pass to dnssec-signzone
or is it likely to change for the next release?



Hauke.


dnssec-settime/signzone output:

KSK:

| Kkeyroll.dnstest.hauke-lampe.de.+005+07849.key
|
| Created: Wed Sep 16 04:23:39 2009
| Publish: UNSET
| Activate: UNSET
| Revoke: UNSET
| Unpublish: UNSET
| Delete: UNSET

Active ZSK:

| Kkeyroll.dnstest.hauke-lampe.de.+005+42630.key
|
| Created: Wed Sep 16 21:19:34 2009
| Publish: Wed Sep 16 21:19:34 2009
| Activate: Wed Sep 16 21:19:52 2009
| Delete: Tue Oct 13 21:19:34 2009

Passive ZSK:

| Kkeyroll.dnstest.hauke-lampe.de.+005+07701.key
|
| Created: Wed Sep 16 21:21:35 2009
| Publish: Wed Sep 16 21:21:35 2009
| Activate: Tue Sep 29 21:21:35 2009
| Delete: Tue Oct 13 21:21:35 2009

Signing the zone from an unsigned zone file:

| + dnssec-signzone -v 3 -N unixtime -K rollkeys -e +4d -i 172800 -S -T
230042 -o keyroll.dnstest.hauke-lampe.de -f db.keyroll.signed db.keyroll
| Fetching KSK 7849/RSASHA1 from key repository
| Fetching ZSK 42630/RSASHA1 from key repository
| Fetching ZSK 7701/RSASHA1 from key repository
| dnssec-signzone: debug 1: decrement_reference: delete from rbt:
0xb7c83060 keyroll.dnstest.hauke-lampe.de
| dnssec-signzone: debug 1: calling free_rbtdb(.)
| dnssec-signzone: debug 1: done free_rbtdb(.)
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NSEC:
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/DNSKEY:
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/7849
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/SOA:
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NS:
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630
| Verifying the zone using the following algorithms: RSASHA1.
| Zone signing complete:
| Algorithm: RSASHA1: ZSKs: 2, KSKs: 1 active, 0 revoked, 0 stand-by
| db.keyroll.signed
| dnssec-signzone: debug 1: calling
free_rbtdb(keyroll.dnstest.hauke-lampe.de)
| dnssec-signzone: debug 1: done free_rbtdb(keyroll.dnstest.hauke-lampe.de)

Re-Signing:

| + dnssec-signzone -v 3 -N unixtime -K rollkeys -e +4d -i 172800 -S -T
230042 -o keyroll.dnstest.hauke-lampe.de -f db.keyroll.signed
db.keyroll.signed
| dnssec-signzone: debug 1: decrement_reference: delete from rbt:
0xb7c91060 keyroll.dnstest.hauke-lampe.de
| dnssec-signzone: debug 1: calling free_rbtdb(.)
| dnssec-signzone: debug 1: done free_rbtdb(.)
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/SOA:
| dnssec-signzone:rrsig by
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 dropped - failed to verify
| dnssec-signzone:resigning with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/7701
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NS:
| dnssec-signzone:rrsig by
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/7701
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/NSEC:
| dnssec-signzone:rrsig by
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained
| dnssec-signzone:signing with dnskey
keyroll.dnstest.hauke-lampe.de/RSASHA1/7701
| dnssec-signzone: keyroll.dnstest.hauke-lampe.de/DNSKEY:
| dnssec-signzone:rrsig by
keyroll.dnstest.hauke-lampe.de/RSASHA1/7849 retained
| dnssec-signzone:rrsig by
keyroll.dnstest.hauke-lampe.de/RSASHA1/42630 retained
| 

Re: Disabling DNSSEC validation per zone?

2009-09-02 Thread Hauke Lampe
Mark Andrews wrote:
 In message 4a99abeb.7080...@hauke-lampe.de, Hauke Lampe writes:

 I am looking for way to disable DNSSEC lookaside validation for a given
 zone.

 For any query to this zone, BIND tries to look up
 example.net.dlv.isc.org DLV records. If the external internet connection
 is down and the DLV record not cached, internal hostname resolution
 fails because BIND cannot prove the zone's insecure state.
 
 Just sign your internal zone and add a trusted-keys clause for it
 and you won't use DLV.  named only uses dlv if the zone is provably
 insecure based on the trust-anchors configured.

That's what I was trying to avoid for now. The internal zone doesn't
lend itself very well to DNSSEC-signing yet.

Also, name resolution failures for internal hostnames like LDAP servers
or kerberos names can cause a lot of trouble. I would have a hard time
justifying the benefits of DNSSEC validation if it bears the risk of
disrupting the internal network every time the SDSL connection congests
or a local zone admin manages to wreck the signatures.


What we try to achieve is:

- Validate DNSSEC signatures on resolvers close to the clients, using
dlv.isc.org
- Keep internal name resolution functioning, even if the connection to
the outer internet is down


I see the following options to do this. Please correct me if I missed some:

1. Sign the internal zone and configure trust-anchors on each resolver.
We really don't want to go there right now

2. Tell BIND about known-insecure zones, so it won't try to locate DLV
records, eg. dnssec-must-be-secure example.net never. Not possible
without changes to BIND, AFAICS.

3. Mirror the DLV zone locally, so that interruptions in the internet
connection won't block internal name resolution. We would probably use
this as an interim solution until either 1. or 2. is available.

I know I could simply recreate the DLV zone with dnssec-walker. An
official distribution via [AI]XFR, rsync or HTTP would be much
appreciated, though.



Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Format of 'dig -k' TSIG key file?

2009-08-22 Thread Hauke Lampe
Joseph S D Yao wrote:

 It turned out that this latter file was needed, but for some
 inexplicable reason perhaps having to do with library routines [I have
 not gone chasing down the code], it ALSO wants the mynet.private file!

The nsupdate manpages mentions this behaviour in the BUGS section:

| BUGS
|   The TSIG key is redundantly stored in two separate files. This
|   is a consequence of nsupdate using the DST library for its
|   cryptographic operations, and may change in future releases.

Maybe the dig manpage should, too, until it changes in future releases.


Hauke.
--- dig.1.orig	2009-08-22 13:41:49.0 +0200
+++ dig.1	2009-08-22 14:44:52.0 +0200
@@ -200,9 +200,10 @@
 .PP
 To sign the DNS queries sent by
 \fBdig\fR
-and their responses using transaction signatures (TSIG), specify a TSIG key file using the
+and their responses using transaction signatures (TSIG), specify a pair of TSIG key files using the
 \fB\-k\fR
-option. You can also specify the TSIG key itself on the command line using the
+option, which can be generated by
+\fBdnssec\-keygen\fR. You can also specify the TSIG key itself on the command line using the
 \fB\-y\fR
 option;
 \fIhmac\fR
@@ -561,6 +562,8 @@
 .SH BUGS
 .PP
 There are probably too many query options.
+.PP
+The TSIG key is redundantly stored in two separate files. This is a consequence of dig using the DST library for its cryptographic operations, and may change in future releases.
 .SH COPYRIGHT
 Copyright \(co 2004\-2009 Internet Systems Consortium, Inc. (ISC)
 .br


signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: stats brainteaser

2009-07-31 Thread Hauke Lampe
Todd wrote:

 Yesterday I needed to flush the cache on a number of my servers, and I
 saw a big spike in queries recorded by the server in the success
 category. The spike was about 40% more than the usual traffic.

After a cache flush, the server has to re-fetch glue and nameserver
records from the root up to the target names. This can cause a
noticeable spike on a busy resolver. The statistics count these
internal queries, too.

 So, my mental exercise is this ... does BIND not record a cache hit as
 a success?

It does, AFAIK. If it was a success and not a cached negative response
or other.

 Assuming my clients are doing say, 1000queries/second, and all 1000
 are cache hits, do they show up as a success?

They do, but so do successfully resolved cache misses.

The number of cache hits is approximately
(responses sent) - (queries caused recursion)

Approximately, because the value includes answers from local
authoritative zones, FORMERRs and other responses that did not come from
the cache.



Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: about cache nonexist record

2009-07-21 Thread Hauke Lampe
Tech W. wrote:

 Can I ask how to call nsupdate in Perl language?
 I know some Perl but not good at it.

The documentation for Net::DNS::Update should get you started. Here's
one example:


use Net::DNS;

my $zone = ixhash.bl.openchaos.org;
my $master = nsig3.hauke-lampe.de.;

my $key_name = update-bl.;
my $key = XXX;

my $update = Net::DNS::Update-new($zone);
my $res = Net::DNS::Resolver-new(
nameservers = [$master],
persistent_udp  = 1,
persistent_tcp  = 1,
recurse = 0,
);

# send update, reset $update object
sub send {
$res-tsig($key_name, $key) if ($key_name);
my $reply = $res-send($update);
if ($reply) {
if ($reply-header-rcode eq 'NOERROR') {
print Update succeeded\n if $debug  0;
} else {
print 'Update failed: ', $reply-header-rcode, \n;
}
} else {
print 'Update failed: ', $res-errorstring, \n;
}
$update = Net::DNS::Update-new($zone);
}



$update-push(pre = nxrrset($hash.$zone A));
$update-push(update = rr_add($hash.$zone 42 A 127.0.0.1));
$update-push(update = rr_add($hash.$zone 42 TXT \timestamp $^T\));
send;



Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Getting dynamic entries into their db files

2009-06-27 Thread Hauke Lampe
Hello John.

Cherney John-CJC030 wrote:

[rndc freeze zone]
 Thanks! I hadn't tried that. I have a problem with that, though. I don't
 know which of my ~600 zones will or won't have dynamic updates.

Well, if there is a .jnl file for a zone, it needs to be flushed. A bit
of shell scripting can generate the rndc freeze and thaw commands.

Dynamic updates issued while a zone is frozen will be lost, unless the
updating application handles the error and retries often enough. So you
probably don't want to freeze zones too long.

 It
 doesn't appear that there is a way to do an rndc freeze on all of my
 zones at once, or pass a wildcard in as the zone name. 

Indeed. I don't know a way to force BIND to write out all zone files
without interrupting normal service. Maybe the folks on bind-users know
more.

AFAIK, the nearest you can get is to set flush-zones-on-shutdown and
restart the nameserver:

| flush-zones-on-shutdown
| When the nameserver exits due receiving SIGTERM, flush or
| do not flush any pending zone writes.
| The default is flush-zones-on-shutdown no.

Also keep in mind that flushing the journal removes IXFR availability up
to the current serial number, although this point shouldn't matter much
if all slaves are already in sync.


I agree with Mark, though, that static backups of dynamic zones are
often useless, except for emergencies where all authoritative servers
lost the zone.

If you restore zones and journals from backup, you lose changes from the
timeframe between the snapshot and restoration and need to force a
retransfer on all slave servers or manually increase the serial number.

It's probably better to sync the current zone from a secondary server
before re-enabling dynamic updates.


Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Trouble With One Domain

2009-06-25 Thread Hauke Lampe
bsfin...@anl.gov wrote:

 There are problems accessing this domain from the Internet, and I cannot
 determine what the problem is.  I have no trouble from Argonne, as the
 domain is slaved on all of my servers.  I do not see any problem with
 the delegations, but I may be missing something.  When I go to

I get SERVFAIL responses from BIND resolvers while Unbound returns an
answer. I think CNAMEs in your delegation could be the cause:

| IllinoisAcceleratorInstitute.org. 86400   IN NS   dns1.aps.anl.gov.
| IllinoisAcceleratorInstitute.org. 86400   IN NS   dns2.aps.anl.gov.

| dns1.aps.anl.gov. 86400   IN  CNAME   t1dns1.aps.anl.gov.
| dns2.aps.anl.gov. 86400   IN  CNAME   t1dns2.aps.anl.gov.

There was a thread about those, just a few days ago on another list:

https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/004126.html
| Does anyone have any knowledge of how well currently deployed DNS
| caches handle NS records pointing to names with CNAME records?
|
|   named fails them deliberately because they cannot work
|   at the theoretical level for all delegation.  You need
|   to change the additional section processing rules for
|   them to work.



Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Zone transfer failing

2009-06-23 Thread Hauke Lampe
Scott Haneda wrote:

 $dig sugardimplesdesigns.com SOA @ns1.hostwizard.com +short

Do you block 53/tcp anywhere on the path to your nameserver?
It rejects TCP queries:

| dig +tcp sugardimplesdesigns.com SOA @ns1.hostwizard.com +short
| ;; Connection to 64.84.37.14#53(64.84.37.14) for
sugardimplesdesigns.com failed: connection refused.

This matches the error log from your secondary:

 Description:
 transfer of 'sugardimplesdesigns.com/IN' from 64.84.37.14#53: failed to
 connect: connection refused

You must allow TCP to port 53 for DNS to function properly.

 Appears to me I am refusing them, I do not see it in my logs, what logs
 would be it in, or what logging statements would I turn on to be able to
 diagnose this?

I would probably first check if the server actually listens on 53/tcp
(with fuser, netstat or similar) and then use tcpdump.



Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Validating a DNSSEC installation

2009-06-13 Thread Hauke Lampe
Erik Lotspeich wrote:

 I now get the AD flag when querying external validating resolvers such
 as the ones you mention.

That's good.
May your signatures never expire and your keys always be valid.

 I believe that my BIND is configured properly to be a validating
 resolver as well:
 
 # dig +adflag @ns.lotspeich.org. isc.org.
 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
 [snip]

Looks good.

 Is it normal that a validating resolver can't validate a domain it is
 authoritative for?

It could but it doesn't, as it implicitly trusts its storage backend.
Instead, you see the AA (authoritative answer) flag instead of AD.

 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

If you want BIND to check signatures and set the AD flag, you would have
to set up views, with the authoritative zones in one view and forwarding
zones in another.


Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: expected a exact match NSEC3, got a covering record

2009-06-13 Thread Hauke Lampe

   --- 9.6.1 released ---
 
 2607. [bug]   named could incorrectly delete NSEC3 records for
   empty nodes when processing a update request.  
   [RT #19749]

I installed 9.6.1 with a cleaned zone and the problem has not reocurred.
Thank you.

 For your information NSEC3 provides no benefit for this zone as it
 has a known structure which can be easily mapped. 

Indeed, I hadn't thought of that. I just wanted to test NSEC3 with
dynamic updates and this RBL zone was an ideal target. It's only queried
by my own servers, so I don't have to worry about resolvers not handling
NSEC3 properly and if anything breaks, it only affects a small part of
spam scoring on the mail gateways.


Hauke.




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Validating a DNSSEC installation

2009-06-11 Thread Hauke Lampe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Erik Lotspeich wrote:

 I have registered with the ISC's DLV registry.  I am
 having trouble finding the best way for me to validate that my setup is
 working and that my zone validates.

dlv.isc.org doesn't list your keys yet. It can take a day or two for DLV
records to appear after your DNSKEY and cookie records have been
checked. If you just added the zone to dlv.isc.org and it still shows a
pending validation state, try request re-check in the DNSKEY Details
section to force immediate validation.

Once your DLV record shows up, you may query external validating
resolvers and see if they set the AD flag in response. OARC operates
resolvers validating against dlv.isc.org. See their website at:
https://www.dns-oarc.net/oarc/services/odvr

dig +adflag lotspeich.org @149.20.64.20
dig +adflag lotspeich.org @149.20.64.21

A successful validation should look like this:
[...]
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 6841
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
[...]  ^^

Future reference: Once .org completes their testing phase *and* your
registrar allows you to register DS records for your domain, queries
should also return AD when validated against the ITAR trust anchor
repository (at https://itar.iana.org/):

dig +adflag lotspeich.org @149.20.64.22

I also run a somewhat-public resolver using the dnssec.iks-jena.de DLV
(http://www.iks-jena.de/leistungen/dnssec.php):

dig +adflag lotspeich.org @85.10.240.255



Hauke.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoxvWsACgkQKIgAG9lfHFPMNgCffasC89jnBB6T2erBR1IN0YLG
O04An27s6qOg9WeW7l8ck6o6E/vmr31F
=gE/Q
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


expected a exact match NSEC3, got a covering record

2009-05-24 Thread Hauke Lampe
Hello.

I run a NSEC3-signed zone with many dynamic updates per day where 
mailservers add RBL records and an hourly cronjob removes old entries.

Several times a day I see queries for nonexistent names in the zone fail.
A typical query might start like this:

| resolver: debug 1: createfetch: 17.245.207.216.spamtraps.bl.openchaos.org A
| resolver: debug 1: createfetch: spamtraps.bl.openchaos.org DNSKEY
| resolver: debug 1: createfetch: 216.spamtraps.bl.openchaos.org DS

The authoritative server then logs

| dnssec: warning: client 85.10.240.254#63666: view authoritative: expected a 
exact match NSEC3, got a covering record

the resolver complains

| lame-servers: info: no valid RRSIG resolving 
'216.spamtraps.bl.openchaos.org/DS/IN': 213.9.73.106#53
| lame-servers: info: no valid DS resolving 
'17.245.207.216.spamtraps.bl.openchaos.org/A/IN': 213.9.73.106#53

and returns SERVFAIL.

The failing names vary over time, as records are added and deleted.

A snapshot of the zone can be downloaded from 
https://www.hauke-lampe.de/temp/spamtrapsbl-20090523.zone (although its 
RRSIGs expire soon), that, loaded into another BIND 9 server, shows the same 
problem as on my authoritative servers when queried for 
17.245.207.216.spamtraps.bl.openchaos.org. So I don't think it has to do 
with caching of NSEC3 records as I suspected at first.

I have tested this with several versions of BIND 9 (9.5.1-P1, 9.6.0, 
9.6.1b1/rc1) on the authoritative side as well as BIND (9.5.1-P1, 9.6.1b1) 
and Unbound 1.2.1 resolving.

What could be the cause of these failures?


Hauke.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users