Hi dnsop,

We’ve submitted the below draft as a way to opt-in to a particular SVCB/HTTPS 
record being “globally relevant” across networks, somewhat similar to the 
“persistent” flag in Alt-Svc. 

This came out of some discussion we were having that cross-network behaviors 
really need to be explicitly opt-in.

I would expect this approach is especially useful for deployments using things 
like Anycast.

As always, there are quite a few caveats and situations where on some networks 
a client may prefer not to reuse answers from a different network and 
deployments where this wouldn’t apply.

Suggestions and feedback are most welcome, via email or issues on the GitHub 
repository.

Thanks,
Eric


Begin forwarded message:

> From: [email protected]
> Date: July 6, 2026 at 9:57:14 PM GMT+2
> To: Eric Kinnear <[email protected]>, Ian Swett <[email protected]>, Nidhi 
> Jaju <[email protected]>
> Subject: New Version Notification for 
> draft-kinnear-dnsop-globally-relevant-00.txt
> 
> A new version of Internet-Draft draft-kinnear-dnsop-globally-relevant-00.txt
> has been successfully submitted by Eric Kinnear and posted to the
> IETF repository.
> 
> Name:     draft-kinnear-dnsop-globally-relevant
> Revision: 00
> Title:    Globally Relevant HTTPS RRs
> Date:     2026-07-06
> Group:    Individual Submission
> Pages:    14
> URL:      
> https://www.ietf.org/archive/id/draft-kinnear-dnsop-globally-relevant-00.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-kinnear-dnsop-globally-relevant/
> HTML:     
> https://www.ietf.org/archive/id/draft-kinnear-dnsop-globally-relevant-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-kinnear-dnsop-globally-relevant
> 
> 
> Abstract:
> 
>   DNS answers for SVCB and HTTPS resource records are typically treated
>   as scoped to the network on which they were obtained.  This requires
>   clients to re-resolve DNS when changing network attachments, adding
>   latency to connection establishment.  This document defines a new
>   SvcParamKey, "globally-relevant", for use in SVCB and HTTPS DNS
>   resource records as defined in [RFC9460].  When present, this boolean
>   flag indicates that the service binding parameters in the record are
>   valid regardless of the client's network attachment point.  Clients
>   that observe this flag can reuse cached SVCB and HTTPS records across
>   network changes, subject to normal TTL expiry.
> 
> 
> 
> The IETF Secretariat
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to