search

PowerDNS / pdns

PowerDNS Authoritative, PowerDNS Recursor, dnsdist
https://www.powerdns.com/
GNU General Public License v2.0
3.7k stars 908 forks source link

IXFR response must be SOA only when request serial >= current serial #1192

Closed Korkman closed 10 years ago

Korkman commented 10 years ago

The current implementation of IXFR in PowerDNS always falls back to AXFR without comparing serials. This leads to excess data being sent and discarded client-side. There should be no more data sent following the SOA, as stated in RFC 1995 section 2 paragraph 4. An easy to test example for this is the ISC BIND tool "dig".

Reproduction:

Allow AXFR for client IP in configuration:

allow-axfr-ips=127.0.0.1

Record traffic, for example with wireshark or tcpdump.

Query PowerDNS with a serial equal to or higher than current SOA:

dig -t IXFR=your-current-soa-serial @127.0.0.1 your-zone.com

Current behavior:

dig will close the connection upon receiving first SOA. The error being: more data has been sent by PowerDNS, but is discarded.

Expected behavior:

No excess data.

Reproducable with current Debian Wheezy packages of both products:

pdns 3.1-4 bind9-host 9.8.4.dfsg.P1-6+nmu2+deb7u1

Fix proposal:

Send only SOA when IXFR request serial is equal to or higher than current SOA serial. This will make IXFR actually save traffic.

Habbie commented 10 years ago

Treating this as a feature request as we are conforming to 1995 (section 4 paragraph 1). Testing against 3.3 or git master would be appreciated.

Korkman commented 10 years ago

RFC 1995 is terribly unclear in detail. Section 4 paragraph 1 can be read as "if server does not support true IXFR, just answer AXFR". That is wrong IMHO. Section 2 paragraph 4 must be implemented:

"If an IXFR query with the same or newer version number than that of the server is received, it is replied to with a single SOA record of the server's current version, just as in AXFR."

Strike the latter part, AXFR never did that. When doing IXFR, clients can assume the response is complete when receiving a standalone SOA message with matching serials, and may close the connection. Which is what happens with dig. When doing AXFR on the other hand, the response is incomplete at that point and more data must be expected. So that part cannot be skipped server-side IMHO.