BIND 10 #1459: Consistency checks in DDNS module

[BIND 10 Development]

#1459: Consistency checks in DDNS module
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:
                       Type:  task   |                Status:  new
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120612
                  Component:  DDNS   |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:  DDNS   |  Estimated Difficulty:  5
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Description changed by jinmei:

Old description:

> Before the (final) commit in a DDNS update, there is a number of
> consistency checks we should do.
>
> ~~It's probably better to start this task after #1512 (at least after
> we agree on its basic code structure)~~ #1512 seems to be mature
> enough for other tasks to start based on its snapshot (trac1512).

New description:

 (Updating based on jabber chat)

 Before the (final) commit in a DDNS update, there is a number of
 consistency checks we should do.

 It was not really clear what "consistency checks" mean, so I'm going
 to list additional checks BIND 9 does, which don't seem to be
 implemented in BIND 10 yet (not even in #1457).  Note that they are
 not only "final" checks, but also checks in prescan or actually
 updating the zone.

 Some of the checks may not make sense for us (or too advanced at the
 moment), so we should discuss any suspicious ones.  Also, if we try to
 include most of the checks, it may be too big for a single ticket.
 Since each individual check is generally independent, we should be
 easily able to separate them into multiple tasks.

 In prescan:
 - reject any meta types including MAILA/MAILB
 - reject any attempt of updating NSEC/NSEC3/RRSIG

 When adding an RR:
 - ignore MD/MF
 - ignore wildcard NS/DNAME
 - be careful with the coexistence of CNAME and DNSSEC related records
 - ignore a 2nd SOA (okay if explicitly deleting the existing one first)
 - ignore NSEC3PARAM records with any flags other than OPTOUT.
 - merge new RRs with existing RRset: in particular, if a new RR is
   being added which is only different with an existing one in TTL,
   make sure just the new TTL is used (note that the new TTL may be
   larger than the existing one)

 When deleting all any type of RRs of a name:
 - do not delete RRSIG or NSEC (or NSEC3?)
 - in addition, if the name is zone origin, do not delete NSEC3PARAM
   (or SOA or NS)

 After applying all changes:
 - check DNSSEC: Prevent the zone entering a inconsistent state where
   NSEC only DNSKEYs are present with NSEC3 chains.
 - zone apex has NS, and if the NS name is a subdomain of the zone,
   there's AAAA or A for it.
 - check_mx: (depending on configuration) whether MX has AAAA or A, the
   mx name is reasonable (not "x.y.z.w")
 - remove_orphaned_ds: "DS records are not allowed to exist without
   corresponding NS records"
 - if 'dnssec-secure-to-insecure' if false, whether at least one DNSKEY
   exists.
 - if changing from secure to insecure, delete all NSEC3s
 - also log it if all changes result in no-op: "redundant request"

--

-- 
Ticket URL: <http://bind10.isc.org/ticket/1459#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development