pdns icon indicating copy to clipboard operation
pdns copied to clipboard

new option 'ignore-errors' for setting 'outgoing-axfr-expand-alias'

Open klaus-nicat opened this issue 3 years ago • 4 comments
trafficstars

Closes #11503

If the ALIAS target can not be resolved during AXFR the AXFR will fail. To allow outgoing AXFR also if the ALIAS targets are broken set this setting to 'ignore-errors', but be warned, this will lead to inconsistent zones between Primary and Secondary name server.

Checklist

I have:

  • [x] read the CONTRIBUTING.md document
  • [x] compiled this code
  • [x] tested this code
  • [x] included documentation (including possible behaviour changes)
  • [ ] documented the code
  • [ ] added or modified regression test(s)
  • [ ] added or modified unit test(s)

klaus-nicat avatar Apr 06 '22 12:04 klaus-nicat

Not only this will lead to inconsistencies between primary and secondaries. It may also result in inconsistencies between secondaries. Such inconsistencies are problematic because they interact badly with aggressive negative caching.

Sorry, but I'm no fan of this outgoing-axfr-expand-alias is "maybe" mode. It will only move the pain around (from the authoritative to the resolver operator).

Ps. If it is safe to ignore errors while expanding alias records, why are those alias records there in the first place?

#11503

mind04 avatar Apr 07 '22 12:04 mind04

Ps. If it is safe to ignore errors while expanding alias records, why are those alias records there in the first place?

Use case: Customer (PowerDNS with ALIAS RR on Pimary Nameserver) and a DNS-Provider (we) providing Secondary services. The customer puts in an ALIAS and the ALIAS is transferred as ALIAS to our PowerDNS. For whatever reason the ALIAS target dissapears - but this is not an issue if the ALIAS is transferred as ALIAS.

We (the secondary DNS provider) use public facing PowerDNS instances and also Knot instances. Knot fetches the zones from PowerDNS by AXFR. So, PowerDNS happily serves all the records of the zone except the ALIAS as it is not resolvable. When Knot transfers the zone, the transfer fails as the ALIAS can not be resolved. Hence - without this patch our secondaries are inconsistent. The PowerDNS Secondaries serve the zone except the unresolveable ALIAS whereas the Knot Secondaries do not serve the zone at all. With this patch, Knot can transfer the zone (without the unresolveable ALIAS) and Knot can also serve the zone, except the ALIAS. (in fact PowerDNS will answer SERVFAIL for the unresolveable RRs whereas Knot will answer NXDOMAIN or NODATA or the wildcard if exists). So, yes this patch is not perfect but it solves a problem which really exists.

Another option, if ALIAS expanding fails on AXFR, would be to put the ALIAS itself in the AXFR. Hence, if expanding is not possible, the put the unexpanded RR into the AXFR. That would also solve our problem and maybe is more "consistent" as it does not silently drops an RR. Would you prefer this second approach?

klaus-nicat avatar Apr 07 '22 22:04 klaus-nicat

Given the default for outgoing-axfr-expand-alias is already no, I think this does absolutely no harm. I.e. using ALIAS with AXFR already gives you inconsistent zones by default.

zeha avatar Apr 19 '22 08:04 zeha

Hi! Is there something I can do to have this PR accepted? Thanks

klaus-nicat avatar Jul 19 '22 10:07 klaus-nicat

Any chance to get this PR merged? The 'ignore-errors' is not default, and the docs clearly mention that this feature may cause inconsistent zones. Except for the broken ALIAS, zones will be working. Omitting an unresolvable ALIAS does not have any real-world consequences (NXDOMAIN/NOERROR instead of SERVFAIL)

klaus-nicat avatar Jan 19 '23 15:01 klaus-nicat

Rebased to:

  • fix conflict in tcpreceiver.cc
  • update docs for "one sentence per line" style
  • 4.7 -> 4.9

zeha avatar Apr 18 '23 00:04 zeha

Rebased to get current CI config from master.

zeha avatar Jun 07 '23 11:06 zeha

green ❤️

zeha avatar Jun 07 '23 12:06 zeha