Latency observed with Stubby when TLS connections Failed

[amitguptakiitian]

Hi,
I am using the OpenWrt platform and my stubby configurations are as below.
root@OpenWrt:~# uci show stubby
stubby.global=stubby
stubby.global.manual='0'
stubby.global.trigger='wan'
stubby.global.tls_query_padding_blocksize='128'
stubby.global.appdata_dir='/var/lib/stubby'
stubby.global.edns_client_subnet_private='1'
stubby.global.listen_address='127.0.0.1@5453' '0::1@5453'
stubby.global.log_level='7'
stubby.global.round_robin_upstreams='0'
stubby.global.idle_timeout='5000'
stubby.global.tls_authentication='GETDNS_AUTHENTICATION_NONE'
stubby.global.dns_transport='GETDNS_TRANSPORT_TLS' 'GETDNS_TRANSPORT_UDP' 'GETDNS_TRANSPORT_TCP'
stubby.@resolver[0]=resolver
stubby.@resolver[0].address='1.1.1.1'
stubby.@resolver[0].tls_auth_name='one.one.one.one'
stubby.@resolver[1]=resolver
stubby.@resolver[1].address='8.8.8.8'
stubby.@resolver[1].tls_auth_name='dns.google'
stubby.@resolver[2]=resolver
stubby.@resolver[2].address='192.168.1.1'
stubby.@resolver[2].tls_auth_name='dummy.domaindoesnotexists.com'

the third resolver is the ISP DNS Server IP address (here I am using a cascaded router, the upstream points to the first router, that accepts the DNS request in clear ).

I wanted to use 192.168.1.1 (or ISP DNS Server) IP as a fallback server(which supports TCP and UDP only) when the other two fail to resolve the DNS requests.
1.1.1.1 and 8.8.8.8 I have taken as an example here that would be replaced in my project with some third-party custom DNS servers.

I have observed the latency when my thrid party DNS servers were down. Stubby takes more time to resolve or sometimes failed to resolve the DNS request when only 192.168.1.1 is working.

I tested the above use case by configuring the wrong IPs for first two TLS Servers. I changed 1.1.1.1 to 1.1.1.111 and 8.8.8.8 changed to 8.8.8.111 such that first two TLS fail and stubby can use the fallback. with this case, I have observed the latency.

can any confirm if the above configurations hold good? if yes, then is the latency expected or is there some defect in Stubby?

Thanks!

[saradickinson]

Hi there - config looks good but one comment is about stubby.global.round_robin_upstreams='0' This settings means that Stubby tries very hard to use your preferred resolver and will only fall back to the next one after failing to connect to the first one several times, causing some latency. Using a setting of 1 is more robust, but in your case since your third resolver is unencrypted is not ideal as it will get used for every 3rd query. So with your balance between preferring encryption but wanting to be able to fall back to a different unencrypted server you will probably have to accept the latency. Hopefully between those 2 services it would be rare for both to be down - unless you are somewhere that is blocking DNS-over-TLS....

[amitguptakiitian]

Hi @saradickinson
Thanks for confirming the configuration and providing the comments.
Here, I intentionally set the stubby.global.round_robin_upstreams='0' as I don't want to use the fallback server until the first two fail.
Thanks