Changes between Version 4 and Version 5 of LargeScaleDNSSECBCP

Timestamp:

07/08/12 21:54:40 (11 months ago)

Author:

ahu

Comment:

--

LargeScaleDNSSECBCP

@@ +1 @@
+= Large Scale DNSSEC Best Current Practices (or 'Best Current Problems') =
+This is a list of things we have noticed during several large scale PowerDNS DNNSEC migrations. 
+
+== 100% PowerDNS related == 
+
  * Do NOT use PowerDNS 3.0 or 3.0.1 for large scale DNSSEC, it has too many
    bugs.  The documentation already mentions this, but we will be
@@ -14 +19 @@
    binaries and dynamic gethostbyname NSS calls.
 
+ * Either stay close to default PowerDNS DNSSEC parameters or consult an expert
+   Test your parameters aginst http://dnsviz.net/ and http://dnssec-debugger.verisignlabs.com/.
+
+ * Updating from PowerDNS 2.9.x to 3.1 requires a database schema upgrade. Not performing the upgrade can lead to silent failures.
+   Please consult http://doc.powerdns.com/upgrades.html#from2.9to3.0 and http://doc.powerdns.com/from3.0to3.1.html relevant.
+
+ * At all times, keep the 'auth' and 'ordername' fields in the database correct, or run 'pdnssec rectify-zone' on changes.
+   Read http://doc.powerdns.com/dnssec-modes.html#dnssec-direct-database for more details.
+
+ * You seriously need to run 'pdnssec check-all-zones'. If an RR has a
+   one broken record in it, the entire RRSET can not be signed. This leads
+   to pain. In addition, PowerDNS sometimes reacts badly to trying to sign
+   broken records.
+
+== Somewhat PowerDNS related ==
+
+ * Stay away from mixed authoritative and recursive operation on one IP address. Not only does this make life complicated, PowerDNS with 
+   DNSSEC appears to have some bugs in this area.
+
+ * When using slaves that AXFR your signed zones, be sure that your slaves actually support serving DNSSEC. Some servers will gladly
+   AXFR a signed zone, but not perform DNSSEC processing on it. This goes for PowerDNS 2.9.x
+
+ * Key rollovers. PowerDNS automatically renews the RRSIGs (the signatures for your DNS data), so you don't need to do anything. There are documents which tell you to roll your DNS keys frequently, although it is now believed such automatic rolling is not required. In any case, if you are doing a large scale migration, it is advised to initially not roll keys until the dust has settled.
+
+== Generic DNSSEC related == 
+
  * Do not secure zones which you don't run yourself! A common scenario is
    where you have company.hu still on your servers, and you are still the
@@ -27 +58 @@
    graph on http://xs.powerdns.com/dnssec-nl-graph/
 
- * You seriously need to run 'pdnssec check-all-zones'. If an RR has a
-   one broken record in it, the entire RRSET can not be signed. This leads
-   to pain. In addition, PowerDNS sometimes reacts badly to trying to sign
-   broken records.
-
  * Make sure your network is stable. It turns out that various versions of
    BIND respond to timeouts to your server by declaring it as not supporting
@@ -41 +67 @@
    subject.
 
- * Either stay close to default PowerDNS DNSSEC parameters or consult an expert
-   Test your parameters aginst http://dnsviz.net/ and http://dnssec-debugger.verisignlabs.com/.
-
- * Updating from PowerDNS 2.9.x to 3.1 requires a database schema upgrade. Not performing the upgrade can lead to silent failures.
-   Please consult http://doc.powerdns.com/upgrades.html#from2.9to3.0 and http://doc.powerdns.com/from3.0to3.1.html relevant.
-
- * At all times, keep the 'auth' and 'ordername' fields in the database correct, or run 'pdnssec rectify-zone' on changes.
-   Read http://doc.powerdns.com/dnssec-modes.html#dnssec-direct-database for more details.
-
  * DNSSEC answers are both larger & different than regular DNS answers. Make very sure that no firewall is in front of your server
    that blocks TCP or large DNS packets. Many default Cisco configurations do just that.
 
- * Stay away from mixed authoritative and recursive operation on one IP address. Not only does this make life complicated, PowerDNS with 
-   DNSSEC appears to have some bugs in this area.
-
- * When using slaves that AXFR your signed zones, be sure that your slaves actually support serving DNSSEC. Some servers will gladly
-   AXFR a signed zone, but not perform DNSSEC processing on it. This goes for PowerDNS 2.9.x
 
  * Clocks need to be set correctly. Also make sure you can reach an NTP server without relying on DNSSEC as a badly set clock will disable DNSSEC, and hence NTP in that case!
@@ -63 +75 @@
  * In any large migration, some things will suddenly stop working because you relied on undefined behaviour or even bugs for proper operations. Be hypervigilant for domains which 'suddenly' malfunction after signing!
 
-* If slaving signed zones via zone transfer (AXFR) , your slaves have a copy of all current DNSSEC signatures (that will expire within two weeks), but not of the actual keys (because AXFR slaves do not need them). So, where slaves used to be "free backups", this is no longer true for DNSSEC unless you replicate the entire database at SQL level (NATIVE replication). We recommend you backup your keys!
+ * If slaving signed zones via zone transfer (AXFR) , your slaves have a copy of all current DNSSEC signatures (that will expire within two weeks), but not of the actual keys (because AXFR slaves do not need them). So, where slaves used to be "free backups", this is no longer true for DNSSEC unless you replicate the entire database at SQL level (NATIVE replication). We recommend you backup your keys!
 
- * Key rollovers. PowerDNS automatically renews the RRSIGs (the signatures for your DNS data), so you don't need to do anything. There are documents which tell you to roll your DNS keys frequently, although it is now believed such automatic rolling is not required. In any case, if you are doing a large scale migration, it is advised to initially not roll keys until the dust has settled.
 
 Please stay tuned for further 'best current practices'.