If it's DNS based, there should be simpler workarounds, so I guess it's just IP based?
While this doesn't directly address Delta's captive portal implementation, on many TP-Link Omada wireless APs, there is a feature that allows you to create a captive portal, and when doing this, you can either whitelist a website by its hostname or by its IP address. I was curious as to how it was filtering by hostname, so I ran a few DNS queries, which all resolved normally, indicating that it wasn't a DNS-based whitelist. Seeing as the whitelisting also worked over HTTPS, I assumed it was TLS-SNI. It turns out that anyone can whitelist any IP address by visiting any website while sending the SNI of a whitelisted hostname. This caused the AP's software to create a firewall rule allowing access to the IP address associated with the spoofed SNI. After doing this, it was then possible to connect to any website hosted on that IP address with any SNI hostname.
There are lots of possible ways to identify WhatsApp traffic, but I never had a chance to figure out what they were really doing. During that time period, if I was on a flight, I was usually with my young child and it's hard to keep focus for debugging networking on a plane, anyway. What I saw when I was looking was more like what joshvm describes elsewhere. The messaging only plans seem to allow most low bandwidth connections, with high latency, but they'll actively supress some things, and others stall beyond some threshold; sometimes you could get a couple media files to transfer, but then it would stop, etc. WhatsApp was engineered to work with the world's terrible networks, so it will usually work ok for messaging as long as packets get through eventually; connection and ping timeouts are long on client and server, because sometimes it takes a lot of seconds. If DNS doesn't work, that's fine too. Multimedia would usually retry and resume enough to work even if connections didn't last long, so I'd guess there was something actively supressing that, but I don't really know.
FWIW, chat isn't TLS, so SNI isn't the answer there, although at least in the past, the protocol was very identifyable. Been gone for a while and don't regularly tcpdump my connections to WA anymore, so I don't know if that changed though. Multimedia is https, and probably has SNI, although that used to vary by platform.
And you say there's no segregation between chat and media - and I trust your out of date info more than my completely made up guesses.
You also need to make sure the DNS server will only resolve the domains you want it to, because if you allow unfiltered dns requests to arbitrary domains, anyone can then tunnel their traffic over DNS, as another comment on this thread pointed out.
I would also assume that Whatsapp might change the servers used with updates of the app. How would Delta deal with that? Just wait for the complaints to come in?
Since on a flight it's likely everyone will use the same resolver on the ground somewhere in Delta's infrastructure a simple mechanism to resolve the IP periodically and update a whitelist (or to cache one VIP location and always return that) might work. Alternatively, as other commenters have suggested, it'd be better to identify traffic with SNI or other profiling.
Updates to the app almost certainly won't change the address it connects to.
Well, they have before. There's four generations of hostnames that were used before g. But g seems likely to work for quite a while.