Ben Schwartz <[email protected]> wrote:
    > 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.

I disagree strongly.
What happens today is that service X from vendor Y, which enterprise
approved, gets put into the enterprise firewall.  ALL OVER services get blocked.
So, without this, we get vendor lock-in.

    > 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.

All of those things are happening, poorly, today.

    > 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.

As we discussed with RFC9726, where you suggested IoT devices all use SOCKS, 
this is a non-solution.

    > 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.

They might have to, and I'm not happy about that either.

But, the key point is that they don't list 198.41.0.0/24 (aka 
a.root-servers.net)

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide




Attachment: signature.asc
Description: PGP signature

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to