Quick thoughts: 1. I don't know what this is for. Is it for firewall configuration? Local firewalls or network firewalls? Configured by the client application or by a middlebox? Is this for allowing unexpected inbound traffic, or locking down outbound traffic to unrecognized IPs? Or is this really about annotating traffic for post-hoc analysis?
2. The mention of WebRTC is very puzzling. Most WebRTC services allow direct connection between any pairs of peers in the world, so the CIDRS record would be 0.0.0.0/0. Is that the intent? 3. The draft mentions RFC 9000 server mobility as an example use case. Is that a key motivation? Server-initiated QUIC connection migration is basically impossible due to stateful firewalls (and symmetric NATs), so this is not something that anyone does on the open internet in practice, or could do in the foreseeable future. --Ben ________________________________ From: Tommy Jensen <tojens.i...@gmail.com> Sent: Monday, July 7, 2025 2:51 PM To: dnsop@ietf.org <dnsop@ietf.org> Cc: david.ietf@adamnet.works <david.ietf@adamnet.works>; 'John Todd' <jt...@quad9.net> Subject: [DNSOP] Fwd: New Version Notification for draft-tdj-dnsop-associated-prefixes-for-domains-00.txt Hello dnsop, Another draft, unrelated to my feelings for Classic DNS over UDP. David, John, and I wrote this draft which defines a way to associate IP prefixes with a domain name. This is somewhat reminiscent of the experimental APL record (RFC Hello dnsop, Another draft, unrelated to my feelings for Classic DNS over UDP. David, John, and I wrote this draft which defines a way to associate IP prefixes with a domain name. This is somewhat reminiscent of the experimental APL record (RFC 3123) with more specific structure and intent. The basic idea is there are services identified by a domain name that trigger network traffic being sent to IP addresses other than those in existing DNS RR types. A common example is the use of WebRTC by a program that uses teleconferencing[.]vendor[.]example for initial connections, but ends up streaming to IP addresses not discovered via the DNS. QUIC also supports servers migrating clients to preferred IP addresses which may not be present in the DNS. Such vendors tend to document their required IP prefixes for firewall configuration purposes, but this leads to manual labor by sysadmins to accumulate these, possibly with vendor lock-in mechanisms. This document intends to make that process automatic: instead of tracking separate vendor's documentation or APIs, accumulation of addresses associated with a service is via DNS queries for the vendor's domain names, which do not tend to change frequently. Thanks, Tommy -------- Forwarded Message -------- Subject: New Version Notification for draft-tdj-dnsop-associated-prefixes-for-domains-00.txt Date: Sun, 06 Jul 2025 13:36:28 -0700 From: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> To: David Redekop <david.ietf@adamnet.works><mailto:david.ietf@adamnet.works>, John Todd <jt...@quad9.net><mailto:jt...@quad9.net>, Tommy Jensen <tojens.i...@gmail.com><mailto:tojens.i...@gmail.com> A new version of Internet-Draft draft-tdj-dnsop-associated-prefixes-for-domains-00.txt has been successfully submitted by Tommy Jensen and posted to the IETF repository. Name: draft-tdj-dnsop-associated-prefixes-for-domains Revision: 00 Title: Associated IP Prefixes for Domain Names Date: 2025-07-06 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-tdj-dnsop-associated-prefixes-for-domains-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tdj-dnsop-associated-prefixes-for-domains-00.txt__;!!Bt8RZUm9aw!8nmnWIPwwlwJzBUHNDd0SClYc_iN_jOiJF1f4BgVxtsAnwcNm9kyPtbdwoleUGcDIrcgOFrOaDdqTREv$> Status: https://datatracker.ietf.org/doc/draft-tdj-dnsop-associated-prefixes-for-domains/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tdj-dnsop-associated-prefixes-for-domains/__;!!Bt8RZUm9aw!8nmnWIPwwlwJzBUHNDd0SClYc_iN_jOiJF1f4BgVxtsAnwcNm9kyPtbdwoleUGcDIrcgOFrOaNOGHPJz$> HTML: https://www.ietf.org/archive/id/draft-tdj-dnsop-associated-prefixes-for-domains-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tdj-dnsop-associated-prefixes-for-domains-00.html__;!!Bt8RZUm9aw!8nmnWIPwwlwJzBUHNDd0SClYc_iN_jOiJF1f4BgVxtsAnwcNm9kyPtbdwoleUGcDIrcgOFrOaNir39kZ$> HTMLized: https://datatracker.ietf.org/doc/html/draft-tdj-dnsop-associated-prefixes-for-domains<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-tdj-dnsop-associated-prefixes-for-domains__;!!Bt8RZUm9aw!8nmnWIPwwlwJzBUHNDd0SClYc_iN_jOiJF1f4BgVxtsAnwcNm9kyPtbdwoleUGcDIrcgOFrOaC6bFEI2$> Abstract: RFC9000 defines a mechanism that allows servers to migrate clients to another IP address without name resolution. The new address may not be discoverable as A/AAAA records for that domain name. This draft defines a mechanism that allows a client to get advance notice of associated IP addresses for a domain name as part of the DNS query. The IETF Secretariat
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
