Thanks for the explanation. I have serious concerns about proposals that would encourage blocking/unblocking IP addresses based on previous DNS activity. If your network's firewall behavior depends on the history of DNS queries, this creates an extreme form of stateful protocol ossification that prevents IP from working correctly. It's like NAT but worse, because the stateful behaviors at the IP layer depend on history from "outside" of IP. It also messes with DNS (which is a lookup protocol, not a signaling protocol). For example, it creates perverse interactions with DNS stub caching, which one might have to disable in order to generate the DNS query activity that will cause a block to be lifted.
Network operators that want to limit network activity to allowed DNS domains should use a domain-based transport proxy such as HTTP CONNECT, so policies can be imposed before DNS resolution, and each data flow is explicitly tied to its domain. In the specific example of WebRTC relays, I'm not convinced that this approach accomplishes the security goal either. Relay servers (like TURN) are themselves opaque proxies for e2e-encrypted data. If the client is untrusted, giving it access to a TURN server is equivalent to giving it access to the whole internet. Regardless, this use case would be resolved better by giving the relays DNS names that can be approved by the network operator, rather than passing IP literals and then trying to encode (ahead of time!) all potential IP literals that might be used. Consider a VoIP operator that acquires relays (or whatever other literal-addressed resource) dynamically from AWS. In this proposal, they would have to list all of AWS's IP range in their CIDRS records ... substantially defeating the intended security goal. --Ben ________________________________ From: Tommy Jensen <[email protected]> Sent: Monday, July 7, 2025 6:19 PM To: Ben Schwartz <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; 'John Todd' <[email protected]> Subject: Re: [DNSOP] Fwd: New Version Notification for draft-tdj-dnsop-associated-prefixes-for-domains-00.txt On 7/7/25 15: 06, Ben Schwartz wrote: 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 On 7/7/25 15:06, Ben Schwartz wrote: 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? Most all of these, yes. Locking down outbound traffic to unrecognized IP addresses is a primary use case in my mind, though more generally firewall configuration to avoid domain name hacks like SNI inspection is desirable, and post-hoc analysis is always something that making data richer is a good thing (reaction to security events is just as important as trying to prevent them, since 100% prevention is impossible). 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? Definitely not, as short prefixes are discouraged and /0 would be "right out". The example refers to the real-world practice of such applications to have fallback CIDRs that, if unblocked, will ensure the vendor's service always works even if arbitrary destinations are blocked which would otherwise result in more direct paths. 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. No, it was just another example. It would be nice if implementations *could* do that, but if you think it's a low-value example, we can provide more practical examples (such as detail on the teleconferencing case). --Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
