pdns
pdns copied to clipboard
PowerDNS
auth: Automatic NOTIFY to NS in catalog zone fails because the NS name is 'invalid.'
- Program: Authoritative
- Issue type: Bug report
Short description
If a Producer catalog zone is created with a sole NS RR which sets the nameserver to 'invalid.' (as recommended), pdns-auth tries to resolve that to send a NOTIFY to it.
Environment
- Operating system: Debian Bookworm
- Software version: 4.7.2
- Software source: self-built package using PowerDNS builder
Steps to reproduce
- Use API to create a "Producer" zone with a single NS RR containing "invalid."
- Set that zone as the catalog zone for an existing zone.
- Check the log/journal.
Expected behaviour
No error should be generated as no configuration telling the server to send NOTIFY to the NS targets was provided.
Actual behaviour
Nov 16 11:39:56 dns21 pdns_server[49]: Unable to queue notification of domain 'private.catalog.km6g.us' to nameserver 'invalid': nameserver does not resolve!
Expected behaviour
No error should be generated as no configuration telling the server to send NOTIFY to the NS targets was provided.
PowerDNS is notifying NS targets since day 1 There is however a configuration option to control this behavior. Put 'only-notify=' in your config to only send notifies to your 'also-notify' destinations. Without 'also-notify' you must use valid nameservers in all your primary zones (including catalogs).
I have both also-notify and only-notify in my configuration, set to the same list of IP addresses.
Empty only-notify will save some resources since it will disable the useless resolving. See https://doc.powerdns.com/authoritative/settings.html#only-notify for the exact details.
That's a bit obscure, but OK :-) I suppose right now my only-notify setting is not providing any value since it has the same entries in it as also-notify does.
This definitely works, but I can envision situations where an admin has many zones with different sets of secondaries listed in the NS records, and thus needs to leave NS target resolution enabled. In such a situation they'd have to use a resolvable name in the NS record of their catalog zone(s).
I know special cases in code are awful, but would it be worth considering a 'soft failure' (ignore) in the auth server whenever it tries to resolve a zone ending with 'invalid.', since those are defined to be unresolvable?
I know special cases in code are awful, but would it be worth considering a 'soft failure' (ignore) in the auth server whenever it tries to resolve a zone ending with 'invalid.', since those are defined to be unresolvable?
How about instead defaulting to effectively only-notify= behavior for producer-type zones? If the recommendation is to have that NS anyway, it seems like that is what users will want?
