BIND 10 #167: configure addresses and ports to listen on for DNS servers

BIND 10 Development do-not-reply at isc.org
Fri May 21 00:24:34 UTC 2010


#167: configure addresses and ports to listen on for DNS servers
--------------------------+-------------------------------------------------
 Reporter:  larissas      |        Owner:  UnAssigned                 
     Type:  task          |       Status:  reviewing                  
 Priority:  major         |    Milestone:  04. 2nd Incremental Release
Component:  Unclassified  |   Resolution:                             
 Keywords:                |    Sensitive:  0                          
--------------------------+-------------------------------------------------

Comment(by jinmei):

 Replying to [comment:3 each]:
 > > There don't seem to be tests for this feature. (I know this is
 probably a short lived feature, but IMO we shouldn't use it as an excuse
 for not testing it)
 >
 > No, true.  There aren't any tests for the -p option either.
 >
 > I'm not actually sure how to use our unit test framework to test "it's
 listening only on the specified address and port".  I can test that it
 rejects invalid addresses, but is there a way to trigger incoming
 connections and confirm that they don't work when they aren't supposed to?

 "only this" may be difficult to test, but we can probably confirm the
 testee actually tries to bind a socket to a specific address[:port] by
 letting the tester make that exact binding first and seeing the subsequent
 attempt fail:

 in the test code:
 {{{
    s.bind("[::1]:5300")
    assertRaises(socket_error_or_something, testee.do_bind("::1", 5300))
 }}}
 etc.

 Another possibility is to separate the actual socket related operations
 and option handling clearly, and to make sure at least the options are
 interpreted as expected.

 btw, in my understanding one of the (advocated) TDD is that by considering
 how to test it before even designing it we can improve t testing the
 feature doesn't seem to be straightforward. (Of course, on the other hand,
 tweaking the design for the convenice of some very tricky test cases could
 rather damage the design.  So we should be careful not being too tricky,
 but I think we should try hard by default designing things so that they
 can be tested)

 Oh, btw, another unrelated comment I happen to notice: I suggest we use
 socket.getaddrinfo() instead of socket.inet_pton().  Whether or not we
 want to support IPv8:-), I believe we'd like to avoid this type of
 exception usage:

 {{{
 +            a = socket.inet_pton(f, addr)
 +        except socket.error:
 +            try:
 +                f = socket.AF_INET6
 +                a = socket.inet_pton(f, addr)
 +            except socket.error as se:
 +                raise se
 }}}

 (clearly this abuses an exception because the first exeption is not
 actually an exceptional case)

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


More information about the bind10-tickets mailing list