Split the state machine out of DnsOverHttps#9569
Conversation
9d29761 to
9b10942
Compare
There's a few things that are a bit awkward, but overall it seems like it'll afford swapping in UDP or Android's resolver.
9b10942 to
d5aa220
Compare
| import okhttp3.Protocol | ||
|
|
||
| /** | ||
| * State machine for DNS calls. This is intended for use with any transport for the queries, such |
| add(DnsMessage.query(call.request.hostname, TYPE_HTTPS)) | ||
| } | ||
| if (includeIPv6) { | ||
| add(DnsMessage.query(call.request.hostname, TYPE_AAAA)) |
There was a problem hiding this comment.
If I wanted to use this for Android and I have two calls to make
a) async blocking InetAddress.getAllByName
b) DnsResolver rawQuery
is that stretching it past being a useful correct abstraction?
What would the calls be? and what would the Transport return as Q?
There was a problem hiding this comment.
Could you use DnsResolver for TYPE_A, TYPE_AAAA, and TYPE_HTTPS ?
There was a problem hiding this comment.
No, we lose a lot of caching and RFC level sorting if we do that.
Even if we break out the RFCs and fix a bunch of things, I've been advised that will perform worse.
We should call either InetAddress.getAllByName() or Network.getAllByName()
There was a problem hiding this comment.
Gotcha.
Does that drawback apply to DnsOverHttps also? Might be worth fixing regardless.
I suspect the ‘perform worse’ is gonna be due to operating system-layer caching? (I can’t think of anything else that’d allow the syscall to run faster than what we can do.)
There was a problem hiding this comment.
No, sort of, maybe, yes?
perform worse is likely
- Android caching in the java layer, avoiding actual DNS work, and resetting when network changes. and other things.
- OkHttp does not correctly sort ip addresses in a way that would avoid some obvious bad patterns.
There was a problem hiding this comment.
Let’s correctly sort IP addresses!
There's a few things that are a bit awkward, but overall it seems like it'll afford swapping in UDP or Android's resolver.