Automatic captive portal detection is problematic because some networks redirect outbound traffic and others block DNS requests entirely

I am trying to automate captive portal detection on an IoT device. My basic understanding of a typical captive portal is that it checks a device's MAC address on connection, and if the device's user hasn't already agreed to the network owner's T&Cs then it will redirect all outgoing traffic to its splash page. This is easy to check for with curl, because if we try to access a known URL and get a 3XX html code instead then we know we're being sent elsewhere.

In testing, we're actually seeing a lot of enterprise captive portals that either drop or block access to a DNS server entirely, meaning that curl can't resolve any host that I give to it. However, the network is still able to redirect a web browser to a captive portal login page. How is the network/router able to do this without giving a device to access a DNS server and then redirecting its traffic? And is there a more reliable way to detect a network with this configuration, beyond hoping that any curl: (6) Could not resolve host: captive.apple.com means that I'm on a captive network?