BIND 10 #1460: Define system-level tests for DDNS

[BIND 10 Development]

#1460: Define system-level tests for DDNS
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jinmei
                       Type:  task   |                Status:  reviewing
                   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:  6
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 jelte]:

 > > BIND 9's system tests have their own update cases.  From a quick look,
 > > I've not found so many we need to incorporate from them, but you may
 > > also want to take a look at it.  It's
 > > bind9/bin/tests/system/nsupdate/tests.sh.  One thing that drew my
 > > attention is this:
 > >
 > > {{{
 > > # inserting an NS record without a corresponding A or AAAA record
 should fail
 > > $NSUPDATE -l -p 5300 -k ns1/session.key > nsupdate.out 2>&1 << END &&
 status=1
 > > update add other.nil. 600 in ns ns3.other.nil.
 > > send
 > > END
 > > grep REFUSED nsupdate.out > /dev/null 2>&1 || status=1
 > > }}}
 > >
 > > although the underlying implementation uses the generic zone
 > > management module, so in our case it's probably more reasonable to
 > > hold off until we do generic zone loading with post-load checks.
 > >
 >
 > So what this does is refuse the addition of NS records that need glue
 but don't have it? Is this specified somewhere or just a useful feature
 that bind implements?

 I believe it's the latter.  RFC2136 also has this:

    7.14. No semantic checking is required in the primary master server
    when adding new RRs.

 > > - We may want to test this, although this level of thing should also
 > >   be covered in unit tests:
 > > {{{
 > >    7.11. A zone's SOA SERIAL should never be set to zero (0) due to
 > >    interoperability problems with some older but widely installed
 > >    implementations of DNS.  When incrementing an SOA SERIAL, if the
 > >    result of the increment is zero (0) (as will be true when wrapping
 > >    around 2**32), it is necessary to increment it again or set it to
 one
 > >    (1).  See [RFC1982] for more detail on this subject.
 > > }}}
 >
 > Added to serial tests.
 >
 > The RFC does not seem to be very clear on what to do if the update
 itself tries to set the serial to 0. It says it is not allowed, but should
 we then change it to 1 or refuse the update?

 From a quick look at the BIND 9 implementation, BIND 9 doesn't seem to
 tweak the serial if it's explicitly specified.  This means, it
 probably wouldn't matter in practice, although in its sense the RFC
 seems to rather suggest to update the serial in that case, too.

 > > - There can be a case where the zone doesn't even have an SOA for
 > >   DB-based data sources (in-memory should ensure that it never
 > >   happens).
 >
 > Eek. While of course true, I don't think there is anything that one
 could do to make a zone more broken than that :) While we should of course
 not crash on it I have no idea on how it is supposed to behave in that
 scenario. Generate one with defaults (if not provided in update)?

 My gut feeling is:

 - if the update handling requires to get the zone's current SOA, the
   whole update should fail with SERVFAIL
 - adding a fresh SOA to a half-broken zone without any SOA can succeed

 But it would also be okay if we fail any update action on such a
 broken zone.

 > Replying to [comment:9 jinmei]:
 > > A couple of more BIND 10 specific things:
 > >
 > > - It's worth testing what happens b10-ddns once started but stops
 > >   running, then restarts again.  update requests will have to be
 > >   forwarded to and processed by b10-ddns after restart.  Note that the
 > >   first request after restart will probably fail with SERVFAIL because
 > >   b10-auth still keeps the socket with the now-stale connection, and
 > >   it can only detect the failure in the next push() operation (#1986
 > >   could solve this)
 >
 > I was kind of thinking that if the system notices ddns is down it would
 always return SERVFAIL until it has been restarted and is answering again.
 Are you suggesting it should buffer the updates?

 No what I meant is:

 - b10-auth and b10-ddns establishes a connection (and probably handles
   an update request successfully)
 - kill and restart b10-ddns
 - *after the restart* send another update to b10-auth.  In the current
   implementation, it will result in SERVFAIL but it's suboptimal (with
   a more sophisticated implementation, the auth should be able to
   detect the ddns's death immediately after it happens and behave
   accordingly).

 One more thing: the current behavior for "zone section test 6" is to
 return NOTIMP, not NOTAUTH.  NOTIMP seemed to be most compatible to
 the BIND 9's behavior in a similar case.  And, in any case, NOTAUTH
 wouldn't be a good code in this case because the server is actually
 authoritative for the zone.

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