Description of problem: BIND releases prior to 9.6 do not support RSASHA1-NSEC3-SHA1 (Algorithm 7) which is used by the .GOV TLD for DNSSEC. Further, enabling dlv.isc.org as an dnssec-lookaside breaks .GOV TLD lookups with SERVFAIL as dlv.isc.org now includes the .GOV TLD DNSKEY records. Version-Release number of selected component (if applicable): Less than BIND 9.6. Specific test below with latest 9.3.4-10.P1. How reproducible: Method 1: Enable dnssec, add GOV TLD DNSKEY, service named [re]start, "algorithm is unsupported". Method 2: Enable dnssec, add dlv.isc.org dnskey-lookaside, add dlv.isc.org DNSKEY, service named [re]start, try to resolve .GOV domain, SERVFAIL. Steps to Reproduce: Method 1: 1. Enable dnssec by adding to named.conf: options { dnssec-enable yes; } 2. Add GOV TLD DNSKEY to named.conf: trusted-keys { GOV. 257 3 7 "AwEAAZ1OCt7zZxeaROvzXNCNlqQWIi++p5ABXSoxqJ65WQko6xrI9RImK7IBT5roFhXjBDGJ8ld9CYIEN94kK83K/QwUGCJ+v3vIQFi09IqsPeRdHTQyghWWb hzAZpnlZ16imXB4yFZjdbV2iM66KcgsESQMPEcIayDQJh6JEi1wmslrYvRRJ6YPOWrlLD0RmdtCaRuzlUE0RiWSem/i8vDFdmsSwChRMcORklKqjqt1+RBIiEFJGKIz7lGc9DXRwkB fb+halii+jrELiZAPzfO7rf08l3QlgHEuxclTTdEaxctPd2O2U/Hl9tRgkxRL/Zv1i0sEx2mOJGcUCeVm4Hf2aM8="; }; 3. Restart named with "service named restart" /var/log/messages reports: /etc/named.conf:[line]: configuring trusted key for 'GOV.': algorithm is unsupported Method 2. 1. Enable dnssec by adding to named.conf: options { dnssec-enable yes; } 2. Add dlv to to named.conf: options { dnssec-lookaside "." trust-anchor dlv.isc.org.; } 3. Add dlv.isc.org DNSSEC KEY to named.conf: trusted-keys { dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2 brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+ 1 uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5 ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk Y62ZfkLoBAADLHQ9IrS2tryAe 7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh"; }; 4. Restart named with "service named restart" 5. dig soa gov @localhost SERVFAIL Actual results: Method 1: /var/log/messages reports: /etc/named.conf:[line]: configuring trusted key for 'GOV.': algorithm is unsupported Method 2: $ dig ns gov @localhost ; <<>> DiG 9.3.4-P1 <<>> ns gov @localhost ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41204 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;gov. IN NS ;; Query time: 2115 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jun 3 15:33:49 2009 ;; MSG SIZE rcvd: 21 Expected results: Specific to Method 1. named restart with no errors Both methods: dig soa gov @localhost with results. Details below: $ dig soa gov @localhost ; <<>> DiG 9.6.1rc1-RedHat-9.6.1-0.4.rc1.fc11 <<>> soa gov @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 731 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;gov. IN SOA ;; ANSWER SECTION: gov. 86400 IN SOA A.GOV.ZONEEDIT.COM. govcontact.ZONEEDIT.COM. 1244062865 3600 900 1814400 86400 ;; AUTHORITY SECTION: gov. 172799 IN NS c.GOV.ZONEEDIT.COM. gov. 172799 IN NS A.GOV.ZONEEDIT.COM. gov. 172799 IN NS e.GOV.ZONEEDIT.COM. gov. 172799 IN NS d.GOV.ZONEEDIT.COM. gov. 172799 IN NS f.GOV.ZONEEDIT.COM. gov. 172799 IN NS b.GOV.ZONEEDIT.COM. gov. 172799 IN NS g.GOV.ZONEEDIT.COM. ;; Query time: 356 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Jun 3 16:02:26 2009 ;; MSG SIZE rcvd: 196 Next, try a query asking specifically for the ad flag (authenticated data): $ dig +adflag ns gov @localhost ; <<>> DiG 9.6.1rc1-RedHat-9.6.1-0.4.rc1.fc11 <<>> +adflag soa gov @localhost ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25333 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 0 ;; QUESTION SECTION: ;gov. IN SOA ;; ANSWER SECTION: gov. 86386 IN SOA A.GOV.ZONEEDIT.COM. govcontact.ZONEEDIT.COM. 1244062865 3600 900 1814400 86400 ;; AUTHORITY SECTION: gov. 172785 IN NS c.GOV.ZONEEDIT.COM. gov. 172785 IN NS g.GOV.ZONEEDIT.COM. gov. 172785 IN NS b.GOV.ZONEEDIT.COM. gov. 172785 IN NS A.GOV.ZONEEDIT.COM. gov. 172785 IN NS f.GOV.ZONEEDIT.COM. gov. 172785 IN NS e.GOV.ZONEEDIT.COM. gov. 172785 IN NS d.GOV.ZONEEDIT.COM. ;; Query time: 33 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Jun 3 16:02:40 2009 ;; MSG SIZE rcvd: 196 Additional info: Algorithm 7 is RSASHA1-NSEC3-SHA1, see http://www.iana.org/assignments/dns-sec-alg-numbers/ BIND didn't gain NSEC3 support until 9.6.0, see https://www.isc.org/software/bind/new-features/9.6 DNSSEC is mandated by the OMB for use by US Federal Government Agencies by December, 2009. Sources: http://en.wikipedia.org/wiki/DNSSEC#DNSSEC_deployment_in_the_U.S._federal_government http://www.govsecinfo.com/the-keys-to-deploying-dnssec.html http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf "The Federal Government will deploy DNSSEC to the top level .gov domain by January 2009... Appropriate DNSSEC capabilities must be deployed and operational [for second-level domains] by December 2009." While there is no DNSSEC requirement for NSEC3 for second-level domains, the .GOV TLD is NSEC3 signed. Current BIND Resolvers with versions less than 9.6 cannot validate the .GOV TLD. "All validators should understand NSEC3 due to the fact that some large zones will be using NSEC3, so resolvers and validators will have to understand NSEC3 responses to fully function." http://www.dnsops.gov/vendors/ Other references regarding this issue: https://lists.dns-oarc.net/pipermail/dns-operations/2009-March/003638.html The other option for use of dlv.isc.org without breaking zones using NSEC3 is to correct the "no supported algorithm" response. In other words, resolve the domain as insecure (as if there were no DNSSEC records), so long as the +adflag or +dnssec flags are not present in the query. There is presently no BIND 9.3 patch available for this, but there is for BIND 9.4 & 9.5 https://lists.isc.org/pipermail/bind-announce/2009-March/000590.html Even if a BIND a 9.3 patch were available, the best option would be to move to the current 9.6 code for NSEC3 support, not just a bugfix to ignore it.
Complete NSEC3 support is non trivial task and won't be available soon. Usage of 9.6 codebase is not possible because there are many configuration incompatibilies between 9.3 and 9.6 (at least default ACLs). For now named will handle data signed with unknown algorithm as unsigned data. If you are interested in complete NSEC3 support open a ticket in issue tracker or contact your support representative, please.
*** This bug has been marked as a duplicate of bug 504794 ***