search

PowerDNS / pdns

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

Reduce query load for activated DNAME processing #13494

Open rz60 opened 1 year ago

rz60 commented 1 year ago

Short description

Proposal for optimizing the DNAME processing algorithm when dname-processing=yes is configured for the server. Could this server-wide control parameter alternatively be used on a 'per zone basis', to keep the query load low for those zones on the server that do not contain a DNAME RR (respectively for those that are administratively not DNAME processing)? This would be also an arbitrary setting, as it is yet by the existing server-wide control parameter.

Usecase

According to the description of the static server config parameter dname-processing: "This approximately doubles query load", the idea or goal is to reduce the query load as far as possible by explicitely specifying the zones which should process DNAMEs (DNAME substitution, CNAME synthesis), or which should not. Zones that are not specified this way could be handled in the same way as the static control parameter setting for dname-processing would.

Description

Referring to the server algorithm described in RFC6672 [1], the matching zone to the given QNAME will be determined in step 2. If successful, step 3 with the recursive database query part for the DNAME processing (3.C.) follows; otherwise follows step 4 that linearly continues to exit.

Thus it seems possible to retrieve the dname-processing setting for the resolved zone in step 2 if it was successful, and continue the algorithm based on the setting for dname-processing=yes of the matching zone. If step 2 was not successful, step 4 has to follow, where mainly cache lookups occur, which can be made regardless of the dname-processing setting; that is, they are always being made. Based on this steps the conclusion seems obvious that a zone related parameter lookup for dname-processing at the time the zone is being determined would be useful. This could be achieved by introducing a new domainmetadata setting (e.g. with the same or a similar name) DNAME-PROCESSING with values "1" or "0".

A parallel existence of both variants (the previous known static server config parameter and the hereby new proposed domainmetadata setting) could be realized with a priority condition, e.g. the static config parameter is the default for all zones, and an existing domainmetadata setting overrides it for its assigned zone.

This proposal contains no dependency between the effective DNAME processing setting and the fact that a DNAME RR exists in any zones that the server ist authoritative for. If required, such a dependency could be achieved by backend database design rules or application logic. This is not part of the issue.

Yet another thought: The fact that a DNAME RR exists at the zone apex could be also interesting for further optimization (if not already being considered), hence it guarantees that no labels except the zone apex itself can exist in that zone (and if the do, they would have to be ignored).

[1] https://www.rfc-editor.org/rfc/rfc6672#section-3.2

Habbie commented 1 year ago

Did you test if the "doubles query load" note is still true? We changed a lot of code since I added that warning.

rz60 commented 1 year ago

no. we are in a first testing phase (yet for server version 4.6; 4.8 will soon be used together with postgres16). I just activated query-logging=yes loglevel=7 to see approx. what happens. but did not test zones that contain no DNAME rr.