Skip to content

Feature request: retry with AXFR on IXFR SERVFAIL #479

Description

@steffann

We sometimes run into a situation where the IXFR history somehow became inconsistent between our primary Knot server and our secondary NSD server. The primary says:

Mar 31 10:27:06 xxx knotd[3733560]: info: [x.x.x.in-addr.arpa.] IXFR, outgoing, remote xxx::233@48338 TCP, zone is up-to-date, serial 2026033101
Mar 31 10:27:52 xxx knotd[3733560]: info: [x.x.x.in-addr.arpa.] IXFR, outgoing, remote xxx:43ba@36170 TCP, zone is up-to-date, serial 2026033101
Mar 31 10:27:56 xxx knotd[3733560]: info: [x.x.x.in-addr.arpa.] IXFR, outgoing, remote xxx::234@38522 TCP, started, serial 2026032601 -> 2026033101
Mar 31 10:27:56 xxx knotd[3733560]: error: [x.x.x.in-addr.arpa.] IXFR, outgoing, remote xxx::234@38522 TCP, failed (inconsistent history)
Mar 31 10:28:08 xxx knotd[3733560]: info: [x.x.x.in-addr.arpa.] IXFR, outgoing, remote xxx:5f78@53746 TCP, zone is up-to-date, serial 2026033101

And the secondary sees:

2026-03-31T10:27:56.196161+02:00 yyy nsd[132665]: xfrd: zone x.x.x.in-addr.arpa. received error code SERVFAIL from xxx::38

So far this makes sense. I have no idea why the IXFR history got inconsistent (it does only happen when NSD is the secondary, we don't have this problem with BIND or Knot as secondary) but currently we end up in a situation that needs manual intervention. We now manually solve the issue by running nsd-control force_transfer x.x.x.in-addr.arpa when we see this in the logs. It would be nice if NSD could fall back to AXFR automatically when this happens.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions