Moin!
I've tested this on Linux with NSD 3.1.1. In that setup NSD is acting as a slave to an ANS server. And normally IXFR works fine, but in cases where ANS doesn't want to do an IXFR (e.g after a zone resign) it answers with an SERVFAIL. I am not sure what the RFC says, but I would expect NSD to fall back to axfr, but it does not do this and you have to remove the file to start an axfr manually.
Can you please fix this, as otherwise NSD requires constant monitoring.
TIA and so long
-Ralf
Ralf Weber wrote:
I've tested this on Linux with NSD 3.1.1. In that setup NSD is acting as
a slave to an ANS server. And normally IXFR works fine, but in cases
where ANS doesn't want to do an IXFR (e.g after a zone resign) it
answers with an SERVFAIL. I am not sure what the RFC says, but I would
expect NSD to fall back to axfr, but it does not do this and you have to
remove the file to start an axfr manually.
According to the IXFR spec, it is allowed to return the full AXFR reply
in return to the IXFR query. So, the RFC says that the ANS server could
have replied instead of servfail...
Best regards,
Wouter
Moin!
Wouter,
Which RFC is this? (I don't doubt it, since this is the BIND behavior, I
am just curious.)
When I look at RFC 1995 it says:
"If the query type is not recognized by the server, an AXFR (preceded by
a UDP SOA query) should be tried, ensuring backward compatibility."
So this means that NSD should indeed try with AXFR when it gets an
error, as I understand it.
Also, I personally find it quite annoying that servers return AXFR to an
IXFR request. As a secondary, I would normally prefer to try another
server in the NS set to see if I can get an IXFR from it rather than
getting an AXFR.
Hi Shane,
Shane Kerr wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Ralf Weber wrote:
I've tested this on Linux with NSD 3.1.1. In that setup NSD is acting as
a slave to an ANS server. And normally IXFR works fine, but in cases
where ANS doesn't want to do an IXFR (e.g after a zone resign) it
answers with an SERVFAIL. I am not sure what the RFC says, but I would
expect NSD to fall back to axfr, but it does not do this and you have to
remove the file to start an axfr manually.According to the IXFR spec, it is allowed to return the full AXFR reply
in return to the IXFR query. So, the RFC says that the ANS server could
have replied instead of servfail...Wouter,
Which RFC is this? (I don't doubt it, since this is the BIND behavior, I
am just curious.)
Same 1995, where it says you can return AXFR contents inside an IXFR reply.
When I look at RFC 1995 it says:
"If the query type is not recognized by the server, an AXFR (preceded by
a UDP SOA query) should be tried, ensuring backward compatibility."So this means that NSD should indeed try with AXFR when it gets an
error, as I understand it.
Yes it does, you are right. Interoperability goes both ways 
Also, I personally find it quite annoying that servers return AXFR to an
IXFR request. As a secondary, I would normally prefer to try another
server in the NS set to see if I can get an IXFR from it rather than
getting an AXFR.
Hm yes. The non-AXFR reply by the master or non-fallback by the slave is
regarded as a feature. This would indicate that some feature option is
needed to control the behaviour.
Best regards,
Wouter
Moin!
Shane Kerr wrote:
When I look at RFC 1995 it says:
"If the query type is not recognized by the server, an AXFR (preceded by
a UDP SOA query) should be tried, ensuring backward compatibility."So this means that NSD should indeed try with AXFR when it gets an
error, as I understand it.Yes it does, you are right. Interoperability goes both ways
Hmm it doesn't or did I miss something - I read this as it will do it in future.
Anyway I have gotten a reply from Nominum and they will fix this, but also say that NSD should have retried with an AXFR. It should have worked if NSD would have used TCP as transport, but I don't think there is an option in the config file to tell NSD to only use TCP for IXFR.
As a workaround I configure request-xfr with AXFR for my DNSSEC enabled zones.
So long
-Ralf
Hi Ralf,
Ralf Weber wrote:
...
So this means that NSD should indeed try with AXFR when it gets an
error, as I understand it.Yes it does, you are right. Interoperability goes both ways
Hmm it doesn't or did I miss something - I read this as it will do it in
future.
Yes, Wouter meant to say: Yes NSD should do this. Currently, NSD is not
following RFC 1995 with respect to AXFR fallback.
Anyway I have gotten a reply from Nominum and they will fix this, but
also say that NSD should have retried with an AXFR. It should have
worked if NSD would have used TCP as transport, but I don't think there
is an option in the config file to tell NSD to only use TCP for IXFR.
This will be in the next release.
My question to the nsd-users list would be if there is interest in AXFR
fallback when the server does not understand IXFR. My opinion is that
NSD should support it, because we strife to be RFC-compliant.
- - Matthijs
Matthijs,
My question to the nsd-users list would be if there is interest in AXFR
fallback when the server does not understand IXFR. My opinion is that
NSD should support it, because we strife to be RFC-compliant.
- I think when the slave contacts the master, if the master cannot
provide IXFR for some reason (serial too old for example) then the
master should return an error code rather than falling back to AXFR.
- When the slave gets an error when attempting to IXFR, it should try a
different master, and when all masters have returned an error then it
should try AXFR.
This allows the slave to use IXFR if any of the masters support it for
the serial the slave is using, which is usually the best case, at least
for large zones.
It might be nice to be able to set this on a per-zone basis on the
master, so that for small zones the master *does* fall back to AXFR, but
since small zones are ... well, small, I don't think it matters too
much.
It might also be nice to set this on a per-master basis on the slave, so
that masters which are known not to provide IXFR can be avoided.
Note that this behavior is not what BIND currently implements (the
master falls back to AXFR when IXFR is not possible, and the slave will
try AXFR on the same master when IXFR is not possible), but that does
not mean BIND does the right thing.
Shane,
Shane Kerr wrote:
Matthijs,
My question to the nsd-users list would be if there is interest in AXFR
fallback when the server does not understand IXFR. My opinion is that
NSD should support it, because we strife to be RFC-compliant.- I think when the slave contacts the master, if the master cannot
provide IXFR for some reason (serial too old for example) then the
master should return an error code rather than falling back to AXFR.- When the slave gets an error when attempting to IXFR, it should try a
different master, and when all masters have returned an error then it
should try AXFR.
This is what I wanted to suggest. I agree with you that it should first
try a different master.
This allows the slave to use IXFR if any of the masters support it for
the serial the slave is using, which is usually the best case, at least
for large zones.It might be nice to be able to set this on a per-zone basis on the
master, so that for small zones the master *does* fall back to AXFR, but
since small zones are ... well, small, I don't think it matters too
much.It might also be nice to set this on a per-master basis on the slave, so
that masters which are known not to provide IXFR can be avoided.
You can already to this:
request-xfr: [AXFR] <ip-address> <key-name | NOKEY>
If the AXFR option is given, the server will not be contacted
with IXFR queries but only AXFR requests will be made to the server.
- - Matthijs