Re: expected covering NSEC3, got an exact match
On Sep 22 2011, I wrote: There was some correspondence last year about this warning message, but this seems to be caused by something new. Since 2011-09-02 we have been seeing messages like this Sep 22 16:38:52 authdns1.csx.cam.ac.uk named[646]: dnssec: warning: client 149.20.58.131#52557: expected covering NSEC3, got an exact match on both our main authoritative-only (recursion no) nameservers. Our own zones don't use NSEC3, but we do officially slave two that do (srcf.net and srcf.ucam.org) so I have been assuming that they are responsible in some way. But we didn't change anything in the server configuration at the time the messages started, and the zone administrator (hi, Malcolm!) says the same about the contents of the two zones. We were running BIND 9.7.4 at that stage, but upgrading to 9.8.1 hasn't caused the messages to go away, as I had rather hoped. Has anyone any clues about this one? Or observed anything similar? We never did manage to track down exactly what was wrong with the NSEC3 records, but the problem seems to have been cured by the zone signer being upgraded from OpenDNSSEC 1.2.1 to 1.3.2. -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Experience with DDNS (RFC 2136)
At 06 Oct 2011 20:26:48 +0100, Chris Thompson c...@cam.ac.uk wrote: Are you willing to share the stories of your DDNS deployments, maybe including approximate number of zones, records, update frequencies, etc.? We converted all our regular DNS updating operations to use dynamic updates in May 2005, for those zones for which we[*] are master. That's currently 58 zones (many of them small, the largest is cam.ac.uk with c. 5 non-DNSSEC RRs) but would have been a few more then before our reverse zone consolidation exercise. We have never regretted this. We did have some Windows 2000 DNS Server stealth slaves that had to be given provide-ixfr no settings because they ed up applying incremental transfers, but they've all gone now (thank $DEITY). We already had most of the input to our DNS zone content generated from an external database (even more so now), but I don't think that was critical. Deciding to write a compare two zone files and generate nsupdate input to convert one to the other Perl script was. Maybe an off topic in this thread, but out of curiosity, is there any specific reason you don't use the database as the direct source of the zone with BIND 9's dlz or PowerDNS? In general it will be slower, and DNSSEC signing might be an issue in that setup, but on the other hand updates will be reflected immediately, (at least in theory) no need for worrying about consistency, no need for additional script or DDNS setups, and (although this may not be an issue with 58 zones w/ max 50K RRs/zone) no need for waiting on reload. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ 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
nsupdate on a Windows ec2 instance to update dynamic DNS isn't working
hello, i'm trying to update dynamic DNS for my windows ec2 instance by running BIND's nsupdate from the instance. it's not working. i'll show details below. anyone have any idea what's going on? what else i should look at or try? * nsupdate command reports no error * my BIND nameserver never sees the packets * running wireshark on the windows instance itself shows me it's not sending any packets to the nameserver * the Windows Firewall Service is not running * the windows instance runs Windows Server 2003, Datacenter Edition, R2 i do know the nameserver is set up correctly in that my linux instances are able to update dynamic dns using nsupdate against this nameserver. contents of update.txt: server 10.x.x.x zone dev.sushimysavior.com update delete SOUS-CHEF-WIN.dev.sushimysavior.com. A update add SOUS-CHEF-WIN.dev.sushimysavior.com. 86400 IN A 10.y.y.y show debug send in case it is necessary, i have a resolv.conf in place at C:\WINDOWS\system32\drivers\etc\resolv.conf that contains: nameserver 10.x.x.x and here's the nsupdate command run: C:\work\binC:\WINDOWS\system32\dns\bin\nsupdate.exe -k C:\WINDOWS\system32\dns\etc\Kuser-ddns-ec2.sushimysavior.com.+157+14445.key -v -d -D -L 2 C:\WINDOWS\system32\dns\etc\update.txt setup_system() Creating key... reset_system() user_interaction() get_next_command() get_next_command() get_next_command() evaluate_update() update_addordelete() get_next_command() evaluate_update() update_addordelete() get_next_command() show_message() Outgoing update query: ;; -HEADER- opcode: UPDATE, status: NOERROR, id: 0 ;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; ZONE SECTION: ;dev.sushimysavior.com. IN SOA ;; UPDATE SECTION: SOUS-CHEF-WIN.dev.sushimysavior.com. 0 ANY A SOUS-CHEF-WIN.dev.sushimysavior.com. 86400 IN A 10.y.y.y get_next_command() get_next_command() cleanup() Shutting down task manager shutdown_program() Shutting down request manager Freeing TSIG key Destroy DST lib Destroying request manager Freeing the dispatchers Shutting down dispatch manager Destroying event Shutting down socket manager Shutting down timer manager Destroying hash context Destroying name state Removing log context Destroying memory context C:\work\bin thanks! kallen ___ 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: Experience with DDNS (RFC 2136)
On 10/07/2011 06:43 PM, JINMEI Tatuya / 神明達哉 wrote: Maybe an off topic in this thread, but out of curiosity, is there any specific reason you don't use the database as the direct source of the zone with BIND 9's dlz or PowerDNS? In general it will be slower, and I can't speak for Chris but here, we rejected DLZ and similar because: 1. DNSSEC 2. Speed 3. Impedance mismatch between database schema and DNS 4. Perceived second-class status of DLZ 5. Loss of various things that are automatic if using zones (IXFR) 6. Too-tight coupling between the SQL DB and DNS Of all of them, #1 and #6 were probably the most important. Using a decent programming language to map your SQL into DNS means you get arbitrary flexibility. Having to shoehorn it into a small set of SQL queries denies you that. Personally, even if bind were to use SQL for its own zone storage, I'd still separate the two. Loosely coupled systems are good. DNSSEC signing might be an issue in that setup, but on the other hand updates will be reflected immediately, (at least in theory) no need It's pretty trivial to use triggers to push updates via DDNS if you're so inclined. for worrying about consistency, no need for additional script or DDNS setups, and (although this may not be an issue with 58 zones w/ max 50K RRs/zone) no need for waiting on reload. There are no reloads with DDNS zones, so I'm not sure I follow you. ___ 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 config sanity check
On 10/5/2011 10:25 AM, michoski wrote: Your initial hope is what I missed comments on... Me too; didn't get any that's horribly broken because or any that looks good feedback, guess I'll just have to review it a couple more times and hope for the best. It is recommended that the transition of a KSK from the published state to the ready state (introduction time) lasts for 45 days (RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors). If the parent of the zone is signed, the recommended introduction time (SPARTA) is one week. The recommended period during which a KSK is retired before it is removed from the zone (retirement time) is four weeks. For the ZSK, the recommended introduction time is four days and the retirement time is two weeks. What values are other folks using? I'm not sure why such a long retirement time is recommended, particularly for the ZSK which has no dependencies on getting a parent zone to update anything. For the KSK, you don't want to use it to sign anything until the parent has published the DS record, any old cached copies of that set without the new one have expired, you've published the DNSKEY record, and any old cached copies of that set have expired. For my case, I am publishing the KSK for an entire year before using it, so can't see any issues there. You don't want to remove a KSK until the parent has removed the corresponding DS record, cached copies have expired, and there are no longer any signatures floating around signed by it. My TTL is only 12 hours, so keeping it around for two weeks after I stop using it seems more than sufficient (and if for some reason there is an excessive delay getting the parent to remove the DS record, I can extend the publication further). For the ZSK, you don't want to sign anything with it after publication until you are sure there are no old cached copies of the set floating around without it. I'm going to publish the ZSK one month in advance of using it, so again don't see any issues. You don't want to remove it while there are potentially any cached signatures floating around that use it. Again with a TTL of 12 hours, two days seems like it should be a sufficient interval to wait. You don't want your signature lifetime to be too short, resulting in expired signatures before new ones are generated. My signature lifetime will be 35 days, with a forced signing at least once a month on the first of the month, along with a fresh signing anytime the backend data changes. So I don't see a scenario where my signatures would expire. The only edge case I can see that might cause a failure is if my primary server dies or there is an issue transferring the new zone to secondaries towards the end of the month. Hypothetically, if the underlying data doesn't change, and the zone was only signed on the first of the month, and an issue arises say the last week of the month, there is a case where it is possible my secondaries will have a copy of the zone that hasn't expired yet, but which does not have valid signatures. I'm willing to live with this possibility, as the likelihood of such a failure is low, and the likelihood it would be resolved quickly is high :). I guess if I missed anything at some point maybe Stephane Bortzmeyer will be contacting me to let me know my dnssec deployment is broken and asking what tool I'm using ;)... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ 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: Experience with DDNS (RFC 2136)
1. DNSSEC Of all of them, #1 and #6 were probably the most important. Note that this will be less of an issue in BIND 9.9: you can set up a DLZ master and configure a slave to do inline signing. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
