[Yeti DNS Discuss] An IXFR Fallback to AXFR Case

[Shane Kerr]

On 2016-04-28 11:44:12+0200 (Thursday)
Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:

> On Thu, Apr 28, 2016 at 05:14:29PM +0800,
>  Davey Song <ljsong at biigroup.cn> wrote 
>  a message of 128 lines which said:
> 
> > I composed a draft describing the case of IXFR fallback to AXFR
> > during MZSK experiment. Comments are welcome !Thank you
> 
> > To ask for development of new IXFR protocol to exclude the RRSIG as
> > a specially zone content when it compute the diff sequences in MZSK
> > model.
> 
> It seems very complicated to do. Not only it introduces a special case
> for RRSIG (what about NSEC*?) but also there is a risk of
> inconsistencies if some parts of the zone changed, then requiring new
> RRSIGs which will have to coexist with the old ones, made with a
> different key!

RRSIG *is* a special case in DNS - it is sort of normal RR, sort of
meta-data, sort of something else.

A simple solution may be to use a different port and then use a
modified IXFR there, where any RRSIG added was treated as a *replace*
operation for RRSIG of a label+RTYPE. No delete of RRSIG would be sent. 

An RRSIG-aware XFR format could actually be quite beneficial to anyone
using it for signed zones. The typical case is to need a new RRSIG when
an RRset is re-signed - which requires replace+add. This basically
means 2x the amount of data needs to be transferred. (I think someone
from NLnetLabs or SIDN was looking on an improved format, but I can't
remember now.)

> > To ask for adopt of IXFR-only draft and recommend it as default IXFR
> > protocol for MZSK situation
> 
> I do not see how it would help: IXFR would fail and then, without
> fallback (to AXFR), the slave would not be updated.

Yes, IXFR-only is not a useful solution in this case.

In fact the master already thinks that it is able to answer the IXR
properly, it is just not the same version of the zone that the slave
can accept.
 
> There is also a fourth solution you do not mention: tie each slave
> root server to a specific DM. This would decrease redundancy and
> resiliency but would allow normal IXFR, and may make debugging easier.

Hm... interesting. From the point of view of the health of the overall
system this is probably not a big problem, but there are a few of
disadvantages.

First, it means that we need to track which root servers are served by
which DM, which is a bit of an administrative annoyance. Not a big
deal, but it is something.

Second, it may evolve into the idea of "regional DM", which I think we
probably do not want. (Or maybe that is interesting to explore?)

Third, I was thinking that it might be nice for a root operator to
compare the zone transfered from all of the DM to verify that the
version produced is identical (apart from RRSIG). This would prevent a
rogue DM operator from being able to inject a bogus version of the root
zone. (This is in contrast to the IANA model, where Verisign can
basically do whatever it wants when it generates the signed zone and
there is no secure way to detect this.)


It would be nice if there was a way for a slave to be "sticky" with
IXFR somehow. That is, to prefer a specific master and use IXFR there,
but if it switches to a different master for whatever reason to start
with AXFR and then convert to IXFR. (This wouldn't require protocol
changes, and would solve our problem.)

Cheers,

--
Shane