Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DNSSEC support #66

Closed
KrasnayaPloshchad opened this issue Oct 18, 2016 · 41 comments
Closed

Add DNSSEC support #66

KrasnayaPloshchad opened this issue Oct 18, 2016 · 41 comments
Assignees
Milestone

Comments

@KrasnayaPloshchad
Copy link

I think adding full DNSSEC validation will making all queries more reliable unless clients explicitly opt out.

@ameshkov
Copy link
Member

It makes sense, thank you for the feature request!

@Itsnothectic
Copy link

I came here to make this same request.

To test if DNSSEC is enabled opening sigfail.verteiltesysteme.net you should get an error. If you test sigok.verteilesysteme.net you should see a blank page.

@sergeevabc
Copy link

Unfortunately, another DNSSEC resolver test fails so far.

@ameshkov
Copy link
Member

Not yet, guys. I am sorry for the delays, we're a bit limited in resources, and I'd like not to switch to DNS tasks until we can really focus on them.

@TPS
Copy link
Contributor

TPS commented Sep 10, 2017

No worries! Just figuring, since DNSCrypt got done, perhaps this got some love as well. Keep on 🚚ing! 📣

@evilvibes
Copy link

Any update on this?

@ameshkov
Copy link
Member

ameshkov commented Jan 3, 2018

@evilvibes we don't want to touch the current installation until the updated version is ready. That's why this issue is still open.

@TPS
Copy link
Contributor

TPS commented Jan 3, 2018

So, does that mean there's ß version someplace? Will it be accessible to play with test sometime?

@ameshkov
Copy link
Member

ameshkov commented Jan 4, 2018

So, does that mean there's ß version someplace? Will it be accessible to play with test sometime?

I'd say it's more of a "demo" at the moment. The old code was tossed out, and the new version is basically a patched Unbound DNS server. Not yet available publicly.

@Corsten56
Copy link

Yes. Will wait for DNSSEC support. Most important thing in modern Russia.

@ibksturm
Copy link

Hi there, any news about dnssec?

and do you think hheres a opinion do start a server in central europe example frankfurt or zurich?

greets

@jonathanmmm
Copy link

Central Europe Server would be great, yes 👍

@ibksturm
Copy link

jupp, would be great, so my route don't have to go over the half of the world as i wrote months ago ^^

@Ryan-Goldstein
Copy link

Any updates on this issue? DNSSEC is very important and has been receiving increased attention lately, including as a part of Cloudflare's Crypto Week 2018 (https://blog.cloudflare.com/automatically-provision-and-maintain-dnssec/).

hmage added a commit that referenced this issue Oct 10, 2018
* commit 'e689c7d940e9a20bc13f024e18b86f3c1e5ba759':
  Do not lose filter name when saving to yaml
  coredns querylog -- since we read entire querylog json once at startup, fill querylog cache from it and then rotate it on each incoming DNS query
  Cache DNS lookups when resolving safebrowsing or parental servers, also cache replacement hostnames as well.
@Who-42
Copy link

Who-42 commented Oct 18, 2018

I was planning to open also a DNSSEC Request but since there is already one, one more who wishes this option

@ameshkov ameshkov added this to the v0.91 milestone Oct 18, 2018
@ameshkov
Copy link
Member

We'll prioritize this issue, guys, thank you!

@ameshkov ameshkov modified the milestones: v0.91, v0.92 Nov 26, 2018
@ibksturm
Copy link

ibksturm commented Dec 7, 2018

news? i looks as the way i'm running AGH dnssec looks like running

@ameshkov ameshkov removed this from the v0.92 milestone Jan 2, 2019
@Mikiya83
Copy link

Do you have any news ? it's a big feature now for a DNS server. Thanks !

@ameshkov
Copy link
Member

ameshkov commented Jan 15, 2019

No news on this yet, sorry

@ameshkov ameshkov added this to the v0.97 milestone Jun 10, 2019
@ameshkov ameshkov modified the milestones: v0.97, v0.98 Jun 25, 2019
@Revertron
Copy link

Just to keep in mind: it should be possible to mark some domains and zones as "unsecure", not to try verification at all.

@ibksturm
Copy link

ьолшо сьасибо 👍

@kmahyyg
Copy link

kmahyyg commented Apr 11, 2020

Recently, I enabled the dnsmasq's DNSSEC on my openwrt router and it works as a dns proxy just working the same as the normal router, AGH on my laptop. I set to use AGH as local dns and CF (DoT) as upstream. However, when dnsmasq's DNSSEC enabled, the AGH failed to dispatch any valid DNS response. According to the verbose log of AGH, it seems that AGH just got connection error from upstream and then returned error(But I'm not so sure about that, my internet connectivity is working properly). I tried to switch off the dnsmasq's DNSSEC, AGH works properly.

Any suggestion?

@ameshkov
Copy link
Member

@kmahyyg have you tried checking what exactly dnsmasq returns for these queries?

@kmahyyg
Copy link

kmahyyg commented Apr 13, 2020 via email

@ameshkov
Copy link
Member

Weird, what kind of connection error does AGH receives?

@kmahyyg
Copy link

kmahyyg commented Apr 13, 2020

Weird, what kind of connection error does AGH receives?

I don't know. I turned on verbose , all logging seems perfect, just get response from upstream as NORESPONSE FROM UPSTREAM. Then dns request timed out. but those domains really exists. I tried to use kdig and set the upstream correctly, the domain is exists.

After I turned off DNSSEC on my router, all things get working. BTW, I'm in china mainland, which has serious network censorship.

@ameshkov
Copy link
Member

ameshkov commented Apr 13, 2020

Could you please post a part of the log with these requests and responses? Maybe I'll notice something there

@kmahyyg
Copy link

kmahyyg commented Apr 16, 2020

Could you please post a part of the log with these requests and responses? Maybe I'll notice something there

logfile-20200416-2.log

Here's the full log after I enabled DNSSEC on my router. Since I've configured the upstream as log shown, it shouldn't be failed to response.

#1579 might be related to this issue.

At the same time when AGH failed,
image

@szolin szolin reopened this Apr 17, 2020
@szolin
Copy link
Contributor

szolin commented Apr 17, 2020

@kmahyyg Can you disable SafeBrowsing ?
In your logs I only see SafeBrowsing: checking... but no sign of the results of SB check. That's very strange considering 3sec timeout for those operations.
Looks like a global dead lock to me: no goroutine has woken up from SB check.

@kmahyyg
Copy link

kmahyyg commented Apr 17, 2020

@kmahyyg Can you disable SafeBrowsing ?
In your logs I only see SafeBrowsing: checking... but no sign of the results of SB check. That's very strange considering 3sec timeout for those operations.
Looks like a global dead lock to me: no goroutine has woken up from SB check.

I will try later... But I think dnssec shouldn't have affiliate with SB?

@ameshkov
Copy link
Member

@szolin

Here's why it happens:

2020/04/16 10:40:18 17356#55 [debug] github.com/AdguardTeam/dnsproxy/upstream.lookup(): successfully finished lookup for dns-family.adguard.com in 59 milliseconds using 176.103.130.131. Result : []
2020/04/16 10:40:18 17356#54 [debug] github.com/AdguardTeam/dnsproxy/upstream.lookup(): successfully finished lookup for dns-family.adguard.com in 78 milliseconds using 176.103.130.130. Result : []

@kmahyyg
Could it be that your router intercepts plain DNS queries and does some additional filtering? Because it seems that when DNSSEC is enabled, we cannot resolve dns-family.adguard.com address (empty "Result: []" in the log)

@kmahyyg
Copy link

kmahyyg commented Apr 17, 2020

@szolin

Here's why it happens:

2020/04/16 10:40:18 17356#55 [debug] github.com/AdguardTeam/dnsproxy/upstream.lookup(): successfully finished lookup for dns-family.adguard.com in 59 milliseconds using 176.103.130.131. Result : []
2020/04/16 10:40:18 17356#54 [debug] github.com/AdguardTeam/dnsproxy/upstream.lookup(): successfully finished lookup for dns-family.adguard.com in 78 milliseconds using 176.103.130.130. Result : []

@kmahyyg
Could it be that your router intercepts plain DNS queries and does some additional filtering? Because it seems that when DNSSEC is enabled, we cannot resolve dns-family.adguard.com address (empty "Result: []" in the log)

pretty weird......

image

@kmahyyg
Copy link

kmahyyg commented Apr 17, 2020

Okay, I see the problem. The last photo is DNSSEC disabled.

image

This is enabled. Problem is SERVFAIL. But even so, this should not happen. Why does DNSSEC use my router's DNS instead of using the upstream DNSs I specified in the AGH setting?

@ameshkov
Copy link
Member

Why does DNSSEC use my router's DNS instead of using the upstream DNSs I specified in the AGH setting?

We use it just one time - when we resolve dns-family.adguard.com address for the first time.

@ibksturm
Copy link

Why does DNSSEC use my router's DNS instead of using the upstream DNSs I specified in the AGH setting?

We use it just one time - when we resolve dns-family.adguard.com address for the first time.

maybe thats the problem... theres a circle

look (example):

routerdns (dnsmasq) 127.0.0.1:53 forwards to AGH on 127.0.0.1:55

AGH ask router onfirst time „hey whats dns-family.adguard...“. router ask back... we‘ve got a circle

possible solution is, if AGH do allways the first request to quad9 or $upstreamresolvers

@szolin
Copy link
Contributor

szolin commented Apr 23, 2020

AGH ask router onfirst time „hey whats dns-family.adguard...“

Are you sure? Can you show the packets AGH sends to your router?
AGH uses these 2 IP addresses "176.103.130.130", "176.103.130.131" to resolve dns-family.adguard.com.

@ameshkov
Copy link
Member

@szolin I suppose that the router may be intercepting plain DNS queries.

@szolin
Copy link
Contributor

szolin commented Apr 23, 2020

I suppose that the router may be intercepting plain DNS queries.

In this case there's nothing wrong with AGH - it's this particular router's configuration problem.

@ameshkov
Copy link
Member

In this case there's nothing wrong with AGH - it's this particular router's configuration problem.

Sure, but we shouldn't be stuck in the case when we cannot resolve that address, the safe browsing check should simply quickly fail

@szolin
Copy link
Contributor

szolin commented Apr 23, 2020

#1612

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests