[bind10-dev] DNS packet API: the name object

[Michael Graff]

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

I thought about this while out last week, and finally can look at a
screen long enough to formulate a reply. :)

I'm really worried about efficiency in the packet / rdata parsing /
writing code.  It's something we will be doing a lot, so I feel this is
one module that needs to have measurements made on speed.  No specific
design requirement needs to be there, but as we add stuff we should keep
in mind what it can do to performance.

I'm also worried about in-memory storage, but that is probably more of a
database issue.

I think it's also useful to document how we use this API, or expect to
use it.  Here's what I came up with:

An auth-only server would parse incoming packets, and format outgoing
ones.  For incoming only a small number of records will typically be
parsed (the query, OPT, and TSIG mostly) but for outgoing, any record
may end up being rendered.

In general, the outgoing records won't need to be processed more than a
simple rendering.  Thus, storing them in wire format in memory might
actually be a win.  Rendering them from variables would be slower.  This
may be a database issue again, but if we are going to use this API, I
would want to avoid a "parse" followed by a "render" -- that is, if the
database can store wire format data, it should not need to be touched
(much.)

A recursive server will inspect responses to its queries more deeply.
Thus, it may need the individual components of a query to be split out
more for some record types (A, AAAA, NS, etc.)  In general, though, TXT
records and other records simply won't be processed by a recursing
server, so I would hope we can hook in lazy cracking where we can...

- --Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqTBloACgkQ+NNi0s9NRJ3lagCgq/xdzgP0QaTPXk7TdJ7BeLr2
rlYAnA6X97OQfaj98v+iIBzojQ5bEjBa
=boCk
-----END PGP SIGNATURE-----