handle deSEC canonicalization of record values

[sshine]

plan::build compares desired against stored on deSEC's wire form. convert.rs reproduces two
axes of deSEC's normalization: embedded domain names (rdata_name_field) and TXT quoting
(is_text_type). deSEC normalizes more than that:

Record values that are not given in canonical form, such as 0:0000::1 for an IPv6 address, will
be converted by the API into canonical form (here: ::1). [...] exact validation and
canonicalization depend on the record type.

deSEC docs, RRsets

Where deSEC canonicalizes a value we do not reproduce, the comparison reports a difference that is
not one, and we write. Every cycle, against a budget of 300 per zone per day. That is the write
loop this provider exists to prevent, arriving through the storage path instead of the adjust path.

Why nothing is currently on fire

The two obvious instances are absorbed, both for reasons that are load-bearing and recorded nowhere.

Long TXT. deSEC splits: "Token strings longer than 255 characters are automatically split into
several token strings." We send one chunk and get several back, so the internal comparison genuinely
does differ. It never fires because external-dns never asks: /records reports txt_unquote, which
joins the chunks back into one target.

IPv6 compression. We do nothing here at all. external-dns absorbs it: Targets.Same falls back
to netip.ParseAddr and compares string forms when EqualFold fails.

What is left

Types where deSEC canonicalizes, external-dns's Same does not absorb it (not case-only, not an
IP), and our egress does not map it back. LOC, SVCB/HTTPS parameter ordering and quoting, and
whatever comes next. Narrow, possibly empty in practice, and currently invisible: nothing notices
that an RRset was written and came back different.

adjusting_storing_and_reading_back_is_a_fixpoint cannot catch it, because it round-trips through
our own records_for rather than through a canonicalizing server. docs/testing.md claims the two
property tests make the no-op write loop structurally impossible; that holds for the adjust path
only.

Two claims to correct either way

• docs/testing.md calls the TXT split "the open question only the live layer can answer" and argues
  "we emit a single chunk and store whatever the server returns, so the split should never matter".
  deSEC documents the split, so the question is answered; and the argument is wrong, since storing
  the server's form is exactly what makes the internal comparison differ. The reason it does not
  matter is the egress join.
• txt_quote's doc comment says letting deSEC do the splitting "is what keeps our idea of the split
  from ever disagreeing with its own". The two do disagree; nothing ever compares them.

Options

1. Detect it. write_zone already holds both sides, plan.patches and confirmed. Comparing them
   costs almost nothing and turns the whole open-ended class into one signal, say
   webhook_write_normalized_total{record_type}, plus a log line.
2. Suppress it. Remember, per RRset, which desired form produced the current stored form; a desired
   form we have already written is identical even when the stored bytes differ. General and
   self-teaching, carried through store::publish.
3. Record the external-dns dependency in docs/protocol.md, with a test, so a future change to
   Targets.Same becomes a known risk rather than a mystery.
4. Extend just live-test with long TXT, LOC and HTTPS round trips.

Building 2 before 1 would be writing a mechanism for a failure not yet observed.

[sshine]

Notes for whoever picks up normalization, so the AAAA case does not have to be re-derived.

Do not normalize AAAA without the evidence

The obvious fix is six lines: parse with std::net::Ipv6Addr and re-render in both
canonical_rdata and records_for. It is a trap in one specific spot, because the three
renderers involved do not agree.

form	Rust Ipv6Addr	Go netip.Addr	dnspython inet_ntoa
::ffff:192.0.2.1 (IPv4-mapped)	dotted	dotted, via Is4In6	dotted
::192.0.2.1 (IPv4-compatible, deprecated)	dotted	::c000:201	dotted

If deSEC renders like Go, normalizing with Rust's Display creates a write loop for the
IPv4-compatible form where today there is none. If it renders like dnspython, Rust matches
and the thing at risk is instead external-dns's own absorption. Neither is guessable, and
guessing wrong is worse than not normalizing at all: today an unmodelled type might loop,
whereas a mismatched normalizer will, for every record of that type, forever.

Normalization has to land on both sides

records_for alone is not enough. /records would still report deSEC's form while
/adjustendpoints handed external-dns back the source's, so external-dns would compare
those, differ, and plan an Update every cycle. We would suppress it as identical, so no
write, but that trades a write loop for a perpetual spurious-update loop costing a full plan
cycle per reconcile. canonical_rdata is the other half, and adjust_one already calls it
per target, so the pattern exists.

The evidence base

desec-rs now carries the probe table and a live characterization test:

• crates/desec/src/probes.rs, behind the probes feature. Three AAAA probes bear on this:
  aaaa-expanded for plain zero-compression and hex case, and aaaa-v4mapped-dotted /
  aaaa-v4mapped-hex, which are the same address written two ways so that whichever form
  both come back as is the server's canonical choice rather than an inference.
  aaaa-v4compat-dotted is the row that settles the table above.
• crates/desec/tests/live.rs::record_values_come_back_in_the_form_desec_chose sends them
  to a scratch zone and reports. Every row starts as Expect::Unknown; promoting one is a
  source change, so the answer arrives with a commit message attached.

Until those rows are promoted, webhook_write_normalized_total{record_type} is what says
whether any of this is happening in practice.

[sshine]

The live characterization has been run. Correcting my previous comment: the renderer table
in it was wrong about the IPv4-compatible form, and the measured answer changes the conclusion.

Results are recorded in desec-rs at crates/desec/src/probes.rs, one Expect per probe, with
the module doc carrying a summary. All 25 probes were accepted; nothing was refused, including
SPF and including a DS at a subname with no delegation beside it.

What deSEC rewrites

Stored verbatim: A, CNAME, MX, SRV, NS, PTR, NAPTR, CAA, URI, SPF,
HTTPS in AliasMode, and TXT escapes and author-supplied chunking. Domain names keep their
case; no field is respaced; CAA keeps ISSUE uppercase.

Rewritten:

type	sent	stored
AAAA	2001:0DB8:0000:…:0001	2001:db8::1
AAAA	::ffff:192.0.2.1	::ffff:c000:201
AAAA	::192.0.2.1	::c000:201
DS/TLSA/SSHFP	uppercase hex digest	lowercase
TXT	one 300-char string	split at exactly 255, two character-strings in one value
LOC	42 21 54 N 71 06 18 W 24m 33m 10m 10m	42 21 54.000 N 71 6 18.000 W 24.00m 30.00m 10.00m 10.00m
SVCB	1 svc.Example.ORG. port=443 alpn=h2,h3 ipv6hint=2001:0DB8::1	1 svc.Example.ORG. alpn=h2,h3 port=443 ipv6hint=2001:db8::1
HTTPS	1 . alpn="h3,h2" no-default-alpn ipv4hint=…	1 . alpn=h3,h2 no-default-alpn ipv4hint=…

The correction

My earlier table claimed Rust's Ipv6Addr renders ::192.0.2.1 dotted and that deSEC might
therefore disagree with it. Both halves were wrong. Rust renders that form as ::c000:201,
which is exactly what deSEC stores. The real picture, now pinned by
rust_matches_desec_on_every_ipv6_form_but_the_mapped_one:

• ordinary addresses: Rust matches deSEC
• IPv4-compatible (::192.0.2.1): Rust matches deSEC, both hex
• IPv4-mapped (::ffff:192.0.2.1): Rust and Go render dotted, deSEC stores hex

So a stock renderer gets AAAA right everywhere except the one embedded-IPv4 form anything
modern emits. That is a narrower objection than I gave before, but it still rules out
Ipv6Addr::to_string() as a drop-in.

What this means for the write loop

Filtering by whether external-dns's Targets.Same absorbs the difference:

• AAAA — absorbed. EqualFold fails, then the netip.ParseAddr fallback compares equal
  for all three forms.
• Hex digests — absorbed by EqualFold alone.
• TXT split — absorbed by us, because txt_unquote rejoins chunks on egress, so
  external-dns never sees a difference. The value comes back as one record holding two
  character-strings, which is what the existing model assumes.
• LOC, SVCB, HTTPS with parameters — not absorbed by anything. Not case-only,
  not parseable as an IP. These are live write loops today.

That is the residue this issue predicted, now measured rather than guessed.

Which fix this argues for

LOC is lossy: size is a mantissa-and-exponent byte, so 33m lands on 30.00m, and the
loc-format and loc-quantized probes come back identical despite differing on input.
No string rewriting can reproduce a lossy encoding. SVCB/HTTPS are reproducible in
principle, but only by implementing the parameter registry and its quoting rules.

So option 2 in this issue, remembering the value that was written, is the general answer, and
option 1's normalization is not worth building for any type measured here: the types where it
would be easy are already absorbed, and the types that actually loop are the ones where it is
impossible or expensive.

webhook_write_normalized_total{record_type} now exists and will show whether any of this is
reached in practice before anything is built on top of it.