[bind10-dev] XFR

[Shane Kerr]

Michael,

Thanks for this. Some comments inline.

On Fri, 2009-06-19 at 03:04 -0500, Michael Graff wrote:
> 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.

Defaulting to HMAC-SHA256 makes sense to me.

> 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.

By default we should "do the right thing".

So, certainly any hosts listed in "allow-xfr" should also allow SOA
checks. We should also allow XFR from any IP address we know about in
the NS-SET for a zone, which would allow these SOA checks too. This can
be tricky, since we would need to cache the out-of-zone values and short
TTLs would make our authoritative servers do a lot of extra queries to
keep this list fresh - how does BIND do this today?

Note that we also need a "--bind9" option or something like that which
we use to insure that we act exactly the same as BIND 9.

> 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.

This makes sense.

> NOTIFY
> - ------
> 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.

This is supported by some other software (NSD at least), and I think we
should go ahead and support TSIG signed NOTIFY messages this as well.

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

Interesting. Do we trust this number, or always issue an SOA freshness
check? (I think we should trust the number, but if we always do the SOA
freshness check we need to preserve this in BIND9-compatibility mode.)

> 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.

It's a pity the ZXFR technique (AXFR through gzip) got dropped (because
of a bad implementation with a security issue, I think). It makes
abundant sense to me, anywhere CPU cycles are cheaper than bandwidth.
Maybe we can revive it.

Also, we may want to be a bit smarter about batching XFR requests - I
don't know if we do this today, but perhaps we can try to apply some
logic so that if you have multiple zones with the same master that they
try to get the zone using the same TCP connection. (Perhaps this never
occurs in reality, but I can see this being a quite common case for big
domain hosters.)

> 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.

We should at least give people the option for UDP.

In fact a UDP IXFR followed by TCP IXFR if it does not fit might be
sensibly used instead of a UDP SOA check followed by TCP IXFR. In theory
this is the most efficient way to get a zone update.

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

Also note that there is a "compressed" mode. In this case rather than
playing a log of updates (one per serial), you essentially give a "diff"
between two serials.

I don't think BIND 9 supports this mode. It *can* cause problems if you
have multiple masters for any given node, because it makes masters fall
back to AXFR if a given master does not have the same serials as a
different master. However, in most cases it works fine.

The compressed response usually needs to be generated at query time, so
it may not be ideal for most cases. But it does save bits on the wire.

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

Which we don't do today, AIUI. So for BIND 9 compatibility we would
probably need to have an option where we skip this check.

> 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.

Agreed.

There is also data that is not in AXFR/IXFR which might be useful. Mark
has a draft which tries to avoid situations where zones never expire due
to nodes which act as both slave and master giving fresh versions of an
old zone to each other.

"true" master -+--> server
               |      ^
               |      |
               |      v
               +--> server

In this case if the "true" master goes away, the two servers will
continue to give stale versions of the zone to each other forever.
Putting a wall-clock expiry time in the zone meta-data can prevent this.

Alternate methods could perhaps do things like sending data to hosts in
advance, and then advancing to the new serial with a separate command.
So, don't serve a new serial until every node in a cluster has the
complete data. Or until every node scattered on slow, flaky links on the
Internet, has the new serial.

--
Shane