Re: response case in-sensitivity?
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)
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)
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 2>&1|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
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
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: Querying directly a nameserver works, while forwarding not
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: dnssec-keygen not responding
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
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
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: DNSSEC not populating parent zone files with DS records
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: "auto-dnssec maintain" stoped working again...
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: NXDOMAIN redirection in BIND 9.9
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: NXDOMAIN redirection in BIND 9.9
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: Bug in bind 9.7.3?
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
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
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: Telling rndc Which IP Address to Use
-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: DNSSEC auto-dnssec issue bind-9.7.2-P3
-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: Pushed transfer to slave fails
Hi Stewart.
> SLAVE (10.5.0.6)
> transfer-source 10.5.0.5;
>
> zone "bard.edu" {
> masters { 10.5.0.5; };
> transfer-source 10.5.0.5;
transfer-source should probably be 10.5.0.6, not .5
> Jan 13 12:37:37 nsi1 named[21007]: zone bard.edu/IN/internal: notify to
> 10.5.0.6#53: retries exceeded
"retries exceeded" means that the master server didn't receive any response
from the slave to its notify queries. Watching the packet flow with tcpdump
might give a hint where queries or replies disappear. Is there any kind of
packet filter between the servers that would let queries pass but filters
notifies?
When you queried the slave from the master server, did you specify the source
address (dig -b 10.5.0.5)?
HTH,
Hauke
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Unable to query the nameserver
-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
> 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
-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: www.ncbi.nlm.nih.gov / pubmed
On 18.08.2010 14:31, Phil Mayers wrote: > After a bit of investigation, it seems that the problem is a missing > NSEC/NSEC3 record in the empty reply for: > > $ dig +dnssec @165.112.4.230 ncbi.nlm.nih.gov ds > > ...since the "ncbi" zone is an unsigned child zone, there needs to be an > NSEC/NSEC3 record to prove the absence of the DS record, and have a > secure delegation to an unsigned child zone. I think the problem is already in the nlm.nih.gov zone. nih.gov contains DS records for nlm.nih.gov, but the zone itself is not signed. dig +dnssec nlm.nih.gov ds @ns.nih.gov. -> signed DS records dig +dnssec nlm.nih.gov soa @ns.nih.gov. -> unsigned response Validating resolvers thus reject the unsigned answer: "nlm.nih.gov SOA: got insecure response; parent indicates it should be secure" According to the SOA, nlmdnshostmas...@mail.nih.gov is the appropriate contact address. I'll put them in Cc. 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: «tsig verify failure» only on some zones
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
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
- 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
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{}?
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
- 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)
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
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
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: 9.7.0-P1 managed-keys.bind issues
Mark Watts wrote: > Apr 14 12:06:34 dns01 named[4911]: zone managed-keys.bind/IN/_meta: > sync_keyzone:dns_journal_open -> unexpected error Does named have permission to create files in the directory specified by "directory" in the options block? BIND uses an internal dynamic zone for RFC5011-updated trust anchors and needs to write zone and journal files in its work directory. 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
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?
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: Cannot use dnssec-settime with old keys
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: OpenDNS today announced it has adopted DNSCurve to secure DNS
Stephane Bortzmeyer wrote: > Sam Wilson 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: Poblem with ZONE (subdomain)
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
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
[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 > > unbound: [968:0] info: ce candidate 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
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: DNSSEC Bogus NXDOMAIN survives authenticating RR
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: Split view logging?
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
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?
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?
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
Disabling DNSSEC validation per zone?
I am looking for way to disable DNSSEC lookaside validation for a given zone. Would this be possible with BIND already or do I need to file a feature request (and where)? My reason is that we use a zone "example.net" for internal hosts, served by an internal nameserver and configured as a "forward" zone on the resolvers. 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. BIND has a configuration setting which does something similar: | dnssec-must-be-secure | Specify hierarchies which must be or may not be secure (signed and | validated). If yes, then named will only accept answers if they | are secure. If no, then normal DNSSEC validation applies allowing | for insecure answers to be accepted. The specified domain must be | under a trusted-key or dnssec-lookaside must be active. I'd like to have a third option to disable normal DNSSEC validation for a known-insecure zone. On a related note, will the ISC's DLV zone be available for AXFR? It used to be but isn't anymore. Because of the importance of DLV for any name resolution (it effectively is a root zone), I would like to mirror the zone on my own servers and configure the resolvers to use them in a "forward first" configuration. 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"?
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
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
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
Hello John. Cherney John-CJC030 wrote: [rndc freeze ] > 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
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
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: "expected a exact match NSEC3, got a covering record"
> --- 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
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: Validating a DNSSEC installation
On Fri, Jun 12, 2009 at 04:29:11 +0200, Hauke Lampe wrote: > 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 got that one wrong. My apologies. That resolver uses IANA's version of a signed root (https://ns.iana.org/), not ITAR. Personally, I don't expect to add DS records for my .org domains within the next two or three years, anyway. By the time the domain registration services I use add working DS support, the root zone could possibly already be signed. Hauke. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Validating a DNSSEC installation
-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"
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
