Subject: Re: [dns-privacy] Summary of the thoughts about DNS privacy

From: Marek Vavruša <[email-masked]>
Date: Tue, 26 Aug 2014 17:01:50 +0200

Hi, I just wanted to chime in that I've read the
draft-bortzmeyer-dnsop-dns-privacy, good stuff.
One of my concerns regarding the privacy is - even with the encryption
and minimization, there's still a lot of information available about
the query resolution, like for example who's asking who, sizes of the
query/response and such. I mean, for example if I'm asking a TLD and
then a hosting company, it's a pretty good chance I'm looking for a
name under that TLD and registered with that company.

I wonder what are your thoughts about something like the onion routing
in the DNS query resolution? Instead of asking the authoritative
servers directly, you could give a small N of random bounces within a
group of name servers, making the exit point (to some extent) random.
This could work even for a partial solution of a query - for example
when resolving multiple NS addresses at once. This presumes a
relatively confident "last mile" between the query originator and the
first bouncing resolver, and unfortunately brings additional costs (in
terms of CPU and bandwidth) for processing bounced queries.

Best,
Marek Vavrusa (CZ.NIC)

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 27 Aug 2014 11:54:11 +0000

Hi Marek,

If you would prefer to do it in the mailinglist, that is fine to me as I only share my own thoughts about DNS privacy. Again I am no more convinced to consider DNS privacy because of the reasons I explained before in mailing list and also here explaining with more example and in different categories.

First of all, please do not think your approach is bad as it already used for several purposes but in my opinion, it does not work for DNS. It is because, in general, there is nothing meaningful are carried by DNS (please see below)

I guess before we go through any solution space, it is required to understand the problem exactly. In other words, answer to this question that what we want to hide from others and who are our target group that we want to hide this data from. Then we can think about whether your solution would help this or not.

First, let's have a different categorization to clarify what we want to hide, and who we want to hide this data from. It actually helps to identify the exact problem and then think about solution space.

In my opinion there are 3 groups of people ( Target User or for short “TU”) who might be interested in our data

1-    a powerful surveillance actor:

This person has power to define a new rule to a country, and all internet traffic flows passed by his devices or the companies who MUST report the information to him. Otherwise those companies will be banned!

2-    A passive surveillance actor:

This can be a government, a colleague of yours or whoever that do not want to others know about his activities. In other words, he doesn’t want to be recognized otherwise he would be in trouble

3-    An attacker:

This person wants to obtain data in whatever way possible. If it is necessary, he would also do active attacks. He would try at the same time to keep himself anonymous but he would do risks to access user’s data.

Now let’s see what information one might obtains from a DNS server, either recursive or TLDs.

1-    Domain names, labels, IP addresses on DNS servers

This data might not be meaningful otherwise it point TU to certain traffics that carry confidential data. It might also lead to a case where TU can find behavior patterns. Of course, gathering this data from a DNS server needs extra effort and needs extra time because he needs to crawl each website to know the content. Also he doesn’t know what a user searched on this website. So he can obtain no precise information.

2-    Source (end user’ IP address) or sender of the data (first point of contact where end user’s device connected to such as a recursive resolver)

Since most users are behind NAT, this might not give much information about an individual but it might be only a general IP address of a network. In case, the target are  messages exchanged between recursive to authoritative name servers, it only expose the source IP address of this recursive (I guess this is where you have concern about)

Now what the purposes of TU might be to analyze the traffic or try to access user’s data (DATA gathering process)

1-    To find users’ behavior and analyze users (this is of course too general. So, TU interested in all traffic to find bindings and matching among traffic flows)

TU group 2 might be interested in.

2-    To gather information about a particular individual and use this data likely against him.

This is what TU group 1,2 and 3 might be interested in.

3-    To gather information about a particular individual only for curiosity but not for any malicious activities.

TU group 2 might be interested in

Now what our purposes might be by hiding the DNS traffic. Our main means of DNS query protection is…: (Our purpose)

1-    To hide who is the data originator (end user) and hide its identity (such as its IP address) behind several other nodes (like what is done in Tor)

Since the originator IP address is not bound to any user, this really not helps.

2-    To disallow user’s behavior analysis and comparison of one user’s behavior with other user’s behavior to find a pattern.

This is of course not possible only by focusing on any DNS traffic, either from stub to recursive or from recursive to authoritative. Why? Because…

-     The source of this data is not an exact user (it is either a public recursive server or a general NAT IP address of a network

-     Domain name, as explained before, doesn’t give any important information about users, its behavior, etc. and you need to do much more efforts to crawl each domain to find out what content the user was looking for. This is, of course, only limited to web sites where you can crawl but not the servers that a user connected only for the means of uploading some files, etc (so, this data is not precise to use it for users’ behavior analysis). You only can gather this information by analyzing and having access to next traffic flows. In this case, TU only focuses on next traffic flows and would not bother himself with DNS traffic analysis.

3-    To disallow anyone to see what I browse or search in my enterprise, public wifi or any other private networks

TU group 1: The content of data is important for him. He doesn’t care what the DNS server have is. He cares about the identity of users and wants to know who browse what. In this case, a user is forced to use his devices and all traffic passed by his devices, either user like this or not but user has no power to prevent him having access to his (user) data. So, he can easily change his role to active attacker in case user uses any encryption to hide the traffic. He already knows the real identity of the user by analyzing next flows and can gather as much information about this user as possible.

TU group2: for this group also the content of data is important. They might not focus on a particular user because the flow matching is what they want to do to find patterns, etc. When the content of data is important, what is happening on DNS server is no interest of him because as I explained earlier, DNS traffic is not meaningful and needs much more effort to make it meaningful and find that bindings between a certain DNS flow to other data flow exchanged between an end user and a service. So, in this case, also randomizing recursive DNS servers and hiding one recursive under the other one is only complicates the query and might need extra time and effort but without having any significant benefits.

TU group3: they are also interested in content of data. They also do risks to be active attacker in order to have access to this data. So, DNS information is no interest of him. He might also not have enough power to sniff all traffic but he would also focus on what he can sniff. He might go to a public wifi network and either sniffs the traffic and if not possible, plays a role of active attacker to obtain data that he looks for.

Now there is one question:

1-    If we hide the identity of data originator that can be an end user or a recursive resolver, does it help to protect users or the data exposes to a certain DNS server?

-     For TU- group 1: No, if it falls into category of data gathering process because an IP address does not bound to a particular user when using NAT or proxy server. But the content of this data exposes the users data

-     For TU- group 2: No, the same reason for TU group 1

-     For TU – group 3: No, again the same reason for TU group 1.

The other reason is that, although that identity is for a particular node (when, for instance, it uses IPv6) but the content of flow (data) would expose information about user. This is of course not the flow that goes to DNS server but it is flows that user start it after this query from DNS server. Now the question is, could you hide data for any means of randomization?

Actually no, because the problem is that the next flows that are the flow from end users to services are important and expose information about user, its behavior, etc.

So, in general, I do not think your approach works here since there is no clear benefit on it. There is only more complexity or might be performance issue because we are going to use several intermediate nodes to answer a query asked by a user or a recursive server.

In other words, DNS traffic does not carry anything interesting information for TU 1,2,3 and only the content of data exchanged after DNS query is important. Usually, when TU is located where it can sniff the DNS flows, it can also sniff next flows that are of his interest(like your example of ISPs). In this case, he skips all DNS flows. In other words, by only analyzing a sample TLD’s traffic or a sample resolver’s traffic, TU cannot gather any meaningful information because…

1-   not all those queries are because a user wants to connect to a website but it can be because this user wants to connect to his file server that has a domain name, thereby he needs to do much more efforts to find out what was the reason for this query to TLD or so. So this is what not of TU’s interest when he has other easier way to gather this information

2-  A website might have several different information and only user is interested in one of that so no precise information can TU gather about a user by he himself crawl a website.

3-  This IP is a general IP address and doesn’t bound to any user

4-  DNS domain names are only no meaningful names and he needs to crawl to find the data or he can easily skip all DNS traffics and only focus on data flows passed by different servers.

I hope I could explain my point clearly here.

I am sorry for a long message….

Best,

Hosnieh

>What I wrote about the onion routing has nothing to with

> protecting the query content, but rather hiding the fact "who's asking".

> Maybe I didn't articulate it clearly enough. Suppose there are three

> traffic observers: the authoritative name server, forwarders, and bad

> guy between the resolver and the auth.

> What happens when user asks a query? All know who's asked, or from

> which network the query originated (because the resolver serves that

> subnet).

> What happens when a query is onion routed first? Bad guy may see only

> part of the traffic, that he is able to sniff (parts of the query may

> have different exit points). Authoritative name servers see the "exit

> point"

> resolver, but can't trace the query back to the first. Forwarders see

> only previous resolver.

> So what have we gained? Neither auth/resolver/bad guy know _who_ asked

> first, unless the query originator reveals himself with edns client

> subnet or something voluntarily.

> Is that worth of the extra cost of bouncing queries? It might be, I

> don't know.

> So, to the "DNS queries carry no important information when the

> surveillance actor have access to the whole traffic flow". That might

> be true, but it's only a one scenario (ISP sniffing on its users).

> For example a root server doesn't see any of your other traffic, but it

> may still know, that you look up an embarrassing website every Monday

> afternoon.

> What I'm most worried about is TLDs, root servers and resolver

> operators collecting traffic. This might be used for a good cause

> (passive DNS, law enforcement), but also for a bad cause.

> We could continue on-list, if you're okay with it, because other people

> might be interested.

> Marek

> On 27 August 2014 10:52, Hosnieh Rafiee <[email-masked]<mailto:[email-masked]>>

> wrote:

> > Offlist

> > Dear Merek,

> > The problem is not how to protect DNS queries. But the problem is

> that DNS queries carry no important information when the surveillance

> actor have access to the whole traffic flow. So, he does not need to

> sniff any DNS traffic at all. So why do we need to complicate our own

> process and our own computation when we do not benefit from it?

> > I hope you understand my point.

> > Hosnieh

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Aug 2014 16:06:21 +1000

In message <CACgotOQXxgzz3XvA7=[email-masked]>
> terms of CPU and bandwidth) for processing bounced queries.

And the point of doing this when the next thing you do is open a
TCP connection to a server is or are you thinking that we should
be using tor for all connections all the time?

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 28 Aug 2014 12:50:41 +0200

Hi Mark,

I'm thinking of bouncing queries between N resolvers, regardless of
what transport protocol they choose to use.
Because the path "client -> resolver -> auth" is easier to trace back
than "client -> resolver -> (random bounces) -> auth".
The only benefit of doing this is the anonymity nearing to that of an
open resolver, without being... open for everyone,
as the resolvers may be only open to each other / secured.
Or do you mean the TCP connection that client possibly opens after
name resolution? Then yes, this does not
prevent eavesdropping between the client and the resolver.

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 28 Aug 2014 13:05:58 +0200

Hi Hosnieh,

it's a little long winded. So, you're questioning the point of DNS
privacy on the basis that it doesn't bring anything useful to the
interested observer?
Sure there's NAT, MITM can eavesdrop your other traffic and so on. But
it is very real for TU2/3 to gather data on the auth/resolvers and use
them as
a forensic evidence, correlating them to other traffic, geolocation
and traffic distribution, whois records etc. with a certain degree of
confidence.
People have started businesses with this sort of information.

Saying DNS traffic does not carry anything interesting is a bold
claim, it might be true, it might be not.
Regardless of how it is, I think that giving less information is
always better, if the cost isn't too high, and I'm happy to discuss
technical questions / ideas.

Best,
Marek

On 27 August 2014 13:54, Hosnieh Rafiee <[email-masked]> wrote:
> Hi Marek,
>
>
>
> If you would prefer to do it in the mailinglist, that is fine to me as I
> only share my own thoughts about DNS privacy. Again I am no more convinced
> to consider DNS privacy because of the reasons I explained before in mailing
> list and also here explaining with more example and in different categories.
>
> First of all, please do not think your approach is bad as it already used
> for several purposes but in my opinion, it does not work for DNS. It is
> because, in general, there is nothing meaningful are carried by DNS (please
> see below)
>
>
>
> I guess before we go through any solution space, it is required to
> understand the problem exactly. In other words, answer to this question that
> what we want to hide from others and who are our target group that we want
> to hide this data from. Then we can think about whether your solution would
> help this or not.
>
>
>
> First, let's have a different categorization to clarify what we want to
> hide, and who we want to hide this data from. It actually helps to identify
> the exact problem and then think about solution space.
>
>
>
> This person has power to define a new rule to a country, and all internet
> traffic flows passed by his devices or the companies who MUST report the
> information to him. Otherwise those companies will be banned!
>
> This can be a government, a colleague of yours or whoever that do not want
> to others know about his activities. In other words, he doesn’t want to be
> recognized otherwise he would be in trouble
>
> 3-    An attacker:
>
> This person wants to obtain data in whatever way possible. If it is
> necessary, he would also do active attacks. He would try at the same time to
> keep himself anonymous but he would do risks to access user’s data.
>
>
>
> This data might not be meaningful otherwise it point TU to certain traffics
> that carry confidential data. It might also lead to a case where TU can find
> behavior patterns. Of course, gathering this data from a DNS server needs
> extra effort and needs extra time because he needs to crawl each website to
> know the content. Also he doesn’t know what a user searched on this website.
> So he can obtain no precise information.
>
> 2-    Source (end user’ IP address) or sender of the data (first point of
> contact where end user’s device connected to such as a recursive resolver)
>
> Since most users are behind NAT, this might not give much information about
> an individual but it might be only a general IP address of a network. In
> case, the target are  messages exchanged between recursive to authoritative
> name servers, it only expose the source IP address of this recursive (I
> guess this is where you have concern about)
>
>
>
> 1-    To find users’ behavior and analyze users (this is of course too
> general. So, TU interested in all traffic to find bindings and matching
> among traffic flows)
>
> 1-    To hide who is the data originator (end user) and hide its identity
> (such as its IP address) behind several other nodes (like what is done in
> Tor)
>
> 2-    To disallow user’s behavior analysis and comparison of one user’s
> behavior with other user’s behavior to find a pattern.
>
> This is of course not possible only by focusing on any DNS traffic, either
> from stub to recursive or from recursive to authoritative. Why? Because…
>
> -     The source of this data is not an exact user (it is either a public
> recursive server or a general NAT IP address of a network
>
> -     Domain name, as explained before, doesn’t give any important
> information about users, its behavior, etc. and you need to do much more
> efforts to crawl each domain to find out what content the user was looking
> for. This is, of course, only limited to web sites where you can crawl but
> not the servers that a user connected only for the means of uploading some
> files, etc (so, this data is not precise to use it for users’ behavior
> analysis). You only can gather this information by analyzing and having
> access to next traffic flows. In this case, TU only focuses on next traffic
> flows and would not bother himself with DNS traffic analysis.
>
>
>
> 3-    To disallow anyone to see what I browse or search in my enterprise,
> public wifi or any other private networks
>
>
>
> TU group 1: The content of data is important for him. He doesn’t care what
> the DNS server have is. He cares about the identity of users and wants to
> know who browse what. In this case, a user is forced to use his devices and
> all traffic passed by his devices, either user like this or not but user has
> no power to prevent him having access to his (user) data. So, he can easily
> change his role to active attacker in case user uses any encryption to hide
> the traffic. He already knows the real identity of the user by analyzing
> next flows and can gather as much information about this user as possible.
>
>
>
> TU group2: for this group also the content of data is important. They might
> not focus on a particular user because the flow matching is what they want
> to do to find patterns, etc. When the content of data is important, what is
> happening on DNS server is no interest of him because as I explained
> earlier, DNS traffic is not meaningful and needs much more effort to make it
> meaningful and find that bindings between a certain DNS flow to other data
> flow exchanged between an end user and a service. So, in this case, also
> randomizing recursive DNS servers and hiding one recursive under the other
> one is only complicates the query and might need extra time and effort but
> without having any significant benefits.
>
>
>
> TU group3: they are also interested in content of data. They also do risks
> to be active attacker in order to have access to this data. So, DNS
> information is no interest of him. He might also not have enough power to
> sniff all traffic but he would also focus on what he can sniff. He might go
> to a public wifi network and either sniffs the traffic and if not possible,
> plays a role of active attacker to obtain data that he looks for.
>
>
>
>
>
> 1-    If we hide the identity of data originator that can be an end user or
> a recursive resolver, does it help to protect users or the data exposes to a
> certain DNS server?
>
> -     For TU- group 1: No, if it falls into category of data gathering
> process because an IP address does not bound to a particular user when using
> NAT or proxy server. But the content of this data exposes the users data
>
> The other reason is that, although that identity is for a particular node
> (when, for instance, it uses IPv6) but the content of flow (data) would
> expose information about user. This is of course not the flow that goes to
> DNS server but it is flows that user start it after this query from DNS
> server. Now the question is, could you hide data for any means of
> randomization?
>
> Actually no, because the problem is that the next flows that are the flow
> from end users to services are important and expose information about user,
> its behavior, etc.
>
>
>
> So, in general, I do not think your approach works here since there is no
> clear benefit on it. There is only more complexity or might be performance
> issue because we are going to use several intermediate nodes to answer a
> query asked by a user or a recursive server.
>
> In other words, DNS traffic does not carry anything interesting information
> for TU 1,2,3 and only the content of data exchanged after DNS query is
> important. Usually, when TU is located where it can sniff the DNS flows, it
> can also sniff next flows that are of his interest(like your example of
> ISPs). In this case, he skips all DNS flows. In other words, by only
> analyzing a sample TLD’s traffic or a sample resolver’s traffic, TU cannot
> gather any meaningful information because…
>
> 1-   not all those queries are because a user wants to connect to a website
> but it can be because this user wants to connect to his file server that has
> a domain name, thereby he needs to do much more efforts to find out what was
> the reason for this query to TLD or so. So this is what not of TU’s interest
> when he has other easier way to gather this information
>
> 2-  A website might have several different information and only user is
> interested in one of that so no precise information can TU gather about a
> user by he himself crawl a website.
>
> 4-  DNS domain names are only no meaningful names and he needs to crawl to
> find the data or he can easily skip all DNS traffics and only focus on data
> flows passed by different servers.
>
>
>
>> On 27 August 2014 10:52, Hosnieh Rafiee <[email-masked]>
>
>> wrote:
>
>> > Offlist
>
>> >
>
>> >
>
>> > Dear Merek,
>
>> >
>

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 28 Aug 2014 12:40:59 +0000

Hi Marek,

> 
> So, you're questioning the point of DNS

Yes, as far as the TU 2,3 has access to all interesting traffics. 

> them as a forensic evidence, correlating them to other traffic,
> geolocation and traffic distribution, whois records etc. with a certain
> degree of confidence.

Do you have any statistics or any references that prove TU 2,3 tried analyzing resolver traffics? 

In news, we just heard that some TUs sniffed the data. But do we know whether they used any resolvers to do this sniff? If you have any valid sources, then please share it. I am really interested to read them!

I would agree on if you have a strong source of such news. 

Because I think it is not enough just assuming that they would use such traffic. For having such assumption, you need a strong theory and strong references to prove it. It might not need much prove or strong references when it is a clear fact or seems to be reasonable. Because as I explained in my long message, it complicates his analysis and doesn't seem to be reasonable.  So, in case they have access to the whole traffic, they can easily sniff that traffic and whatever information you mentioned here, they can easily obtain from that traffic (without the need of DNS traffic at all). 
You are caring about geolocation information, well.. , the end user identity is the same, and this is, of course, available in next flows without any need to complicate this analysis.

If you use Tor based approach for a client (end user) but not any DNS server, it likely makes sense because a client or end user is the source of interesting traffic not a resolver or any other DNS servers. In this case you might also need to combine this approach with encryption or use exactly the approach implemented by Tor (tunneling + the use of intermediate servers). But this is not about DNS server traffic at all and this is about the privacy of next traffic flows.

This is why I think DNS privacy does not make sense.  

If all next traffics are encrypted (end to end encryption) and TU is only limited to DNS traffics, then DNS privacy  makes sense. But this is of course, a fancy scenario as today not all traffics are encrypted. If this fancy scenario happens even in near future, then I presume that all traffics would be encrypted including DNS traffic by the same way as the protection of other end user's traffic. For example, the use of tunneling. 

The problem is that you  might hide first resolver source of traffic behind several intermediate nodes, but you clearly did not hide the real end user traffic. 

> Saying DNS traffic does not carry anything interesting is a bold claim,
> it might be true, it might be not.
> Regardless of how it is, I think that giving less information is always
> better, if the cost isn't too high, and I'm happy to discuss technical
> questions / ideas.

The problem is that there is no strong proof behind the assumption that "DNS traffic is useful for TU and DNS carries some meaningful information for TU". If first, someone can prove it with real facts and references, then it would be to be on a same page.
But all what I can see in this list or all what I can read in drafts are the assumptions without any real facts. The assumption makes sense if one can also easily prove it either theoretical or in real life. But, it doesn't make sense when no one can prove it and unfortunately, here for prove, folks only use new assumptions...  Everyone only says as less information we provide to TU, it is better. But what kind of information you are talking about? How this information is useful for TU? Why TU needs them? Just some geolocation information of the location of different resolvers (based on your concern)? Let me give you an example. Resolver x in Munich receives many request for  google.com? so now ., .com,google.com knows that this resolver asked this request. What does it show you? What do you want to conclude from this data? 
Now presume that you hided resolver x behind resolver y and resolver y is located in Paris. Now resolver y asks for google.com. ., .com and google.com DNS servers now know that resolver y is looking for google.com. again what do you want to conclude from this data? You want to conclude that people in Paris search google a lot? What is it important about this and why it is difference to people from Munich search a lot on google and not paris.

What does it show you? The people in location x or y search google a lot? Ok... you could gather this information from google statistics as well... what else?

So why TU wanted to do so? TU have no information of what users in Munich searched (the data content) if they do not analyze next traffics. So, when they suppose to do so, again why should they bother themselves to look for this data?

is it what you want to hide? Tell me please what this information gives, it appears that there is no thought about whether or not this information is useful for TU and make sense for him to spend time and energy for such analysis and whether or not TU already has other and better sources for gathering the same information precisely. 

About your approach, it is not only problem of cost, it is performance and more importantly the question of its benefit.

Best,
Hosnieh

---

From: Marek Vavruša <[email-masked]>
Date: Thu, 28 Aug 2014 16:14:24 +0200

Hi Hosnieh,

> You are caring about geolocation information, well.. , the end user identity is the same, and this is, of course, available in next flows without any need to complicate this analysis.

No, I do not belong in TU 2/3 and I do not participate in any data
misuse project. However, the collected data is provably valuable for
some people (otherwise services like following wouldn't exist), if the
data is valuable, then
there's someone who desires it (be it a for a good or bad cause). This
is "I don't know my neighbours, let's not lock the front door",
regardless of whether you believe it or not.

http://www.enyo.de/fw/software/dnslogger/first2005-paper.pdf
https://www.iseclab.org/papers/bilge-ndss11.pdf
https://www.farsightsecurity.com/Services/DNSDB/

> The problem is that you  might hide first resolver source of traffic behind several intermediate nodes, but you clearly did not hide the real end user traffic.

OK, as I've said, this does not prevent MITM sniffing on you
(confidentiality problem), it makes you more anyonymous to name
servers (anonymity problem).

> So why TU wanted to do so? TU have no information of what users in Munich searched (the data content) if they do not analyze next traffics. So, when they suppose to do so, again why should they bot…

That's obviously uninteresting example. Say we have a newly registered
domains with abusive content, whois data a and map of resolver traffic
to those domains. The domain are quickly taken down,
but the more you observe, the more you know who/when/where is
interested in those domains and correlate it to other data. The name
servers are centralized source of information of such data and tell
you
where to look for the other, possibly incriminating traffic.

> About your approach, it is not only problem of cost, it is performance and more importantly the question of its benefit.

Let's see, we have a grid of 1-N caching resolvers. Each query is
likely to be answered from cache, but if it isn't, it has roughly 4
recursive sub-queries to authoritative nameservers. If those four
subquestions are bounced 0-2 times,
we have 0-2 roundtrips. Is that too much? Maybe, but it may be a
service as well.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 29 Aug 2014 09:41:03 +0000

> data is valuable, then there's someone who desires it (be it a for a
> good or bad cause). This is "I don't know my neighbours, let's not lock
> the front door", regardless of whether you believe it or not.

This is completely a different case and your example is unrelated. You're not locking the door. You  are only pointing something to somewhere else. 

> > The problem is that you  might hide first resolver source of traffic
> behind several intermediate nodes, but you clearly did not hide the
> real end user traffic.
> 
> (confidentiality problem), it makes you more anyonymous to name servers
> (anonymity problem).

The problem is that you think that DNS carries something important and all the assumption here is based on that. 

Again TU needs CONTENT to know whether or not the website that you concern about is abusive. This is not by only checking DNS server traffic! Do you get a lot of information from a DNS server?

DNS traffic analysis does not give much information to TU. He can also HAVE all those information by skipping all DNS traffic!

He needs to crawl that website! The other thing is that, some percentage of loading those abusive web is the result of typos error on the URL or end user mistake. So, such report is not precise

> to those domains. The domain are quickly taken down, but the more you
> observe, the more you know who/when/where is interested in those
> domains and correlate it to other data. The name servers are
> centralized source of information of such data and tell you where to
> look for the other, possibly incriminating traffic.

So again, by only changing the source of report TU can just have this information that people in X search abusive website a lot. Can you generalize this to all people in X country? Can you get any meaningful information from such report and conclude that people in x country are bad people because they like those kinds of website!

Definitely NO. this is not based on facts. This is like choosing wrong samples for reports. 
So you only change x to y but not the conclusion of the report. The problem is that conclusion report is not valid so it doesn't matter whether you change the variables of the report.

Best,
Hosnieh

---

From: Marek Vavruša <[email-masked]>
Date: Fri, 29 Aug 2014 13:41:57 +0200

> This is completely a different case and your example is unrelated. You're not locking the door. You  are only pointing something to somewhere else.

Aha, sure. Please tell me more how my example of subject analyzing
resolver traffic doesn't answer your question about, well, people
analyzing resolver traffic. I admit my analogy was imperfect though,
the point is to give as few data as possible about yourself.

> He needs to crawl that website! The other thing is that, some percentage of loading those abusive web is the result of typos error on the URL or end user mistake. So, such report is not precise

Ok, you obviously don't believe DNS traffic needs privacy on the sole
basis, that there's a bigger fish in the pond. I have seen X-Files and
I choose to believe, let's leave it at that and move to the technical
side of things.

> So you only change x to y but not the conclusion of the report. The problem is that conclusion report is not valid so it doesn't matter whether you change the variables of the report.

How did "all people in X country" get to my example? My IP address is
for example public. Can you get any meaningful information from the
name server about my lookups? Sure.
Can you correlate my lookups to other people? Yup. I reiterate the DNS
traffic _isn't_ interesting for incriminating evidence, but it can
tell you at which servers to look for such evidence.
Because how can you tell which website to crawl? You can for example
traverse all newly registered domains, domains with an empty whois,
but you can observe a group of nodes interested
in such websites. If they have a good track record of looking up the
address of the abusive website each Friday night, there's a good
chance that the thing they'll be looking up the next time
will be similar. Again, this sort of information doesn't make them
guilty, but a potential suspects and I do not claim such thing.

Kind Regards,
Marek

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 29 Aug 2014 12:00:36 +0000

> I choose to believe, let's leave it at that and move to the technical

I am telling from my first message! And I am telling that your approach is also not useful because of several reasons Provided you and you appears that you did not read them. Sorry, I am not planning to repeating myself here.

> name server about my lookups? Sure.

NO. 

> traffic _isn't_ interesting for incriminating evidence, but it can tell
> you at which servers to look for such evidence.
> traverse all newly registered domains, domains with an empty whois, but
> you can observe a group of nodes interested in such websites. If they
> have a good track record of looking up the address of the abusive
> website each Friday night, there's a good chance that the thing they'll
> be looking up the next time will be similar. Again, this sort of
> information doesn't make them guilty, but a potential suspects and I do
> not claim such thing.
> 

:-) sorry we are agree on disagree, so I would no longer answer to this message. I think I repeated myself a lot. I  keep telling you that NEXT traffic that is traffic from User X to server Y is what already the TU has (x can be a group of users or one user and y also can be a group of servers) and can analyze them all with no problem. So what you change here? Nothing. That traffic is running and TU sniffing it. So you just bother yourself to change your resolver IP address (hide them in what so ever way) but YOU did not hide the main source of traffic and you did not complicate the process of this TU. 

Please widen your scope and also look that what next traffics can be then probably you can understand my concern...

TU doesn't want to crawl a website! For your case if TU only wants to focus on DNS traffic he needs to crawl a website but not for my case where TU SKIP DNS traffic and only check the real user traffics. This traffic clearly in a real-time tells TU what a group of users are interested are. 

Best,
Hosnieh