Adguardhome: [Feature Request] DNSCrypt v2 Support

Created on 13 Jan 2018  ·  21Comments  ·  Source: AdguardTeam/AdGuardHome

Can you please consider supporting the DNSCrypt v2 protocol alongside or instead of the old DNSCrypt.

Thanks

https://github.com/jedisct1/dnscrypt-proxy

question

All 21 comments

@zero77 this is a new client application, the protocol stays the same, so don't worry :)

But does it affect your current code (preformance, compatibility, etc.) ?

But does it affect your current code (preformance, compatibility, etc.) ?

Nope, it does not. We may eventually switch to the new dnscrypt-proxy implementation when it reaches stable stage.

Great! Thanks for the answer.

Where is the sdns stamp produced in AGHome?

How to set to drop all requests other than DNSCrypt ?

AGH supports DNSCrypt upstreams, but it cannot be a DNSCrypt server.

We might add it in the future. Please vote for this feature request if you'd like us to: https://github.com/AdguardTeam/dnsproxy/issues/44

Thanks

Although it would've been nice if that had been clear on :

https://github.com/AdguardTeam/AdGuardHome/wiki/Encryption
https://github.com/AdguardTeam/AdGuardHome/wiki/VPS

As I probably wouldn't have installed had I realised that.

I guess only work around is to install dnscrypt-wrapper in front on AGH but unclear how to setup for DoH / DoT

How do I get the hash for http/2 stamp ?

And how to set so that AGH drops requests without the hash?

Tbh, I thought that it is clear:

How do I get the hash for http/2 stamp ?
And how to set so that AGH drops requests without the hash?

You mean dnscrypt-proxy like certificate-pinning hashes?

We don't support it yet, If you feel that this is important, please file a feature request.

Sorry, I don't understand what exact hash do you mean.

Do you mean a DNS stamp? Or a certificate pinning hash?

DNS Stamp

  • DNSCrypt : isn't supported so cant create an sdns I.e dnscloak for iOS wont work

  • http/2 is supported so dnscloak for iOS could work if create an sdns. But its not working; I think the issue is the hashi. Maybe I am not generating the hash for the sdns correctly.

Is there a setting to drop non sdns requests? To only let users with the sdns connect.

Only other option seems to be to install dnscrypt-wrapper and point it to AGH?

@no-replies got it.

hashi is purely client-side feature. dnscrypt-proxy verifies that your server certificate hash is equal to what was specified in hashi.

http/2 may be supported (sort of) but dnsstamp doesnt work. I think the issue is the hashi

It is optional. If you don't set any hash, dnscrypt-proxy will verify the certificate, but it won't check if hashes are matching (at least this is my understand, I guess @jedisct1 can clarify on this better.

Is there setting to drop non sdns requests. So that can have Doh on VM with open port but only let users with the sdns connect.

This is impossible. In case of HTTP/2, SDNS is internally translated into a simple https URL, so for the server (AG Home) the request looks just like a regular HTTPS request.

Yes which means if client didn't have the hash request should be dropped?

Can you confirm how to generate the hash for the sdns stamp so that I can ensure Im not doing it wrong.

Would this solve it :

Client
http/2
DNSCRYPT-WRAPPER (if no hash drop)
AdGuard home

Hashes for DoH are important. See https://www.reddit.com/r/dnscrypt/comments/a1asu6/dns_stamp_for_quad9_doh_missing_hashes_compared/eapwxkm/ for some details about why they are.

But they are not mandatory. If they are not present, dnscrypt-proxy will indeed just check the certificate.

By the way, starting dnscrypt-proxy will a SHOW_CERTS environment variable defined prints the certificate chain, along with the corresponding hashes.

Thanks. So that explains why I couldn't get the hash to work.

AGH currently only supports "upstream dnscrypt" so whilst dnscrypt clients will be able to connect with http/2 to AGH they won't be able to verify the hash, wont be able log or action filters. @s-s @jedisct1

Think it maybe an idea to update the readme and prioritise the Feature Request

won't be able to verify the hash

They will if you enter the hash properly. Again, verifying hashes is the client-side feature, it has nothing to do with AGH.

Yep I may be doing it wrong. The published public adguard sdns don't appear to have the hash. So I tested by creating sdns with hash for the adguard servers and a test server. All have the same behaviour. Dnscloak can't show logs, doesn't apply filters

Don't have much cert experience.

Test server :

openssl x509 -in /etc/letsencrypt/live/domain.com fullchain.pem -pubkey | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64

I thought this was correct ?

For the adguard servers looked up IP, cert and generated hash (Maybe this is wrong)

The stamps for the AdGuard DoH servers in the public list have the hash.

sdns://AgMAAAAAAAAADzE3Ni4xMDMuMTMwLjEzMCD5_zfwLmMstzhwJcB-V5CKPTcbfJXYzdA5DeIx7ZQ6Eg9kbnMuYWRndWFyZC5jb20KL2Rucy1xdWVyeQ
sdns://AgMAAAAAAAAADzE3Ni4xMDMuMTMwLjEzMiD5_zfwLmMstzhwJcB-V5CKPTcbfJXYzdA5DeIx7ZQ6EhZkbnMtZmFtaWx5LmFkZ3VhcmQuY29tCi9kbnMtcXVlcnk

Hashes: f9ff37f02e632cb7387025c07e57908a3d371b7c95d8cdd0390de231ed943a12

Think this should be reopened.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ammnt picture ammnt  ·  3Comments

hl2guide picture hl2guide  ·  3Comments

alexpovel picture alexpovel  ·  3Comments

s-timm picture s-timm  ·  4Comments

xiaofengcod picture xiaofengcod  ·  3Comments