Yes, you are off base. We don't care at all about the traffic ratio with 1.1.1.1.

I would be very curious to find out what the actual bandwidth looks like.

I vaguely recall a site that that shows approximate throughput for given properties but I can't remember the terms to google for to (re)find it. But 1.1.1.1 might not be listed - or the numbers might only represent valid traffic and be wildly inaccurate.

Traffic breakdowns would thus be very interesting to see (for whatever is shareable, at least - heh, you'd probably have enough fireside stories to drown multiple HNs with :) ). In the case of 1.1.1.1 I'm wondering about what percentage of traffic is coming from valid DNS clients (and I also wonder where the requests are coming from - although that's just trivia to me), versus eg nonsense from horribly misconfigured lightbulbs.

I'm 95 percent sure that every dns response is bigger than the request, so it might not help much. Although if they're getting a lot of garbage in it might be helpful.

It depends on what methodology is used to classify traffic as inbound/outbound. The large DNS response in your example counts as outbound packets, but it's part of an inbound TCP connection. I don't know how peering agreements work.

Interesting.

I would have thought that they would go with the simplest measure possible, bytes in vs bytes out.

Pardon the ignorance, but I'm curious: why is it important for them (or anybody) to receive inbound traffic, given they offer 1.1.1.1 for free? And also what does it mean "This balance is important in deciding whether their peering is settlement free."?

I'm not a network engineer, so take this with as much credibility as you'd give an explanation after a few beers:

Most network providers have peering agreements to handle reciprocal traffic flows. In other words, if you're Comcast, you send a shit-ton of traffic to, say, Verizon. But Verizon also sends a shit-ton of traffic to you, as well. Generally, companies will have peering agreements that express the price for which they will route traffic for other network providers, and generally if there's a lot of reciprocal traffic, the peering will be "settlement free" - in other words, neither party charges the other to route traffic. So, in the example above, you as Comcast would agree to route Verizon's traffic across your network for free as long as Verizon did the same.

Cloudflare is a CDN, which means they push a LOT of traffic out across a lot of networks, and it's likely they're not getting as much inbound traffic as they're pushing out. That makes it harder for them to negotiate settlement-free peering, since they're not providing as much reciprocal value to their partners. By owning 1.1.1.1, they can now claim any trafic sent to that IP as "inbound" to Cloudflare's networks for the sake of peering agreements. Since 1.1.1.1 gets a bunch of traffic from either misconfigured equipment or people doing silly tests, routing that traffic helps improve Cloudflare's ability to negotiate better peering agreements.

Which, honestly, is pretty clever, since most of that traffic is garbage.

Balanced inbound/outbound traffic only matters for transit networks. That is, networks which are neither the source nor destination of the traffic they carry.

Nobody expects a residential ISP or a CDN to have balanced flows at part of a settlement-free peering agreement.

Cloudflare as a CDN with a lot of peering connections likely helps reduce internal traffic for other carriers by virtue of having endpoint data sources close to the destinations of the data.