Re: SERVFAIL debugging
JINMEI Tatuya / 神明達哉 wrote: At Mon, 22 Jun 2009 13:30:42 +0400, Dmitry Rybin kirg...@corbina.net wrote: Please try 9.6.1b1, which we expect to be released next week. It has a new experimental feature just for that purpose: Is this feature going to be back ported to 9.4 and 9.5 releases as well? For 9.5, yes. For 9.4, not according to the current plan. named[87071]: 22-Jun-2009 13:18:23.256 query-errors: debug 2: fetch completed at resolver.c:6569 for static.cache.l.google.com/A in 0.041364: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Which version of BIND9 is this? To match the line number we need the exact version number. --- JINMEI, Tatuya Internet Systems Consortium, Inc. FreeBSD 7.2-STABLE, bind from ports bind96-9.6.1 version: 9.6.1 CPUs found: 8 worker threads: 6 number of zones: 1258 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 3 query logging is OFF recursive clients: 162/1900/2000 tcp clients: 0/100 server is up and running It one of 3 other dns servers, and after update to 9.6.1 from 9.6.0 I have an error, then allocated by the bind memory grows more 2,5-3 gb. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer failing
On Jun 23, 2009, at 3:16 PM, Scott Haneda wrote: Good observation. This is a long standing issue that I assumed was solved. Named on OS X will go deaf on port 53 tcp for some reason. I just kicked it, and now I can tcp dig it. $dig +tcp sugardimplesdesigns.com SOA @ns1.hostwizard.com +short ns1.hostwizard.com. scott.hostwizard.com. 2009062206 28800 7200 2419200 3600 I now the men and mice guys are familiar with this, if you guys are reading, have you ever pinned this down, or found a solution to it? No, we have not. However, it appears to be related to the port being idle for some time. Servers that use their TCP port more frequently, usually due to having lots of zone updates that need to be replicated to slaves, don't appear to be affected. You might try creating a cron job that digs against the TCP port every 5 minutes to try to keep the port active and prevent it from gong deaf. I could be wrong, but I seem to recall that we've seen this on other operating systems as well, although the lion's share of reports have been with Mac OS X. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Re: Support of HIP RR (RFC 5205)
Does anybody know if (or when) BIND supports HIP (RFC5205) resource records ? It's in BIND 9.7. BIND 9.7.0a1 is in the process of being prepared. 2565. [func] Add support for HIP record. Includes new functions dns_rdata_hip_first(), dns_rdata_hip_next() and dns_rdata_hip_current(). [RT #19384] Mark Thanks a lot, works fine. Holger ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: can't query for RRSIG that references NSEC3
On Jun 24 2009, Jack Tavares wrote: a correction: my dig command is dig @127.0.0.1 -t RRSIG 4PPH7Q8R02M0AD8MLJPS0UEH2AB9KFJL.test.net and I still get NXDOMAIN NSEC3 records (and their associated RRSIG records) are, in a sense, not properly part of the zone. RFC 5155 section 7,2,8 Responding to Queries for NSEC3 Owner Names mandates the response you are seeing. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.0a1 and dnssec-signzone verification
I have some issues with dnssec-signzone under BIND 9.7.0a1. I'm using different algorithms for key- and zone signing keys. This is the list of currently used keys: $ dnssec-zkt . Keyname Tag Typ Sta Algorit Generation Time sub.example.de. 56595 KSK act RSASHA1 Oct 03 2008 23:27:15 sub.example.de. 40956 KSK act RSASHA1 Oct 03 2008 01:02:19 sub.example.de. 26451 KSK act RSASHA1 Jun 15 2009 08:58:26 sub.example.de. 11091 ZSK pub RSAMD5 Jun 24 2009 17:12:33 sub.example.de. 38598 ZSK act RSAMD5 Jun 15 2009 08:56:24 Signing the zone with dnssec-signzone and *not* turning off the verification of the zone (via -P), gives me a lot of error messages: $ dnssec-signzone -o sub.example.de zone.db Verifying the zone using the following algorithms: RSASHA1. Missing self signing KSK for algorithm RSAMD5 Missing ZSK for algorithm RSASHA1 Missing RSASHA1 signature for sub.example.de NSEC Missing RSASHA1 signature for sub.example.de SOA Missing RSASHA1 signature for sub.example.de NS Missing RSASHA1 signature for a.sub.example.de NSEC Missing RSASHA1 signature for a.sub.example.de A Missing RSASHA1 signature for b.sub.example.de NSEC Missing RSASHA1 signature for b.sub.example.de A Missing RSASHA1 signature for c.sub.example.de NSEC Missing RSASHA1 signature for c.sub.example.de A Missing RSASHA1 signature for localhost.sub.example.de NSEC Missing RSASHA1 signature for localhost.sub.example.de A The zone is not fully signed for the following algorithms: RSAMD5 RSASHA1. dnssec-signzone: fatal: DNSSEC completeness test failed. Does it mean that it is no longer possible to use different key algorithms in one zone? Thanks Holger ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: can't query for RRSIG that references NSEC3
Thanks. I obviously missed that part of the rfc. -- Jack Tavares From: Chris Thompson [c...@hermes.cam.ac.uk] On Behalf Of Chris Thompson [c...@cam.ac.uk] Sent: Wednesday, June 24, 2009 18:44 To: Jack Tavares Cc: Bind Users Mailing List Subject: RE: can't query for RRSIG that references NSEC3 On Jun 24 2009, Jack Tavares wrote: a correction: my dig command is dig @127.0.0.1 -t RRSIG 4PPH7Q8R02M0AD8MLJPS0UEH2AB9KFJL.test.net and I still get NXDOMAIN NSEC3 records (and their associated RRSIG records) are, in a sense, not properly part of the zone. RFC 5155 section 7,2,8 Responding to Queries for NSEC3 Owner Names mandates the response you are seeing. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL debugging
At Wed, 24 Jun 2009 10:13:51 +0400, Dmitry Rybin kirg...@corbina.net wrote: new experimental feature just for that purpose: Is this feature going to be back ported to 9.4 and 9.5 releases as well? For 9.5, yes. For 9.4, not according to the current plan. named[87071]: 22-Jun-2009 13:18:23.256 query-errors: debug 2: fetch completed at resolver.c:6569 for static.cache.l.google.com/A in 0.041364: SERVFAIL/success [domain:com,referral:1,restart:0,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] Which version of BIND9 is this? To match the line number we need the exact version number. FreeBSD 7.2-STABLE, bind from ports bind96-9.6.1 Okay, then the above log strongly suggests that the cache is full in some unusual way and even recently fetched RR (which is in this case NS for google.com) has been purged before it's actually used. There have been bugs that could cause this symptom, but all known problems should have been solved in 9.6.1. So, I have no specific idea about how exactly that happened. Can you provide the following information? - your complete named.conf - if you enable statistics-channel, its output when you see this trouble - the result of rndc dump when you see this trouble (note: rndc dump purges stale cache entries as a side effect and may hide the cause. It will still help investigate the problem) If you think it's sensitive please contact me offlist. Thanks, --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer failing
On Jun 24, 2009, at 1:54 AM, Scott Haneda wrote: On Jun 23, 2009, at 11:57 PM, Chris Buxton wrote: On Jun 23, 2009, at 3:16 PM, Scott Haneda wrote: Good observation. This is a long standing issue that I assumed was solved. Named on OS X will go deaf on port 53 tcp for some reason. I just kicked it, and now I can tcp dig it. $dig +tcp sugardimplesdesigns.com SOA @ns1.hostwizard.com +short ns1.hostwizard.com. scott.hostwizard.com. 2009062206 28800 7200 2419200 3600 I now the men and mice guys are familiar with this, if you guys are reading, have you ever pinned this down, or found a solution to it? No, we have not. However, it appears to be related to the port being idle for some time. Servers that use their TCP port more frequently, usually due to having lots of zone updates that need to be replicated to slaves, don't appear to be affected. You might try creating a cron job that digs against the TCP port every 5 minutes to try to keep the port active and prevent it from gong deaf. I could be wrong, but I seem to recall that we've seen this on other operating systems as well, although the lion's share of reports have been with Mac OS X. In your estimation, a named/BIND bug, or OS level bug? How would one go about finding out, and working it out, so we can solve this? I can certainly and very easily shove a launchd job in to run every 5 minutes, and do not even consider it much of a kludge, but would like to solve it for others, as it is a bear to track down. I'm not really qualified to determine where the bug is, but I would guess there's a bug in the IP stack that most other server software doesn't trigger. Perhaps ISC could find a way to work around it, or perhaps Apple could fix it. My WAG is that Apple inherited this bug from *BSD, from which large portions of the Darwin kernel are (or at least were) derived. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.0a1 and dnssec-signzone verification
On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote: I have some issues with dnssec-signzone under BIND 9.7.0a1. I'm using different algorithms for key- and zone signing keys. That's a problem. Does it mean that it is no longer possible to use different key algorithms in one zone? You can use multiple algorithms in a zone, but each algorithm must be represented as both KSK and ZSK. If you have an RSASHA1 KSK, an RSAMD5 KSK, an RSASHA1 ZSK and an RSAMD5 ZSK, you'll be fine. But if all your KSKs are RSASHA1 and all your ZSK's are RSAMD5, that's actually a protocol violation. dnssec-signzone should have been complaining all along; it was a bug that it didn't. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.0a1 and dnssec-signzone verification
At Wed, 24 Jun 2009 18:23:52 +, Evan Hunt wrote: On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote: I have some issues with dnssec-signzone under BIND 9.7.0a1. I'm using different algorithms for key- and zone signing keys. You can use multiple algorithms in a zone, but each algorithm must be represented as both KSK and ZSK. If you have an RSASHA1 KSK, an RSAMD5 KSK, an RSASHA1 ZSK and an RSAMD5 ZSK, you'll be fine. But if all your KSKs are RSASHA1 and all your ZSK's are RSAMD5, that's actually a protocol violation. dnssec-signzone should have been complaining all along; it was a bug that it didn't. Evan's rule (that the KSK and ZSK algorithms should match) is correct, but the reasons are a bit (more) complex. The protocol requirement is that every signed RRset in a zone have an RRSIG for each algorithm listed in the zone's DS RRset in the parent. A simpler way of saying this is that every KSK algorithm in a zone must also be a ZSK algorithm. Note that this has nothing to do with the SEP bit in the DNSKEY RRs, only to do with which keys sign which RRsets (the protocol forbids the validator from using the SEP bit). The validator allows ZSK algorithms which are not KSK algorithms, but signing your zone that way leaves you vulnerable to the same algorithm downgrade attack that resulted in the seemingly bizzare protocol requirement noted above. So don't do that. Allowing ZSK algorithms that aren't KSK algorithms is useful during certain transitions, but you don't want verification to rely on mismatched algorithms. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone transfer failing
In message dc7c615c-b326-461a-9257-65cd3ba06...@menandmice.com, Chris Buxton writes: On Jun 24, 2009, at 1:54 AM, Scott Haneda wrote: On Jun 23, 2009, at 11:57 PM, Chris Buxton wrote: On Jun 23, 2009, at 3:16 PM, Scott Haneda wrote: Good observation. This is a long standing issue that I assumed was solved. Named on OS X will go deaf on port 53 tcp for some reason. I just kicked it, and now I can tcp dig it. $dig +tcp sugardimplesdesigns.com SOA @ns1.hostwizard.com +short ns1.hostwizard.com. scott.hostwizard.com. 2009062206 28800 7200 2419200 3600 I now the men and mice guys are familiar with this, if you guys are reading, have you ever pinned this down, or found a solution to it? No, we have not. However, it appears to be related to the port being idle for some time. Servers that use their TCP port more frequently, usually due to having lots of zone updates that need to be replicated to slaves, don't appear to be affected. You might try creating a cron job that digs against the TCP port every 5 minutes to try to keep the port active and prevent it from gong deaf. I could be wrong, but I seem to recall that we've seen this on other operating systems as well, although the lion's share of reports have been with Mac OS X. In your estimation, a named/BIND bug, or OS level bug? How would one go about finding out, and working it out, so we can solve this? I can certainly and very easily shove a launchd job in to run every 5 minutes, and do not even consider it much of a kludge, but would like to solve it for others, as it is a bear to track down. I'm not really qualified to determine where the bug is, but I would guess there's a bug in the IP stack that most other server software doesn't trigger. Perhaps ISC could find a way to work around it, or perhaps Apple could fix it. It's a matter of reproducing it. I suspect there is a unhandled / unexpected error code being returned. Alternatively the interface disappears for a while, so we close the socket, and we can't re-bind to it when it re-appears because we no-longer have permissions to do so when running with -u. If Apple, or anyone else for that matter, has fine grain permissions which will allow the ability to bind(2) to a reserved port as a ordinary user like Linux capability code does we would be happy to receive patches. If it is a re-binding issue the running without -u will address that. My WAG is that Apple inherited this bug from *BSD, from which large portions of the Darwin kernel are (or at least were) derived. I doubt that as named has always worked fine on the BSD kernel Apple used to start Darwin. Mark Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.0a1 and dnssec-signzone verification
In message 20090624211854.a3be222...@thrintun.hactrn.net, Rob Austein writes: At Wed, 24 Jun 2009 18:23:52 +, Evan Hunt wrote: On Wed, Jun 24, 2009 at 05:45:33PM +0200, holger.zule...@arcor.net wrote: I have some issues with dnssec-signzone under BIND 9.7.0a1. I'm using different algorithms for key- and zone signing keys. You can use multiple algorithms in a zone, but each algorithm must be represented as both KSK and ZSK. If you have an RSASHA1 KSK, an RSAMD5 KSK, an RSASHA1 ZSK and an RSAMD5 ZSK, you'll be fine. But if all your KSKs are RSASHA1 and all your ZSK's are RSAMD5, that's actually a protocol violation. dnssec-signzone should have been complaining all along; it was a bug that it didn't. Evan's rule (that the KSK and ZSK algorithms should match) is correct, but the reasons are a bit (more) complex. The protocol requirement is that every signed RRset in a zone have an RRSIG for each algorithm listed in the zone's DS RRset in the parent. A simpler way of saying this is that every KSK algorithm in a zone must also be a ZSK algorithm. Note that this has nothing to do with the SEP bit in the DNSKEY RRs, only to do with which keys sign which RRsets (the protocol forbids the validator from using the SEP bit). The validator allows ZSK algorithms which are not KSK algorithms, but signing your zone that way leaves you vulnerable to the same algorithm downgrade attack that resulted in the seemingly bizzare protocol requirement noted above. So don't do that. Allowing ZSK algorithms that aren't KSK algorithms is useful during certain transitions, but you don't want verification to rely on mismatched algorithms. Not so much a downgrade attack but validation failures may result if you have a algorithm listed in the DS that are not used to sign all the RRsets in the zone. Preventing downgrade attacks are not a DNSSEC design goal as it is any key validates. That being said you can have a validator that has policy knobs which aren't part of the DNSSEC design goals but can be realised as a side effect of trying to ensure that you have valid signatures for each algorithm. Holger if you build dnssec-signzone with ALLOW_KSKLESS_ZONES defined then the set of algorithms with self-signed DNSKEY records will be used. You will still get complains because you don't have a non KSK key for RSASHA1. You appear to be moving from a KSK less use of RSAMD5 to KSK aware use of RSASHA1 and are in the pre-publish phase with RSASHA1 keys. This isn't covered by the verifier. I would add a non-KSK for RSASHA1 and set ALLOW_KSKLESS_ZONES to allow this transition to pass the verifier. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
