Requesting synchronous AXFR

[klaus-nicat]

I know "pdns_util retrieve", that queues a zone transfer from the configured primaries. But the client does not know if the queued zone transfer will succeed.

Is there some feature/workaround/hack in PDNS to requests a zone transfer "now" and the request blocks until there is a result (success or failed)? Ideally using a specified primary IP address ...

[klaus-nicat]

Background: Customer like the possibilty to test if AXFR works (i.e. if their primaries and firewalls are correctly configured). And I am considering if this can be possible with PDNS or we have to build some tool next to PDNS for testing AXFR.

[klaus-nicat]

(think out loud) Would it be possible to make an API Endpoint that just calls CommunicatorClass::suck and reports back if the AXFR succeeded or not. (Ideally with a "test" parameter which performs the AXFR but does not store it in the DB)

[zeha]

I think there are multiple things that could be done:

• Add a primary_address option to /api/v1/servers/localhost/zones/<id>/axfr-retrieve. That's a feature that can stand on it's own. (probably easy)
• Add a new API call to check if there is a pending AXFR for a secondary zone. This wouldn't block a thread in pdns_server to wait for an AXFR to complete. (probably easy)
• Add a new API (+ pdnsutil?) feature to probe AXFR capability. Should probably still be tied to an existing zone, to allow using TSIG. I imagine this would just try TCP connect + start AXFR + then abort. Probably no validation of the received data (would that be important?). This would block an API thread.
• Add a new API to get the result of the last AXFR attempt for an existing domain. Would need inventing some form of (in-core-in-memory?) storage for that. Maybe have addSuckRequest return some ID to correlate the queued attempt with "the last attempt" later on.
• Conditionalize writing into the backend in CommunicatorClass::suck, to provide a form of "no act" AXFR attempt. That might suck a lot.

[zeha]

Add a new API (+ pdnsutil?) feature

pdnsutil might work for probing, because then it would block the newly spawned pdnsutil process, and no crossover with the running pdns_server is necessary. For anything else, it would be pdns_control instead, and suddenly it's very hard (probably can't block waiting etc).

[klaus-nicat]

Do you mean that using pdns_util the pdns_server would not get blocked as the pdns_util process would do the AXFR and not pdns_server? Will it use the same codebase? So, if AXFR in pdns_util works/fails it will behave identical in pdns_server?

[zeha]

pdnsutil never talks to pdns_server but does everything behind its back. So it doesn't influence the running process from that PoV. It already shares 95% of its code with pdns_server.
However, we still can't just call suck, as that writes into the DB, and I think that's exactly what you didn't want.

[klaus-nicat]

Indeed, I do not want to write. Or, it should write but ROLLBACK instead of COMMIT to be as much as possible identical to what pdns_server would do.
Will pdnsutil also honor query-local-address when used with --config-name? Because the AXFR must use a certain src-ip.