[bind10-dev] custom update tool for use in DDNS tests

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(I originally started to write this message as a comment for ticket
http://bind10.isc.org/ticket/2061 but it occurred to me that this may
warrant some discussion first, not only to decide whether we should do
this in the first place, and whether this is the right approach, but
also because I may touch on some more general things that may warrant
some thought)

For #2061, what we need is the ability to create 'bad' UPDATE
messages; for instance multiple zone statements, or prereq/update
statements for wrong names.

Currently it uses nsupdate for creating and sending test packets (and
dig to check the results on the server).

I don't think we need to create unparseable packets, so I think it
could be done using standard libdns++ calls; what I was thinking of
could maybe would essentially be something like nsupdate, but with
more control over the entries; e.g. a session could look like
$> b10-update-tool
b10-update-tool v0.1
> help
commands:
server <address> [port]
add <section> <rr>
    where:
    section is one of ZONE, PREREQUISITE, UPDATE
    rr is text for RR statement (e.g. "example.org 0 IN ANY")
send
help
> server 127.0.0.1 5300 add ZONE example.org add ZONE foo.bar add
> UPDATE example.org 0 ANY ANY add UPDATE example.org 12345 IN A
> 192.0.2.1 send
rcode: FORMERR

Or something like that (yes this could even be a much more general
packet-creation-debug-tool if we want, but yagni and all that).

Regarding evolving this into a new nsupdate later, the above could be
an 'expert' session, where 'normal' operation would have something
similar to the original syntax (e.g. when you start it with -x or
something).

An additional option would be a -q flag that would quit immediately
exit with the rcode value returned from the server (and a predefined
one in case there is no answer); this would make fitting it into tests
quite a bit easier.

I think we have most of the packet creation code already, if we want
to pull that out of unit tests, where we already do a lot of this. But
I don't want to call our BIND10 python code directly from lettuce
tests; writing a separate tool based on it would still make it
'depend' on bind10 libs, but at least it would be indirect through the
command-line tool.

Which brings me to a different point; I think we should be careful
about dependencies in our system tests (especially since we also do a
number of compliance/interop tests there, which I hope to separate at
some point (yes it also occurred to me today that I may have used to
little abstraction in most of the tests, like the 'wait for stderr
message', but that is a story for another day)).

Currently it needs dig and nsupdate. If we have something like the
above, we can also use that where we use nsupdate now, but we'd be
replacing a bind9 dependency with a bind10 one. I assume that at some
point in the future we'd depend on 'bind10-tools' in general (but I am
presuming a sane package split here ;)). This need not necessarily be
discussed in depth now, but I would like to kindle all of your
thought-flames :)


Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/8mXYACgkQ4nZCKsdOncVcYQCgq88bbphpaS59FjYf0YJMjjIX
3goAmwSQiIyw/Gi/xPR8rMFcWwLh0mQN
=taU0
-----END PGP SIGNATURE-----