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      |
-------------------------------------+-------------------------------------

Comment (by jelte):

 Looks like a number of these are actually in already, but they maybe not
 explicitely tests. There are a few that may warrant some discussion first.
 Not sure if this should go to the list, but we can copy this comment to
 -dev if so :)

 > In prescan:
 > - reject any meta types including MAILA/MAILB

 Already done (anything over type code 249 actually, since we don't
 implement those two records atm)

 > - reject any attempt of updating NSEC/NSEC3/RRSIG

 I was wondering, in the case where there is no auto-dnssec like thing,
 would it not be possible to make it so that the UPDATE actually updates
 the DNSSEC data as well? If not, some checks below seem moot, since it
 would simply not be possible to have a DNSSEC zone with DDNS enabled (of
 course, if we would have something like auto-dnssec enabled, the prescan
 should do this rejection)

 >
 > When adding an RR:
 > - ignore MD/MF
 > - ignore wildcard NS/DNAME

 ok those seem nice

 > - be careful with the coexistence of CNAME and DNSSEC related records

 there is already a bit of cname special casing (ignore cnames if other
 data is present, ignore other data if cnames is present). This does not
 take DNSSEC into account, so yeah, that needs to be added; but see above
 for dnssec+dnssec

 > - ignore a 2nd SOA (okay if explicitly deleting the existing one first)

 This should already be done as it is implemented now (anything but the
 last soa is ignored; no special care is taken to see which would be the
 'best' soa). Does warrant test though.

 > - ignore NSEC3PARAM records with any flags other than OPTOUT.

 See above for DNSSEC+DDNS. But still; why?

 > - 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)
 >

 Ah, differing TTLs and what to do with them. Always a fun topic. Is this
 defined somewhere or is this simply what bind9 does? (one could also
 reasonably argue that it should use the existing TTL, i think).

 > 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)

 ack, but once again, ddns+dnssec related though.

 >
 > After applying all changes:
 > - check DNSSEC: Prevent the zone entering a inconsistent state where
 >   NSEC only DNSKEYs are present with NSEC3 chains.

 or vice versa. Repeat dnssec+ddns statement.

 > - zone apex has NS, and if the NS name is a subdomain of the zone,
 >   there's AAAA or A for it.

 As we discussed, 9 does this, but it is diving into semantic
 interpretation of data (even more so than other suggestions here, IMO); I
 was wondering whether this should be an outright rejection, or only if
 *all* NS records are in-zone without glue.

 Still, probably very useful as foot protection.

 > - check_mx: (depending on configuration) whether MX has AAAA or A, the
 >   mx name is reasonable (not "x.y.z.w")

 I don't understand the second part.

 > - remove_orphaned_ds: "DS records are not allowed to exist without
 >   corresponding NS records"
 > - if 'dnssec-secure-to-insecure' is false, whether at least one DNSKEY
 >   exists.

 What is dnssec-secure-to-insecure? A state transition or a setting?

 > - if changing from secure to insecure, delete all NSEC3s

 !

 > - also log it if all changes result in no-op: "redundant request"

 This is actually another thing we don't do right now, we'll never have no-
 ops. Easy to add though (check diff to see if there is anything more than
 a soa serial update), but right now every update would result in a change;
 the soa serial. So right now we do section 3.6 option 1, but 2 would be
 much better, in which case a log message would indeed be nice.

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