[bind10-dev] XFR

[Michael Graff]

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

Transfers are pretty well understood, and are a place where little work
has been done in terms of protocol work.  This is general because it
just works.

TSIG
- ----

TSIG is a security mechanism where DNS messages are signed using
cryptographic keyed hashes.  The hashes supported by BIND 9 include
HMAC-MD5, HMAC-SHA1, HMAC-SHA256, and HMAC-SHA512.  There may be more,
and BIND 10 should support all of them.  MD5 is probably still in common
use, but BIND 10 might want to default to HMAC-SHA256 for keys it generates.

TSIG has a DNS format name, which BIND 9 uses as the identifier.  BIND
10 should use an internal name for this when referring to the key by
identifier, as the user may not control the name used by a hosting company.

The example here is, if I secondary my zone on Provider1 and Provider2,
I may use the username "explorer" on both.  They may then create a TSIG
key named "explorer".  However, I cannot add both of these to a BIND 9
config file as the name is the same.

Instead, BIND 10 should allow me to name these something else, and
include the DNS name to use in the protocol as part of the description
of this key.

For example:

  key "provider1" { name "explorer"; ... }
  key "provider2" { name "explorer"; ... }

I could then specify which key to use for which host.  This would mean
that both keys may need to be checked if used in ACLs.  This idea needs
more research on the implications of incoming packets, allow-transfer
statements, and which key(s) need to be examined when there is an
overlap of protocol-level names.


SOA CHECKS
- ----------

SOA checks are performed as a light-weight freshness check.  It is
expected that any server which would allow AXFR to a set of secondaries
would allow these SOA checks as well.  This is not always the case, so a
failure (timeout) here may indicate that an XFR should be issued.  This
has caused problems in the past, however, so it should perhaps not be
the default behavior.

SOA checks were at one point not TSIG signed, even if a TSIG key would
later be used to transfer the zone contents.  I believe we should issue
them TSIG signed if a key is specified, and fall back to non-signed if
we get a TSIG failure.


NOTIFY
- ------

When a zone changes, NOTIFY allows the master (or intermediate masters
in a tiered configuration) to indicate that a zone has changed and a
refresh (SOA check + transfer) might need to be initiated.  They are a
hint only, and if missed, normal periodic checking will ensure zone
freshness.

BIND 9 does not sign notifies.  This is arguably a mistake, which I
would like to revisit.  I believe that signing a NOTIFY would allow the
slave to ignore "bad" notifies, if any, without additional network
traffic.  This makes sense to me, since BIND 9 also ignores NOTIFY
messages from non-configured masters.  Using a TSIG key could, in
certain situations, allow non-masters to generate the notify but the
master list itself would be used to refresh the zone.

NOTIFY is actually an unsolicited response with an SOA indicating the
current zone's serial number.


AXFR
- ----

An AXFR includes the whole zone's data, transfered as multiple DNS
messages bracketed by the SOA records.

AXFR is the least efficient, in general, method of transport of a zone.
 It will require us to maintain up to two copies of the zone, one which
is coming in, and one which is being served.  We would not want to serve
a partially transfered zone as live data.

We may use any database techniques to avoid the need to actually
replicate data.  The BIND 9 method for in-memory, with a version number
field, is actually quite workable, and would probably work well for SQL
as well.  Ideally we won't maintain more than one version at a time, and
an SQL database need not be cleaned by the auth server itself, but could
have a cleaner process dedicated to database back-end cleanups.

AXFR transfers may be "one answer" -- one large DNS packet, as large as
we can make it, is sent for each block of the zone -- or "many answers"
- -- we send one DNS frame per RR.  The latter is for compatibility and
debugging.

AXFR always uses TCP.  AXFR responses may be TSIG signed if the AXFR
request was.  Not every single DNS frame contains a TSIG signature, but
all frames between the last signature and the current one are included
in the hash.  This is for efficiency of some sort, perhaps network
efficiency.

If memory serves, there is a hack Microsoft included in their transfer.
 That hack is, on the request, a normal DNS frame is sent, but the data
portion is two bytes longer than the DNS frame needs.  These two bytes
are padded with the string "MS".  This may be used to switch to
one-answer format, or from it, I cannot remember.


IXFR
- ----

IXFR requests specify a starting serial number.  Should a delta from
that version to the current one not exist on the server, an AXFR would
be returned instead.

IXFRs are usually preferred because they are smaller in size.  The
protocol can be TCP or UDP, although BIND 9 only implements IXFR over TCP.

The format is the starting SOA, followed by any number of records,
intermediate SOA values, and followed by a final SOA.

Care must be taken to ensure that the IXFR is not larger than the AXFR
request.

IXFR responses may be TSIG signed if the request was.


INTERNAL ONLY
- -------------

While AXFR and IXFR are external protocols, intended to work across name
server platforms, we should consider more efficient encodings and
transfers within a BIND 10 "cluster" if we wish.  Examples would include
transfer of a pre-compiled binary format between a server with a
"master" role and those with "slave" roles.  Binary patches, fragments,
and other update methods could also be used for any number of update
mechanisms.

We must be careful to ensure that we are not making more work for little
gain here however.  Initially AXFR/IXFR would work within the cluster,
and we can later improve if needed.

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

iEYEARECAAYFAko7RoYACgkQ+NNi0s9NRJ3d2ACfUurYoYKm1rzYz6GIgK2dwqiN
NGsAnRDevi5zB1wNeIlGcAuxpPLsaAxr
=gGKJ
-----END PGP SIGNATURE-----