[bind10-dev] custom update tool for use in DDNS tests
Shane Kerr
shane at isc.org
Thu Jul 12 10:43:28 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jelte,
On Tuesday, 2012-07-10 23:07:02 +0200,
Jelte Jansen <jelte at isc.org> wrote:
> 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).
Maybe this:
$ b10-ddnscli
b10-ddnscli v0.1
> help
commands:
server <address> [port]
zone <zone-name>
prereq <type> <rr>
where:
type is one of NXDOMAIN, YXDOMAIN, NXRRSET, or YXRRSET
rr is text for RR statement (for example "example.org 0 IN ANY")
add <rr>
delete <rr>
where:
rr is text for RR statement (for example "www.example.org 3600 IN A
192.0.2.1")
send
> server 127.0.0.1 5300
> zone foo.bar
ZONE set to FOO.BAR
> zone example.org
ZONE set to EXAMPLE.ORG (was FOO.BAR)
> add example.org 0 ANY ANY
> add example.org 12345 in a 192.0.2.1
> send
rcode: FORMERR
My thinking is that you can only ever have 1 zone, so just make that a
command to set a zone.
Further, I find it annoying in nsupdate to have to specify "update"
before "add/delete". (Actually it might make some sense to make the
prerequisite commands also separate commands, but for some reason that
never annoys me.)
Probably it would make sense ultimately to make the RR parser work like
that in a zone file, so I can omit the "IN" and also set a default TTL
and omit that too, but that's certainly out of scope for now. :)
> 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).
Except that everybody hates the nsupdate syntax. :)
Maybe what we want is to treat the update as a 1st order object, and
allow you to modify the components on each section directly:
> show
Zone: EXAMPLE.ORG
Prerequisites
[none]
Updates
u1. ADD EXAMPLE.ORG 0 ANY ANY
u2. ADD EXAMPLE.ORG 12345 IN A 192.0.2.1
> update remove u1
> add www.example.org a 192.0.2.2
> show
Zone: EXAMPLE.ORG
Prerequisites
[none]
Updates
u2. ADD EXAMPLE.ORG 12345 IN A 192.0.2.1
u3. ADD WWW.EXAMPLE.ORG 1H IN A 192.0.2.2
> delete example.org 1H IN A 192.0.2.1
Zone: EXAMPLE.ORG
Prerequisites
[none]
Updates
u2. ADD EXAMPLE.ORG 12345 IN A 192.0.2.1
u3. ADD WWW.EXAMPLE.ORG 1H IN A 192.0.2.2
u4. DELETE EXAMPLE.ORG 1H IN A 192.0.2.1
> update move u4 up
> update move u4 up
> show
Zone: EXAMPLE.ORG
Prerequisites
[none]
Updates
u4. DELETE EXAMPLE.ORG 1H IN A 192.0.2.1
u2. ADD EXAMPLE.ORG 12345 IN A 192.0.2.1
u3. ADD WWW.EXAMPLE.ORG 1H IN A 192.0.2.2
Clearly out of scope for this tool, but just thinking about it. :)
> 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.
Check.
- --
Shane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
iEYEARECAAYFAk/+qlAACgkQMsfZxBO4kbTQ0gCfZOCjjt9keO3ff+rdWv9XuDjV
W9sAoMbXgTlVO1deill7qRi/xa2RnrVS
=ZJW2
-----END PGP SIGNATURE-----
More information about the bind10-dev
mailing list