On Jul 7, 2025, at 8:13 PM, Tommy Jensen <[email protected]> wrote:
This Message Is From an Untrusted Sender You have not previously corresponded with this sender. Comments in-line. Meta note: it seems your concerns are all focused on the way allow/block traffic enforcement consumes this information. Do you have any concerns with the ability to discover associations for logging and audit purposes? For logging and audit purposes the standard practice is to use PTR records, which are more precise than CIDRS and have clearer semantics. On 7/7/25 15:58, Ben Schwartz wrote: 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. The comparison with NAT seems like a weird apples-to-mangoes comparison. They’re both situations where the apparent behavior of the IP layer is inconsistent, and depends on prior history. This breaks the end-to-end IP model, complicates debugging, etc. I could have said “stateful firewall” instead. ... Anyway, how is this different from enforcement of IP allow/block based on other dynamic, non-IP logic such as which process it originated from or what the current time is, both common practices today that are "history from 'outside' of IP"? Neither of those are “history”. They are information contemporaneous with the access decision. 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. Implementations may end up doing this, sure, but it isn't inevitable. I know my previous employer's implementation of DNS-based allowlisting has a long-term approval time period that well exceeds most TTL values, because in real life, everyone continues using resolutions for as long as possible. Breaking connectivity just because a cache was cleared (for any reason) was deemed unacceptable. In other words: this is up to the implementation of the enforcement. This seems like a great example of how this is going to fail in nasty, confusing ways. QUIC connections will happily live for days, for example, but this mechanism means that _sometimes_ those connections are going to fail because of an invisible timeout. Those failures will probably exhibit blackhole behavior, resulting in an outage (of probably at least 30 seconds) while the connection attempts to get through, eventually gives up, and falls back to an application-level reconnect (which may also be user-visible). 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. Two things: (1) you are assuming the deployer is a *network* operator and not a *device* operator. What about when there is no network "edge" to manage? On-device enforcement seems like it doesn’t need this mechanism. Apps can be identified reliably, and can ship their own network access policy signed by the publisher, etc. ... It is absolutely true that trust in an endpoint, defined by any identifier, has risks. A firewall rule that blocks specific IP addresses isn't perfect when an allowed IP address will proxy traffic to those same IP addresses. I do not see how this draft introduces a new paradigm in that regard. AFAICT this draft is only relevant in cases where 1. An application bootstraps via DNS 2. The application then begins to communicate with other IP addresses without resolving them from names. 3. These address literals haven’t been communicated to the firewall in advance. 4. The firewall does not normally allow client-initiated access to these IPs. 5. The firewall wants this application to have access to unrecognized IPs. 6. The application’s traffic is not identified in any other way. If our only examples of this usage pattern are cases (like TURN) where the policy is not an effective security measure, then it doesn’t make sense to build standards to support it. ... As for assigning DNS names to <whatever>... yes, I would very much like that, but this requires the same operator to control the managed endpoints *and* all services they connect to. That isn't reflective of reality, where everyone has dependencies on many third parties who can define their endpoints by domain name or IP addresses. Third-party IP address literal dependencies are rare in client applications. When they do exist, there is often no guarantee that they will stay within a particular CIDR. For example, consumer VPN operators often distribute server IPs as IP literals, but they generally do not promise that those IPs will fall in any particular range. ... Even though there are services which operate this way, many do limit and actively communicate their CIDR dependencies. Could you point to some examples of services that fit this pattern _and_ require IP-literal-based communication with these endpoints from enterprise clients? —Ben
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
