Deutsch   English   Français   Italiano  
<d591nag9wral$.dlg@v.nguard.lh>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!1.us.feeder.erje.net!feeder.erje.net!news.quux.org!weretis.net!feeder8.news.weretis.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: VanguardLH <V@nguard.LH>
Newsgroups: comp.mobile.android
Subject: Re: blocking ads in apps
Date: Thu, 7 Mar 2024 04:11:11 -0600
Organization: Usenet Elder
Lines: 34
Sender: V@nguard.LH
Message-ID: <d591nag9wral$.dlg@v.nguard.lh>
References: <urrh3l$11qcg$1@dont-email.me> <tqzjs2e8my6$.dlg@v.nguard.lh> <urt51d$qj57$1@solani.org> <ddm2jq96xwsj$.dlg@v.nguard.lh> <urtmbg$qkb2$1@solani.org> <9gteu7yrmr3o.dlg@v.nguard.lh> <uruqnq$r5lq$1@solani.org> <1hkb4t0iz4f7f$.dlg@v.nguard.lh> <us0n5p$scvd$1@solani.org> <zfpqohdeb6vb$.dlg@v.nguard.lh> <us1go3$sq58$1@solani.org> <93jp5fetvgmn$.dlg@v.nguard.lh> <us2gl8$t2fq$1@solani.org> <t89d094xgey9$.dlg@v.nguard.lh> <usbr0l$1398a$1@i2pn2.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net +MMnQhjEzCqusKq9GZ6k/AXM/KoD2R0McPTw0Zq9gYqvdkfI0b
Keywords: VanguardLH,VLH
Cancel-Lock: sha1:07IPwqaIINsF8Rq0qI/r/Phencs= sha256:HqkkTQio990CQZfK6c4etSvb4Nqh8VDPJxUo/SHoo9k=
User-Agent: 40tude_Dialog/2.0.15.41
Bytes: 3388

david <this@is.invalid> wrote:

> Using <news:t89d094xgey9$.dlg@v.nguard.lh>, VanguardLH wrote:
> 
>>> The final DNS query is encrypted for sure, that much even I'm aware of.
>>> But how Private DNS blocks ads is still a mystery to me.
>> 
>> The DNS server returns a fail status to the client on a DNS lookup that
>> is "blocked".  Blocking at the DNS server is by failing DNS lookups to
>> the client.  So, depends on which DNS server to which you connect
>> whether it blocks nothing or something.  The Cloudflare and Google DNS
>> don't block anything.  AdGuard DNS says what they block (fail the
>> lookups) at their web site to which I gave the URL.
> 
> https://developers.google.com/speed/public-dns/docs/dns-over-tls
> https://developers.google.com/speed/public-dns/docs/dns-over-tls#how_it_works
> 
> 1. The stub resolver is configured with the DNS-over-TLS resolver name dns.google.
> 2. The stub resolver obtains the IP address(es) for dns.google using the local DNS resolver.
> 3. The stub resolver makes a TCP connection to port 853 at one of those IP addresses.
> 4. The stub resolver initiates a TLS handshake with the Google Public DNS resolver.
> 5. The Google Public DNS server returns its TLS certificate along with a full chain of TLS certificates up to a trusted root certificate.
> 6. The stub resolver verifies the server's identity based on the certificates presented.
>    If the identity cannot be validated, DNS name resolution fails and the stub resolver returns an error.
> 7. After the TLS connection is established, the stub resolver has a secure communication path between to a Google Public DNS server.
> 8. Now the stub resolver can send DNS queries and receive responses over the connection.

Guess the point that encrypted DNS (DoH or DoT) is about secreting the
traffic, and ad, phish, malware, porn, or other blocking is a feature of
the DNS server irrelevant of connection type.

A DNS server may not accept encrypted connections, but it might.
A DNS server may not block anything, but it could.
Two different features.  What you get depends on which DNS you use.