Update Yandex

[demarcush]

No description provided.

[jedisct1]

IPv6 should remain distinct entries. There's no way to select IPv6 resolvers otherwise.

[demarcush]

Doesn't ipv6_servers = true and ipv4_servers = false do that? I mean I've seen it choose the v6 ones when doing that in the configuration.

[demarcush]

Only use-case I've found for such resolvers being on distinct entries based on their IP protocol is when for example someone specifically wants to use different resolvers with different IP versions e.g.:

server_names = ['yandex-ipv6', 'cloudflare']

and filtering them with ipv*_servers is not possible.

[jedisct1]

I don't think ipv6_servers and ipv4_servers work with DoH. Will have to check, though; I never use DoH.

[demarcush]

I used Meganerd's entries (as they are merged). Here's what I've found during my tests:

The algorithm basically selects a random stamp that belongs to a entry, when using

server_names = ['meganerd']

which is a dnscrypt one, if the randomly chosen stamp matches the ipv*_servers requirements with a logical OR, it will be used, and if not, No servers configured fatal error.
This means when using dnscrypt ones in server_name, it depends on a flip of a coin that it gets to be used (Which is fine with me, as I never try to hard-code anything in my configs).

But with DoH the story gets to be so much more interesting, as the algo only does the random selection and doesn't respect the ipv*_servers reqs; It may do the handshake on IPv6, then switch to IPv4 for a later query and do this back and forth movement between protocols indefinitely.

It's a shame, I thought I could also make public_resolvers.md more compact this way (as encrypted resolvers are becoming a thing).

You think I can open up an issue for dnscrypt-proxy and file this as an issue (or a feature request)? Or should we stick with the current template (as it's the simplest method)?

[demarcush]

But my honest thought about the naming schemes is that they should definitely be reconsidered. With the current one it can be quite ambiguous. A standard should be developed for naming them and get to be strictly applied. Maybe with DNSCrypt v4? I don't know how much the devs and the community are comfortable with breaking changes.

[jedisct1]

This is the original naming scheme. Some people are still running dnscrypt-proxy version 1 or other software that don't even have IPv4/IPv6 selectors.

We can certainly make the current version of dnscrypt-proxy smarter regarding IPv4/IPv6 filters, and define a version 4 of the resolvers list. But it will take years before people upgrade.

But to be honest, I like the fact that IPv6 entries are distinct, and that when we use them, this is explicit. For the same resolver, performance can be very different when reached over IPv4 and IPv6, so it's also nice to have both being probed, and used as needed depending on their latency.

[jedisct1]

BTW I'm at the SYCL conference, so I won't have much time to review/merge these PRs this week.

[demarcush]

I'd love to participate in its upgrades to make dnscrypt-proxy smarter every day. This one funny piece of software removed so much headache from my life.

Regarding the conference, take your time, I'm not going anywhere.

[jedisct1]

The -family variants don't seem to block anything? At least I tried the most popular adult website, and nothing got blocked.

Do they need something else? Maybe a different query path? Do they work at all?

[demarcush]

There's no mention of paths being different: https://dns.yandex.com
And Adguard's doc only contains the DNSCrypt stamps (which are now deactivated).

At first I thought it has something to do with only using the IP in VHOST field (as we see with some resolvers that share the same IP on different tiers but know what to do with the query based on request's SNI); But no, that didn't do it too and I could get correct answers for adult sites again.

What do you propose? Should I add them to the regular yandex and yandex-ipv6 for better reachability?

[jedisct1]

I would remove it, as it doesn't behave as expected. And not include it in the regular yandex since it may still block stuff.

[demarcush]

Done.