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

[BIND 10 Development]

#1460: Define system-level tests for DDNS
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jelte
                       Type:  task   |                Status:  closed
                   Priority:         |             Milestone:
  medium                             |  Sprint-20120612
                  Component:  DDNS   |            Resolution:  complete
                   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      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * status:  reviewing => closed
 * resolution:   => complete


Comment:

 See below for final additions and comments, I'm going to assume it is ok
 now and close the ticket :)

 (if not we can update live or if there is something seriously wrong you
 are free to reopen the ticket)


 Replying to [comment:12 jinmei]:
 > Replying to [comment:11 jelte]:
 >
 > >
 > > 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.
 >

 which is, depending on how broadly one defines 'semantic', already
 contradicted by the very RFC itself :) But anyway, right, noted, leaving
 it as possible future enhancement

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

 Added that as a test, I suspect that we'll also need to change the
 difference-generation code if we want to be able to fully recover from
 such a case, and I'm not quite convinced it is worth it (and quite sure it
 is not at this point).

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

 ah, ok, incorporated it into the module tests.

 BTW, I am reasonably certain that this document contains more tests that
 would currently fail.

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

 Ah, for some reason I though NOTAUTH was redefined to 'not-primary' in the
 RFC, don't know where I got the idea. I didn't understand why it would be
 NOTIMP instead REFUSED then, but it is not the DDNS that is 'notimp' but
 the forwarding. Changed (and added a note about forwarding).

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