As a specific clarification, mandatory doesn't work this way.
It is purely about if the client recognizes the SvcParamKey.
>From RFC9460 Section 8 (
https://datatracker.ietf.org/doc/html/rfc9460#mandatory)

In a ServiceMode RR, a SvcParamKey is considered "mandatory" if the RR will
not function correctly for clients that ignore this SvcParamKey. [...]

A ServiceMode RR is considered "compatible" by a client if the client
recognizes all the mandatory keys and their values indicate that successful
connection establishment is possible

For example the https scheme mapping in the RFC includes "port,
no-default-alpn" as automatically mandatory.
This just means that https implementations must recognize them and know
what to do with them and skip the records if they don't.
This is independent of the client capabilities (eg, does it have IPv6
connectivity and thus the ability to use an ipv6hint).

Best, Erik




On Tue, Jul 7, 2026 at 9:51 AM Niall O'Reilly <[email protected]> wrote:

> On 7 Jul 2026, at 4:02, Jan Schaumann wrote:
>
> Perhaps it would be useful to include in the draft a
> brief description why that is insufficient and whether
> the anticipation is that browsers will (eventually)
> *not* race HTTPS and A/AAAA lookups but *only* use
> HTTPS lookups (or use those as blocking prior to any
> A/AAAA lookups).
>
> This.
>
> Besides, I wonder whether the proposal offers any new
> semantics beyond what is already possible by omitting
> the "ipv4hint" parameter while providing the "ipv6hint"
> one. For emphasis, one might set the "mandatory" parameter
> to include "ipv6hint", and reference the IPv4 endpoint
> in a separate SVCB-compatible RR with relatively
> unfavourable SvcPriority.
>
> Modulo my syntax errors, here is an example of what
> I have in mind.
>
> $ORIGIN example.com                        ;; or whatever
> info HTTPS    5 . mandatory=ipv6hint ipv6hint=2001:db8::5
> info HTTPS 5000 .                  ;; fallback to default
> info AAAA  2001:db8::5
> info A     192.0.2.5
>
> ATB, Niall
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to