Discussion:
[swinog] Google DNS on Salt Mobile
Gregor Riepl
2018-10-29 08:16:59 UTC
Permalink
Hi,

It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).

Is there a particular reason for that?

I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not even ISPs
are providing that service any more...

Thanks for any info.
Greg
xaerni
2018-10-29 08:54:59 UTC
Permalink
Hello.I have read salt has today a Internet problem. When salt now use google Dns. I think they have a Dns Problem.I think this is now as workarround.Greetings XaverVon meinem Samsung Galaxy Smartphone gesendet.
-------- UrsprÃŒngliche Nachricht --------Von: Gregor Riepl <***@gmail.com> Datum: 29.10.18 09:16 (GMT+01:00) An: ***@swinog.ch Betreff: [swinog] Google DNS on Salt Mobile Hi,It seems like Salt is no longer supplying their own DNS servers whenestablishing an LTE connection. Instead, the network responds with Google DNSservers (8.8.8.8 8.8.4.4).Is there a particular reason for that?I'd rather not send all my DNS requests to Google.Perhaps it's time to switch to private resolvers everywhere, if not even ISPsare providing that service any more...Thanks for any info.Greg_______________________________________________swinog mailing ***@lists.swinog.chhttp://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Daniel Stirnimann
2018-10-29 09:13:30 UTC
Permalink
Hello Greg,
Post by Gregor Riepl
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).
They seem to use a mix of Google Public DNS and own resolvers.

I noticed this a year ago as well:
https://twitter.com/seckle_ch/status/935547795066572800

Measurements from Apnic about DNSSEC validation rate for end users of
Salt and use of Google Public DNS does not show a clear trend:
https://stats.labs.apnic.net/dnssec/AS15796?c=CH&g=0&w=30&x=1

Daniel
Gregor Riepl
2018-10-29 18:10:13 UTC
Permalink
Post by Daniel Stirnimann
Post by Gregor Riepl
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).
They seem to use a mix of Google Public DNS and own resolvers.
You are right; the list of servers is somewhat randomised and contains more
than two entries.

Since my local resolver library only supports two DNS servers at once, I
simply wasn't seeing Salt's own DNS server for a while.

Still, I don't think it's very nice to push Google DNS to clients.
Bill Woodcock
2018-10-29 23:25:55 UTC
Permalink
Post by Gregor Riepl
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).
I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not even ISPs
are providing that service any more

For what it’s worth, there’s a Quad9 server cluster in Zurich, and unlike Google, Quad9 is GDPR-compliant. As someone will certainly point out, it’s also subject to US law, but is a public-benefit not-for-profit corporation, and US law doesn’t compel an organization to turn over data which isn’t collected in the first place. And Quad9 is GDPR-compliant because it doesn’t collect source IP addresses in the first place.

And yes, we recommend anyone who has the capacity to do so run their own resolver rather than using _any_ external resolver. Something like 95% of Quad9’s users are behind their own caching resolvers.

-Bill
Jeroen Massar
2018-10-30 06:38:52 UTC
Permalink
Post by Gregor Riepl
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).
I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not even ISPs
are providing that service any more…
For what it’s worth, there’s a Quad9 server cluster in Zurich, and
unlike Google, Quad9 is GDPR-compliant. As someone will certainly
point out, it’s also subject to US law, but is a public-benefit
not-for-profit corporation, and US law doesn’t compel an organization
to turn over data which isn’t collected in the first place. And Quad9
is GDPR-compliant because it doesn’t collect source IP addresses in
the first place.
How can something be "GDPR compliant" when no consent is given at all?
(or have you layered HTTP on top of DNS to provide a 20-pager of
legalise that nobody can be bothered to read as it will change at a
moment's notice?).

Stating "it doesn’t collect source IP addresses" means "but we collect
everything else". Likely doing Passive DNS style things at minimum.


IP addresses, especially sources, sometimes also appear in the label,
simply because some weird CDNs/ISPs will encode the source IP for
'geo-dns' or 'loadbalancing' reasons in the label. Are you stripping
those?

And then there are RBLs, and reverse-IPs in general. Do you filter
those? or do you track those IP Addresses anyway, as that exposes the
other side of the connection....


There are many reasons why so many of the public DNS resolvers popped
up: one of them is the amount of data that can be extracted from it.

Even if it is just the weird domains people look at (and then crawl
those, as they where not known yet), or statistics like "in that ASN
people look at Netflix, but less at Youtube".


Please stop centralizing this Internet thing....

Greets,
Jeroen
And yes, we recommend anyone who has the capacity to do so run their
own resolver rather than using _any_ external resolver. Something
like 95% of Quad9’s users are behind their own caching resolvers.
-Bill
_______________________________________________
swinog mailing list
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
Bill Woodcock
2018-11-01 05:24:17 UTC
Permalink
Post by Jeroen Massar
Post by Bill Woodcock
Post by Gregor Riepl
It seems like Salt is no longer supplying their own DNS servers when
establishing an LTE connection. Instead, the network responds with Google DNS
servers (8.8.8.8 8.8.4.4).
I'd rather not send all my DNS requests to Google.
Perhaps it's time to switch to private resolvers everywhere, if not even ISPs
are providing that service any more

For what it’s worth, there’s a Quad9 server cluster in Zurich, and
unlike Google, Quad9 is GDPR-compliant. As someone will certainly
point out, it’s also subject to US law, but is a public-benefit
not-for-profit corporation, and US law doesn’t compel an organization
to turn over data which isn’t collected in the first place. And Quad9
is GDPR-compliant because it doesn’t collect source IP addresses in
the first place.
How can something be "GDPR compliant" when no consent is given at all?
By not collecting any PII.
Post by Jeroen Massar
Have you layered HTTP on top of DNS to provide a 20-pager of legalise that nobody can be bothered to read as it will change at a moment's notice?
No.
Post by Jeroen Massar
Stating "it doesn’t collect source IP addresses" means "but we collect everything else”.
That’s an obviously false statement, and doesn’t usefully contribute to the conversation.

Quad9 collects:

- Aggregate count of IPv4 queries per site
- Aggregate count of IPv6 queries per site
- Aggregate count of UDP queries per site
- Aggregate count of TCP queries per site
- Aggregate count of TLS queries per site
- Aggregate count of HTTPS queries per site
- Aggregate count of DNScrypt queries per site
- Aggregate count of queries matching each blocked domain per site, for queries which are directed to the malware-filtering addresses.

In the future, Quad9 may also count aggregate number of queries matching blocked domains by origin AS, but there’s no active project to implement that.

If you see a privacy problem with any of that, please tell them. Or tell me, and I’ll pass it along. The entire purpose is to improve privacy and security. If they’re not actually doing that, they’re failing, and there’s no point in doing it if it’s failing.
Post by Jeroen Massar
IP addresses, especially sources, sometimes also appear in the label, simply because some weird CDNs/ISPs will encode the source IP for 'geo-dns' or 'loadbalancing' reasons in the label.
While you’re right, that has no bearing, since the labels aren’t being collected.
Post by Jeroen Massar
Are you stripping those?
Or do you mean RFC 7816? Yes. I believe it may not be entirely rolled out in production yet, but that may have gotten finished while I wasn’t looking.
Post by Jeroen Massar
And then there are RBLs, and reverse-IPs in general. Do you filter those?
Can you ask the question more explicitly? I don’t understand it as stated.
Post by Jeroen Massar
There are many reasons why so many of the public DNS resolvers popped up: one of them is the amount of data that can be extracted from it.
Exactly. And in Quad9’s case the reason is because privacy regulators were looking for an exemplar to use in their argument that collection of PII wasn’t a business requirement for operating a DNS resolver.
Post by Jeroen Massar
Please stop centralizing this Internet thing
.
To the best of my knowledge, I’ve spent the past thirty years doing the opposite. If you have some reason to believe otherwise, please bring it to my attention.

-Bill
Gregor Riepl
2018-11-01 07:45:56 UTC
Permalink
Post by Bill Woodcock
- Aggregate count of IPv4 queries per site
.....
Post by Bill Woodcock
- Aggregate count of queries matching each blocked domain per site, for queries which are directed to the malware-filtering addresses.
In the future, Quad9 may also count aggregate number of queries matching blocked domains by origin AS, but there’s no active project to implement that.
As any other centralised service, a DNS resolver will implicitly collect and
pass on any traffic that goes through it.

DNS has no protections against that, and I believe it was never the point of
the protocol that it does.
Integrity is a bigger issue and there are many examples where it is actively
being violated - this is at least partially addressed by DNSSEC.

The question is what happens with the data. Deleting it right away would be a
good start, and I'm pretty certain Google isn't doing that. Quad9, as you
explained, is at least saying they don't keep any individual records, but
collect aggregate information.
Post by Bill Woodcock
While you’re right, that has no bearing, since the labels aren’t being collected.
In the end, this is a question of who you trust and who you don't.

I'm not sure if switching from one centralised service to another is a good
idea, but my initial complaint was more directed at the fact that an ISP is
delivering data about a customer's habits to the one of the biggest service
providers on the planet on a silver platter, and without their customer's
consent to boot.
That's not ok.
Bill Woodcock
2018-11-01 08:18:48 UTC
Permalink
Post by Bill Woodcock
- Aggregate count of IPv4 queries per site
.....
Post by Bill Woodcock
- Aggregate count of queries matching each blocked domain per site, for queries which are directed to the malware-filtering addresses.
In the future, Quad9 may also count aggregate number of queries matching blocked domains by origin AS, but there’s no active project to implement that.
As any other centralised service, a DNS resolver will implicitly collect

The word “collect” is generally understood to mean “record” or “retain” and I’ve used it in that sense. By intention and design, neither of those are true for Quad9, with respect to any PII. No PII is recorded or retained, except in the sense that the source IP address of any query is used to address the reply.

and pass on any traffic that goes through it.
No, that’s false. Please read RFCs 7816 and 7871. Quad9 implements the former and not the latter, in order to minimize the leakage of data from end-user to authoritative server. Moreover, that’s only an issue with zones for which PCH is not authoritative. For all those for which PCH is authoritative, no queries pass “through” to anywhere else.

Again, if, after acquainting yourself with Quad9’s practices and the relevant RFCs, you see any way in which Quad9 could provide better privacy or security protections to users, they would VERY MUCH LIKE YOUR CONSTRUCTIVE INPUT, as that’s the entire point. It’s an open and transparent community project, to serve the community.
Integrity is a bigger issue and there are many examples where it is actively
being violated - this is at least partially addressed by DNSSEC.
Which is why Quad9 was the first global anycast resolver to implement DNSSEC validation, and why PCH is the only DNSSEC operator besides ICANN to implement FIPS 140-2 Level 4 security.
The question is what happens with the data.
Only if “the data” is collected in the first place, and I regard doing so as a failure. If data is collected, it will inevitably be breached or disclosed. The only defense against this is to not collect data in the first place. Which, again, is the entire point of Quad9.
Post by Bill Woodcock
While you’re right, that has no bearing, since the labels aren’t being collected.
In the end, this is a question of who you trust and who you don’t.
Exactly. The reasonable thing to do is to operate your own RFC 7816-compliant caching resolver at your border, and use a recursive resolver with policies that match your self-interest. And that’s what ~95% of Quad9’s users do, to the best of their understanding. Which is admittedly/purposely/by-design a limited understanding, since there’s no institutionalized concept of a “user.” However, since it’s a community, there’s a lot of discussion and mutual support and exchange of anecdotal information. And during the pilot (November 2016-November 2017) there was active interaction with the pilot users.
My initial complaint was more directed at the fact that an ISP is
delivering data about a customer's habits to the one of the biggest service
providers on the planet on a silver platter, and without their customer's
consent to boot.
That's not ok.
Completely agreed.

Unfortunately, nearly all large ISPs and many small ones are doing this, though usually not in as obvious a fashion as you observed. Most outsource operation of “their” resolvers to companies which monetize on the back end, without changing the IP address.

-Bill
Jeroen Massar
2018-11-01 20:50:49 UTC
Permalink
On 2018-11-01 09:18, Bill Woodcock wrote:
[..]
No, that’s false. Please read RFCs 7816 and 7871. Quad9 implements
the former and not the latter
And because of the latter instead of going to the local ISP netflix
cache one might go to the country-level cache or because it does not
know better to the continental cache. GeoDNS goes rather bad when the
source address is odd.
Next to the problem of load-balancing or traffic engineering that the
sending party is trying to fix by doing those tricks in the first place.


Hence, supporting ENDS-Client-Subnet (stripping at minimum to BGP or /24
or /48 subnet) would be a good thing.
If it is not considered a good thing, a little note on the site why not
would go a long way.
Again, if, after acquainting yourself with Quad9’s practices and the
relevant RFCs, you see any way in which Quad9 could provide better
privacy or security protections to users, they would VERY MUCH LIKE
YOUR CONSTRUCTIVE INPUT, as that’s the entire point. It’s an open and
transparent community project, to serve the community.
- Please put on the quad9 website a _versioned_ "policy" and "privacy"
page, thus that one can also see the previous editions. That would be
good transparency.
- align https://quad9.net/about/ with them, as "policy" does not mention
"no other secondary revenue streams for personally-identifiable data"
which is a 'good' sentence, but needs repeating there too.
- Create a minimal version of those; 99% of the people do not bother
reading them at all, let alone when too long.

- Provide a /technical/ details page:
- what software is used (e.g "we run bind4 custom patched by vix
himself") and when possible point to Open Source to recognize their
efforts (one does run multiple different resolver types to avoid any
bugs I hope ;)
- what actual RFCs/techniques are (not) used
- why for instance RFC7871 is chosen not be to be supported
- that DNSSEC is supported and that validation is active

- list of providers of 'malicious domains' and who randomly
samples/verifies that list (otherwise: who censors it)
"Quad9 checks the site against a list of domains combined from 19
different threat intelligence partners."
does one hit in a list block the domain, or do N lists (RPZ?) need to
blacklist it?
(RPZ does not have spamassassin-like scoring, asked for that option
once though, but it is hard to do ;)

Technical details (even though not verifiable as one does not have
access to the infra) would be a great thing.



Some other not-so-constructive comments (I snipped around those sections
of the mail):

- Remove refs to "not-for-profit" as that just means that all the money
goes into the business instead of paying taxes...
- "The three primary founding collaborators for the project have goals
that are similar.", I can only assume that Big Blue is not a founding
collaborator then... but the logos tell differently.
in order to minimize the leakage of
data from end-user to authoritative server. Moreover, that’s only an
issue with zones for which PCH is not authoritative. For all those
for which PCH is authoritative, no queries pass “through” to anywhere
else.
(I can only assume that you mean "9.9.9.9 recursor sits on the same
net/vlan/switch as the PCH auth, thus it never leaks ;)
Post by Gregor Riepl
Integrity is a bigger issue and there are many examples where it is actively
being violated - this is at least partially addressed by DNSSEC.
Which is why Quad9 was the first global anycast resolver to implement
DNSSEC validation, and why PCH is the only DNSSEC operator besides
ICANN to implement FIPS 140-2 Level 4 security.
"global anycast resolver". That is a DNS recursor that is 'open for the
world' right? :)



Greets,
Jeroen
Jeroen Massar
2018-11-01 20:26:53 UTC
Permalink
TLDR:
- https://quad9.net/policy/ and https://quad9.net/privacy/ are the
multiple pages of legalese
- it is a long text, not actually mentioning any actual technology
- nobody using 9.9.9.9 will read it as they are using an IP, not a
website with text
- it can change whenever, there are no versions, there is no history
of what changed (archive.org possibly)
- for a variety of reasons IP (and thus PII) might be gathered
anyway
- IP prefixes are summarized, but unknown till which size (IPv6
/48?)
- Undefined what happens with packets towards 9.9.9.9 (is somebody
doing PDNS, or otherwise grabbing bits?)
- Nothing mentioned about RFC7871 (EDNS Client Subnet) which is
required for helping CDNs/Geo-DNS...
more inline ;)


Oh and for the record: Woody, you are not the "problem" here, the
companies around Quad9 though, they have a commercial interest in the
data... somebody has to pay for it, and that can mostly only be solved
with the personal data collection.... nothing is for free in the end and
bills (and woody's :) have to be paid.
[snip]
Post by Bill Woodcock
Post by Jeroen Massar
How can something be "GDPR compliant" when no consent is given at all?
By not collecting any PII.
That is indeed a great start, what one does not have, one cannot abuse.
Post by Bill Woodcock
Post by Jeroen Massar
Have you layered HTTP on top of DNS to provide a 20-pager of legalise
that nobody can be bothered to read as it will change at a moment's
notice?
No.
Post by Jeroen Massar
Stating "it doesn’t collect source IP addresses" means "but we collect
everything else”.
That’s an obviously false statement, and doesn’t usefully contribute
to the conversation.
Strange as https://quad9.net/privacy/ reads:

"We share anonymized data on specific domains (such as domain,
timestamp, geolocation, number of hits, first seen, last seen) with our
threat intelligence partners."

That says "Domains" and possibly labels.
It also says "geolocation" which is derived from an IP, which can be
wildly wrong but also extremely specific...


It is not specified at all what is actually really collected. It would
be great to have a list, or a log example or heck the tool (as it is
likely open source...) of what is actually logged/collected/"shared with
partners".



But more importantly, for us 'geeky people' who run our own domains,
that domain identifies an individual and thus a domain in effect points
to PII..... while 'gmail' is general, 'massar.ch' is not so general any
more...



Next to that labels can include IP addresses (e.g. 1.2.3.4.in-addr.arpa,
but also the forward 4-3-2-1.dsl.isp.example) Noting that these are
looked up by every SMTP server on the planet.

Are you saying you are dropping these labels? As otherwise, you are
collecting PII.


https://quad9.net/policy/ reads:

"This policy may be amended by Quad9, and the new version of the policy
shall become effective upon its posting "

so, as it is not versioned, and previous versions are not available,
that 'policy' can be changed any time.

Today it might look okay, tomorrow, it will not, and then 9.9.9.9 is
hardcoded like 8.8.8.8 and nobody gave consent on the change in policy.


Lets look a bit deeper:
"When you use Quad9 DNS Services, the information we gather aides us to
personalize, improve and operate our infrastructure. "

Personalize? So, as in, P(ersonaliz)eII , how does one "personalize"
when you claim to not collect Personal Information?

"Our normal course of data management does not have any IP address
information or other PII logged to disk or transmitted out of the
location in which the query was received."

What is the "not-normal course"? When is that applied? What happens
then?


Did you note the 20 pages of legalese I mentioned, indeed, there is
about that amount on those pages. Would be cool to have a bullet list of
what is collected...

"We may aggregate certain counters to larger network block levels for
statistical collection purposes"

So, you keep addresses, but at "block" level. For IPv6, is that on /64,
/56 or /48? And for IPv4 /31? ... would be great to specify otherwise
that is a meaningless statement.

"observed behaviors which we deem malicious or anomalous"

Is "trying to resolve a malware URL" considered "malicious"? would be
great to specify this.
(I guess what I know what is written, but hey, it is a policy, thus
legalese and thus, needs to be specific).


"We do keep some generalized location information (at the
city/metropolitan area level) so that we can conduct debugging and
analyze abuse phenomena."

Are you saying that certain "cities" have more abuse than others!? :)

Look, just state that for debugging, IP addresses will be seen, nobody
minds they are in the clear.
But just do not log it and definitely do not automatically share with
"3rd parties"...


I'll skip commenting on the cookie section as that section just violates
any form of 'privacy'...


"Quad9 does not store PII IP address data on permanent storage methods
(disk) or transmit that data out of the datacenter in which the query
was received."

Funny, it actually says exactly that it shares those things with
'partners'...

I'll also skip over that "partner" means $world when one talks about
companies the size of IBM, everybody is a 'partner' (google uses that
same tactic in their 'privacy' policies)

[snip]
Post by Bill Woodcock
If you see a privacy problem with any of that, please tell them. Or
tell me, and I’ll pass it along. The entire purpose is to improve
privacy and security. If they’re not actually doing that, they’re
failing, and there’s no point in doing it if it’s failing.
How is privacy and security improved by sending packets to a third party
one does not have a financial incentive with (if you are not the
customer, you are the product)...

Somebody pays for the infra, thus what are they getting back?
Post by Bill Woodcock
Post by Jeroen Massar
IP addresses, especially sources, sometimes also appear in the label,
simply because some weird CDNs/ISPs will encode the source IP for
'geo-dns' or 'loadbalancing' reasons in the label.
While you’re right, that has no bearing, since the labels aren’t being
collected.
Post by Jeroen Massar
Are you stripping those?
Or do you mean RFC 7816? Yes. I believe it may not be entirely
rolled out in production yet, but that may have gotten finished while
I wasn’t looking.
Post by Jeroen Massar
And then there are RBLs, and reverse-IPs in general. Do you filter those?
Can you ask the question more explicitly? I don’t understand it as
stated.
Simple embedding of IPs in labels. See above in-addr.arpa and
dsl.isp.example examples.


But speaking of RFCs.... RFC7871 (ENDS Client Subnet) is not supported
to optimize all that GeoDNS traffic?
No mention in the 'privacy' or 'policy'.

Would be good to just list the technologies used.
Post by Bill Woodcock
Post by Jeroen Massar
There are many reasons why so many of the public DNS resolvers popped
up: one of them is the amount of data that can be extracted from it.
Exactly. And in Quad9’s case the reason is because privacy regulators
were looking for an exemplar to use in their argument that collection
of PII wasn’t a business requirement for operating a DNS resolver.
ISPs do not have to collect it either, and people already have a
relationship with them and locally, with low latency and full support
desks to help people when there are problems.

Thus the example one is looking for is the ISPs.

Though of course, in the US this might be quite different from other
countries where ISPs work against their customers instead of for them...
Post by Bill Woodcock
Post by Jeroen Massar
Please stop centralizing this Internet thing….
To the best of my knowledge, I’ve spent the past thirty years doing
the opposite. If you have some reason to believe otherwise, please
bring it to my attention.
You indeed have, but the companies involved in quad9 have not...

and while previous work has been awesome, this is a bit the opposite and
centralizes things.

Greets
Jeroen
Rainer Duffner
2018-11-01 20:53:32 UTC
Permalink
On a related note:

Does anyone run a resolver with QNAME-minimization enabled?

Any problems, common or specific to certain domains?
Jeroen Massar
2018-11-01 21:02:13 UTC
Permalink
Post by Rainer Duffner
Does anyone run a resolver with QNAME-minimization enabled?
Any problems, common or specific to certain domains?
At least everybody running unbound is (as it is the default) and unbound
is very often deployed in high-speed recursor situations.

Do note that unbound has a not-default-on strict mode. That means in
non-strict mode (default) it will retry when failures happen. (As such,
a MITM/bad-authoritive could introduce a failure to learn more)

The config option reads and explains reasonably well:
------
qname-minimisation-strict: <yes or no>
QNAME minimisation in strict mode. Do not fall-back to
sending
full QNAME to potentially broken nameservers. A lot of
domains
will not be resolvable when this option in enabled. Only
use if
you know what you are doing. This option only has effect
when
qname-minimisation is enabled. Default is off.
----

Exact details are in the archives of the unbound mailing list...

Greets,
Jeroen

Loading...