On axfr fallback

NSD
1

Hi,

There was some resistance on a feature in NSD that was introduced in
3.2.0. AXFR/TCP fallback in case of failing IXFR zone transfers was not
appreciated by everyone.

The issue was raised on this mailing list a couple of months ago:
http://open.nlnetlabs.nl/pipermail/nsd-users/2008-August/000805.html

To clarify things:
As a master, NSD replies with NOTIMPL if you request it an IXFR.

As a secondary, this thread suggests that NSD should fallback to AXFR,
when IXFR did not work, but only after all masters were not able to
serve IXFR. We have implemented that in 3.2.0.

However, in some environments IXFR could fail, even if the masters
support it. It would fail because of for example, bad connection. AXFR
fallback would not help in that case.

The misconception lies within "IXFR did not work". A secondary should
only fallback to AXFR if the IXFR was not recognized by the master, not
if other errors occur.

We would like to adapt the AXFR fallback, so that it will not do the
fallback after a number of failed IXFR rounds. Instead, a master will be
marked by the secondary if it returned a NOTIMPL or a FORMATERR. In that
case, the next cycle round the masters, NSD will only fallback to AXFR
if the nameserver was marked. In other words, NSD would never fallback
to AXFR if all configured masters support IXFR.

In addition, we would like to cache the mark for 48hr. After that, NSD
may request the previously marked master for IXFR again.

We think this behavior is even more in line with RFC 1995 and will work
better in an environment which has poor network connection. Do you think
this is a solution that we can agree on?

Regards,

Matthijs Mekking
NLnet Labs

2

Hi,

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

Hi,

There was some resistance on a feature in NSD that was introduced in
3.2.0. AXFR/TCP fallback in case of failing IXFR zone transfers was not
appreciated by everyone.

The issue was raised on this mailing list a couple of months ago:
http://open.nlnetlabs.nl/pipermail/nsd-users/2008-August/000805.html

To clarify things:
As a master, NSD replies with NOTIMPL if you request it an IXFR.

As a secondary, this thread suggests that NSD should fallback to AXFR,
when IXFR did not work, but only after all masters were not able to
serve IXFR. We have implemented that in 3.2.0.

However, in some environments IXFR could fail, even if the masters
support it. It would fail because of for example, bad connection. AXFR
fallback would not help in that case.

The misconception lies within "IXFR did not work". A secondary should
only fallback to AXFR if the IXFR was not recognized by the master, not
if other errors occur.

Yes

We would like to adapt the AXFR fallback, so that it will not do the
fallback after a number of failed IXFR rounds. Instead, a master will be
marked by the secondary if it returned a NOTIMPL or a FORMATERR. In that
case, the next cycle round the masters, NSD will only fallback to AXFR
if the nameserver was marked. In other words, NSD would never fallback
to AXFR if all configured masters support IXFR.

In addition, we would like to cache the mark for 48hr. After that, NSD
may request the previously marked master for IXFR again.

We think this behavior is even more in line with RFC 1995 and will work
better in an environment which has poor network connection. Do you think
this is a solution that we can agree on?

A configuration knob to disable AXFR fallback entirely, globally or per server basis would be nicer.

Regards,

Matthijs Mekking
NLnet Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJGaLTIXqNzxRs6egRAmVWAJ9Ze6R5dARx4T6cXfNNJRLFemEffwCfR84a
s6BUKpZKiRK7PfF//vJD8/o=
=dJcR
-----END PGP SIGNATURE-----
_______________________________________________
nsd-users mailing list
nsd-users@NLnetLabs.nl
http://open.nlnetlabs.nl/mailman/listinfo/nsd-users

Regards,

Vicky Shrestha

3

Bill Woodcock wrote:

NSD would never fall back to AXFR if _any_ of the configured masters
support IXFR, no?

Not precisely. In the suggestion I proposed, NSD would never fall back
to AXFR if *all* of the configured masters support IXFR. The marking is
on a per server basis: If one master does not implement IXFR, NSD would
request AXFR to that master, and will try IXFRs for the others.

    > A configuration knob to disable AXFR fallback entirely, globally or per
    > server basis would be nicer.

Yes, that would certainly help avoid messy accidents.

In my current opinion, that is the responsibility of the operator. If
you don't want to use AXFR, only install servers that support IXFR.
So the option is likely not to be strictly necessary and if we implement
it, it would be in strife with our requirements we set on NSD (in this
case simplicity).

Matthijs

4

[...]

> > A configuration knob to disable AXFR fallback entirely, globally
> > or per server basis would be nicer.
>
> Yes, that would certainly help avoid messy accidents.

In my current opinion, that is the responsibility of the operator. If
you don't want to use AXFR, only install servers that support IXFR.

That's ok if you manage every single secondary and master for a zone, but in
reality, sharing of zones between different organizations with different
style of administration happens.

So the option is likely not to be strictly necessary and if we implement
it, it would be in strife with our requirements we set on NSD (in this
case simplicity).

OK, in case that matters, I also think that the configuration knob issue would
be really great :slight_smile:

5

[...]

> > A configuration knob to disable AXFR fallback entirely, globally
> > or per server basis would be nicer.
>
> Yes, that would certainly help avoid messy accidents.

In my current opinion, that is the responsibility of the operator. If
you don't want to use AXFR, only install servers that support IXFR.

That's ok if you manage every single secondary and master for a zone, but in
reality, sharing of zones between different organizations with different
style of administration happens.

OK, there are two cases here:

A) master not controlled

and

B) slave not controlled

In case of A) solution is simple - just don't configure it as master if it
doesn't support IXFR.

In case of B) (and unbound) - you are just fine, since you control master.

What I am missing?

So the option is likely not to be strictly necessary and if we implement
it, it would be in strife with our requirements we set on NSD (in this
case simplicity).

OK, in case that matters, I also think that the configuration knob issue would
be really great :slight_smile:

For what exactly?

I am against creating configuration option just because "it might be handy".

Ondrej

6

We would like to adapt the AXFR fallback, so that it will not do the
fallback after a number of failed IXFR rounds. Instead, a master will be
marked by the secondary if it returned a NOTIMPL or a FORMATERR. In that
case, the next cycle round the masters, NSD will only fallback to AXFR
if the nameserver was marked. In other words, NSD would never fallback
to AXFR if all configured masters support IXFR.

I don't have time to do test, so I am going to ask. What error code does
bind returns if you delete it's journal (and ixfr-from-differences is yes)?
Ie. if bind cannot provide IXFR, only AXFR? Will nsd fallback to AXFR in
that case? (I hope the answer is that it's the FORMATERR error code ;)).

Ondrej.

7

Ondrej,

8

Shane,

Ondrej,

I don't have time to do test, so I am going to ask. What error code does
bind returns if you delete it's journal (and ixfr-from-differences is yes)?
Ie. if bind cannot provide IXFR, only AXFR? Will nsd fallback to AXFR in
that case? (I hope the answer is that it's the FORMATERR error code ;)).

If BIND cannot provide IXFR then it automatically falls back to AXFR.

Alright, you forced me to read RFC1995 ;).

I think this behavior is badly broken, but it is allowed by the RFC.
(There are several scenarios which can cause BIND to not have enough
information to provide IXFR from any particular serial, which means if
you are unlucky enough to try that server before a server that *can*
provide IXFR, you have to transfer the entire zone.)

It seems to me, that the problem here is that RFC 1995 tried to be foolproof
and what we really need is:

C: request IXFR
S: return "cannot serve IXFR, try AXFR" error code
C: request AXFR

instead of:

C: request IXFR
S: return IXFR or AXFR

What about making update to RFC1995 to allow server to return error code?

Ondrej