[mitc-gjuge]

What is this PR about?

Follow-up to the review on #5257. upsertRecord listed every record of a zone just to find the one it was about to write, which @narcisonunez pointed out is expensive on large zones. The API supports filtering, so this asks it to filter.

const query = new URLSearchParams({
  "filter[source]": source,
  "filter[types][]": type,
});

The filter matches substrings, so it narrows but does not decide

This is the part worth reviewing. filter[source] is documented with a bare subdomain example (filter[source]=www), and testing it against a live account shows it matches substrings rather than exact values:

filter[source]=autoconfig  -> [autoconfig]
filter[source]=auto        -> [autoconfig, autodiscover]
filter[source]=disco       -> [autodiscover]

So the straightforward version of this change — take the first result the filter returns — would have upserted auto onto the existing autoconfig record and silently overwritten it. The exact comparison is therefore kept on the filtered result: the filter narrows what is transferred over the wire, and the local check still decides what matches. There is a test that fails if the first candidate is trusted.

The apex was the other thing to check, since Infomaniak represents it as "." rather than an empty source. filter[source]=. does return the apex records, and an upsert against an existing apex TXT returns its id instead of creating a second one — verified end to end, since a duplicate at the apex on a zone with MX or SPF records is how mail breaks.

Two smaller behaviours noted while testing: an empty filter[source] is rejected with a validation error (unreachable here — toSource writes "." for the apex, never ""), and a source with no match returns an empty array as expected.

listZoneRecords is unchanged and still used by listRecords, which legitimately needs the whole zone.

Checklist

Before submitting this PR, please make sure that:

• You created a dedicated branch based on the canary branch.
• You have read the suggestions in the CONTRIBUTING.md file https://github.com/Dokploy/dokploy/blob/canary/CONTRIBUTING.md#pull-request
• You have tested this PR in your local instance.

Tested against a real Infomaniak account: record creation, an upsert that finds the existing record through the filter and returns its id rather than duplicating, and an upsert on an existing apex record. The test zone was left with exactly its original records. pnpm -r run typecheck passes and the DNS suite is green (85 tests).

Issues related (if applicable)

Follow-up to a review comment on #5257.

Screenshots (if applicable)

N/A — no user-visible change.

Greptile Summary

This PR reduces Infomaniak upsert lookup cost by filtering DNS records by source and type at the API while retaining an exact local comparison to prevent substring matches from selecting the wrong record.

• Adds a focused filtered-record lookup for upserts.
• Preserves full-zone listing behavior for operations that require every record.
• Adds coverage for query serialization and substring-filter false positives.

Confidence Score: 5/5

The PR appears safe to merge, with no concrete correctness, security, or repository-rule violations identified.

The filtered lookup retains the exact matching behavior that controls update versus create, and the added tests cover both parameter serialization and the documented substring-overmatch case.

_{Reviews (1): Last reviewed commit: "perf(dns): filter Infomaniak records ser..." | Re-trigger Greptile}