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

Implement DNS filtering feature #302

Closed
ameshkov opened this issue Dec 23, 2016 · 9 comments

Comments

@ameshkov
Copy link
Member

commented Dec 23, 2016

Here's what we need to do:

  1. Add "DNS filtering" feature. When this feature is enabled, Adguard will filter and block DNS requests and does not need to use Adguard DNS servers.

  2. "DNS filtering" uses the following filters as rules sources:
    Simplified domain names filter
    User filter
    Whitelist

Please note, that it does not depend on whether Simplified domain names filter is enabled or not in the "Filters" section. It will anyway be used by "DNS filtering"

@ameshkov ameshkov added this to the 1.2.0 Pro milestone Dec 23, 2016

@javabean

This comment has been minimized.

Copy link

commented Dec 23, 2016

I can see 2 ways to further improve that feature:

  • allow the user to input her own filter from an external HTTP(s) URL, instead of entering data manually
  • (advanced) allow the user to specify her own DNS server

Actually, the first feature should also be part of Safari content blocking features!

In short: your filter lists are great, but I would like to add my own lists hosted my own server (for both Safari and DNS blocking)… ;-)

Thanks guys!

@ameshkov

This comment has been minimized.

Copy link
Member Author

commented Dec 27, 2016

allow the user to input her own filter from an external HTTP(s) URL, instead of entering data manually

Yeah, I agree with this, there's a feature request about custom filter subscriptions: #50.

What for DNS filtering, I guess we'd better fully separate Safari content blocking filters from the DNS filters. It's just they have different purposes.

(advanced) allow the user to specify her own DNS server

Yep, this should be done for sure as with DNS filtering users no more needs to use AG DNS and can stick with any other DNS.

@javabean

This comment has been minimized.

Copy link

commented Dec 29, 2016

What for DNS filtering, I guess we'd better fully separate Safari content blocking filters from the DNS filters. It's just they have different purposes.

Agreed, they are too different in the end.
Which asks the question: is the AdBlock file format really appropriate to such a DNS list? I would say it is a bit overkill! ;-)

Regarding documentation, it would be incredibly useful to know whether blocking exemple.com will also block subdomains like sub.example.com (please make it so!).
What's used for blocking? NXDOMAIN or 127.0.0.1?

So AdGuard Pro is shaping up nicely with incredible features:

  • block DNS requests within the device
  • and / or use a specified 3rd-party DNS server

I am glad I bought it! :-)

@ameshkov

This comment has been minimized.

Copy link
Member Author

commented Jan 16, 2017

@javabean sorry for the delay, I've just recently got back from vacation.

Which asks the question: is the AdBlock file format really appropriate to such a DNS list? I would say it is a bit overkill! ;-)

Yep, it understands basic rules syntax:
https://adguard.com/en/filterrules.html#basic-rules-syntax

Regarding documentation, it would be incredibly useful to know whether blocking exemple.com will also block subdomains like sub.example.com (please make it so!).

It will:)

What's used for blocking? NXDOMAIN or 127.0.0.1?

DNS server uses 127.0.0.1. However, in the case of on-device DNS filtering we're not yet sure what to choose.

@javabean

This comment has been minimized.

Copy link

commented Jan 19, 2017

It will [block sub-domains]

Fantastic! :-)

DNS server uses 127.0.0.1. However, in the case of on-device DNS filtering we're not yet sure what to choose.

FYI, my own (private) DNS server uses NXDOMAIN with great success. The device doesn't even have to send an UDP DNS request to 127.0.0.1, the DNS resolution simply aborts nicely. Less network traffic = better battery life! :-)

@ameshkov

This comment has been minimized.

Copy link
Member Author

commented Jan 19, 2017

The device doesn't even have to send an UDP DNS request to 127.0.0.1, the DNS resolution simply aborts nicely. Less network traffic = better battery life! :-)

Oh, there's no network connection to 127.0.0.1 anyway, it'll use unix sockets .

What bothers me about NXDOMAIN is if device caches this type of responses.

@ameshkov

This comment has been minimized.

Copy link
Member Author

commented Jan 19, 2017

Ah, my bad, it won't use Unix sockets, who knows why did I write it. Anyway, local net connections work in a bit different way, moreover, nothing listens to it, so connection won't even be established.

@javabean

This comment has been minimized.

Copy link

commented Jan 19, 2017

What bothers me about NXDOMAIN is if device caches this type of responses.

Good catch. In practice, we want to black-list rather long-lived domains. This and the fact that the black-lists will be updated infrequently by the user (she needs to open up the AdGuard application, so the count will be in days or weeks in the better case) means that the OS cache (if any) will most probably be much less than the list refresh delay. So we should be OK. :-)

@ameshkov

This comment has been minimized.

Copy link
Member Author

commented Jan 19, 2017

In the case of local DNS filtering, it is not really important how OS caches responses, as for blocked domain there will be no real DNS request.

However, this is quite important in the case of using AG DNS servers. Currently, the TTL for a blocked domain is 1 hour.

@Stillness-2 Stillness-2 added PRO and removed PRO labels Feb 27, 2017

@Stillness-2 Stillness-2 modified the milestones: 1.2.0 Pro, 1.2.0 Feb 27, 2017

Stillness-2 added a commit that referenced this issue Apr 12, 2017
Stillness-2 added a commit that referenced this issue Apr 12, 2017
ameshkov pushed a commit that referenced this issue Jul 18, 2019
Merge pull request #302 in ADGUARD-IOS/adguard-ios from bug/1083 to m…
…aster

* commit '405e75f15de5c9686df0715bccdc2ac100179f9e':
  Fixed dark theme bug on ios 13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.