Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread Owen DeLong



> On Mar 11, 2020, at 19:25 , Jan Schaumann  wrote:
> 
> Owen DeLong  wrote:
> 
>> DOH isn?t inherently bad, but every implementation
>> of DOH that I am aware of involves depriving the
>> user of choice and/or control
> 
> I don't think that's quite correct.
> 
> There is an unfortunate and persistent conflation of
> "DoH" with "DoH to a centralized third-party
> resolver"; that is largely Mozilla's fault, but even
> for Firefox the argument can be made that that is not
> _depriving_ the user of choice, but enabling their
> choice.  (Defaults being seen as no-choice seems a
> stretch, even if we know the majority of users will
> not (know how to) change the defaults.)

When you change the way a system works and make the new
behavior “opt-out”, especially when you present the option in
such a misleading way, I’ll stand by my statement.

> Google, for example, has noted that they have no plans
> to follow Mozilla's example, and instead will only use
> DoH if the local stub resolver in question is on
> their explicit shortlist of DoH resolvers.

Yeah, the part they leave out is that name servers like 2001:4860:4860:: 
and 2001:4860:4860::8844 are on that list.

> That is, the user (or the organization controlling the
> end-point) have already set the stub resolver to that
> service; if the user changes the stub resolver to
> point to some other IP, then Chrome will _not_
> override that and use DoH to e.g., Google's public
> resolver.

And you think that the average internet user has a sufficient level of 
understanding
to make an informed choice about this, let alone implement said choice?

>> and also depriving network operators of the ability
>> to enforce the ?my network, my rules? concept.
> 
> The network operator has _some_ control, but that
> control is limited by design, as the primary threat
> model for DoH and especially for _DoH to a third-party
> resolver_ is to defend against an untrusted network
> operator.

OK, but what about the network operator’s ability to defend against an 
untrusted user?

> That is indeed the argument of increased choice made
> by Mozilla: if a user explicitly enables DoH to a
> given server, they can enable it to be mandatory with
> no fallback and the network operator cannot change
> that.  (Unless the network operator is also in control
> of the user's device, of course.)

Right… Now put yourself in the position of a typical parent who works in a 
widget
factory and has all the skills necessary to find the power switch on a 
computer. Said
parent’s pre-teen child decides that DoH can lock dad out of snooping her 
web-surfing
and chat room choices and, so, enables it. Dad, in the meantime, has decided to
depend on the Disney service that came bundled with his Netgear router and is
assuming that has him covered there and won’t allow her to resolve adult sites 
and
risky chatrooms.

Do you not see a problem here?

Owen



Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread JASON BOTHE via NANOG
The enterprise as well. I’m certain many are blindly unaware as this could have 
negative impacts beyond traditional control. 

J~

> On Mar 11, 2020, at 20:43, Owen DeLong  wrote:
> 
> 
> 
>> On Mar 11, 2020, at 18:31 , Rubens Kuhl  wrote:
>> 
>> 
>> 
>>> On Tue, Mar 10, 2020 at 5:30 PM Owen DeLong  wrote:
>>> For anyone considering enabling DOH, I seriously recommend reviewing Paul 
>>> Vixie’s keynote at SCaLE 18x Saturday morning.
>>> 
>>> https://www.youtube.com/watch?v=artLJOwToVY
>>> 
>>> It contains a great deal of food for thought on a variety of forms of 
>>> giving control over to corporations over things you probably don’t really 
>>> want corporations controlling in your life.
>>> 
>> 
>> Depends on your threat model: ISPs, Big Tech companies, State-level actors, 
>> random hacker at the same Wi-Fi network. The problem with DoH is that 
>> software developer picks the threat model he or she thinks is most relevant, 
>> and applies to all use cases. 
>> 
>> Solution is to ask user what is the user threat model and apply it. DoH/DoT 
>> are not harmful per se, their indiscriminate usage is. 
>> 
>> 
>> Rubens
>> 
> 
> Yes and no…
> 
> DOH isn’t inherently bad, but every implementation of DOH that I am aware of 
> involves depriving the user of choice and/or control and also depriving 
> network operators of the ability to enforce the “my network, my rules” 
> concept.
> 
> While I realize some may argue that this is desirable in some instances, 
> understand that I’m not talking about the ISP level, but even within the 
> home. Parents should be able to enforce DNS policy on their children, for 
> example. DOH allows the average child to generally bypass any such 
> limitations. Worse, most parents are unlikely to even realize that this is 
> the case.
> 
> Owen
> 


Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread Jan Schaumann
Owen DeLong  wrote:

> DOH isn?t inherently bad, but every implementation
> of DOH that I am aware of involves depriving the
> user of choice and/or control

I don't think that's quite correct.

There is an unfortunate and persistent conflation of
"DoH" with "DoH to a centralized third-party
resolver"; that is largely Mozilla's fault, but even
for Firefox the argument can be made that that is not
_depriving_ the user of choice, but enabling their
choice.  (Defaults being seen as no-choice seems a
stretch, even if we know the majority of users will
not (know how to) change the defaults.)

Google, for example, has noted that they have no plans
to follow Mozilla's example, and instead will only use
DoH if the local stub resolver in question is on
their explicit shortlist of DoH resolvers.

That is, the user (or the organization controlling the
end-point) have already set the stub resolver to that
service; if the user changes the stub resolver to
point to some other IP, then Chrome will _not_
override that and use DoH to e.g., Google's public
resolver.

> and also depriving network operators of the ability
> to enforce the ?my network, my rules? concept.

The network operator has _some_ control, but that
control is limited by design, as the primary threat
model for DoH and especially for _DoH to a third-party
resolver_ is to defend against an untrusted network
operator.

That is indeed the argument of increased choice made
by Mozilla: if a user explicitly enables DoH to a
given server, they can enable it to be mandatory with
no fallback and the network operator cannot change
that.  (Unless the network operator is also in control
of the user's device, of course.)

-Jan


Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread Owen DeLong


> On Mar 11, 2020, at 18:31 , Rubens Kuhl  wrote:
> 
> 
> 
> On Tue, Mar 10, 2020 at 5:30 PM Owen DeLong  > wrote:
> For anyone considering enabling DOH, I seriously recommend reviewing Paul 
> Vixie’s keynote at SCaLE 18x Saturday morning.
> 
> https://www.youtube.com/watch?v=artLJOwToVY 
> 
> 
> It contains a great deal of food for thought on a variety of forms of giving 
> control over to corporations over things you probably don’t really want 
> corporations controlling in your life.
> 
> 
> Depends on your threat model: ISPs, Big Tech companies, State-level actors, 
> random hacker at the same Wi-Fi network. The problem with DoH is that 
> software developer picks the threat model he or she thinks is most relevant, 
> and applies to all use cases. 
> 
> Solution is to ask user what is the user threat model and apply it. DoH/DoT 
> are not harmful per se, their indiscriminate usage is. 
> 
> 
> Rubens
> 

Yes and no…

DOH isn’t inherently bad, but every implementation of DOH that I am aware of 
involves depriving the user of choice and/or control and also depriving network 
operators of the ability to enforce the “my network, my rules” concept.

While I realize some may argue that this is desirable in some instances, 
understand that I’m not talking about the ISP level, but even within the home. 
Parents should be able to enforce DNS policy on their children, for example. 
DOH allows the average child to generally bypass any such limitations. Worse, 
most parents are unlikely to even realize that this is the case.

Owen



Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread Rubens Kuhl
On Tue, Mar 10, 2020 at 5:30 PM Owen DeLong  wrote:

> For anyone considering enabling DOH, I seriously recommend reviewing Paul
> Vixie’s keynote at SCaLE 18x Saturday morning.
>
> https://www.youtube.com/watch?v=artLJOwToVY
>
> It contains a great deal of food for thought on a variety of forms of
> giving control over to corporations over things you probably don’t really
> want corporations controlling in your life.
>
>
Depends on your threat model: ISPs, Big Tech companies, State-level actors,
random hacker at the same Wi-Fi network. The problem with DoH is that
software developer picks the threat model he or she thinks is most
relevant, and applies to all use cases.

Solution is to ask user what is the user threat model and apply it. DoH/DoT
are not harmful per se, their indiscriminate usage is.


Rubens


Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-11 Thread Scott Weeks
--- o...@delong.com wrote:
From: Owen DeLong 

For anyone considering enabling DOH, I seriously recommend 
reviewing Paul Vixie’s keynote at SCaLE 18x Saturday morning.

https://www.youtube.com/watch?v=artLJOwToVY

It contains a great deal of food for thought on a variety 
of forms of giving control over to corporations over things 
you probably don’t really want corporations controlling in 
your life.

---



Definitely informative.  I had no idea.  As well Paul Vixie
always sees things from a uniqus PoV.  Thanks for sharing!

I add a +1 that folks should watch this.

scott

Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2020-03-10 Thread Owen DeLong
For anyone considering enabling DOH, I seriously recommend reviewing Paul 
Vixie’s keynote at SCaLE 18x Saturday morning.

https://www.youtube.com/watch?v=artLJOwToVY

It contains a great deal of food for thought on a variety of forms of giving 
control over to corporations over things you probably don’t really want 
corporations controlling in your life.

Owen


> On Sep 27, 2019, at 10:33 , Curtis Maurand  wrote:
> 
> powerdns dnsdist supports dns over https so you don't have to be held hostage 
> by cloudflare or google.
> 
> 
> 
> On 9/18/19 10:19 AM, Mike Hammett wrote:
>> Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as 
>> default behavior?
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions 
>>   
>>  
>>  
>> 
>> Midwest Internet Exchange 
>>   
>>  
>> 
>> The Brothers WISP 
>>   
>> 
>> From: "Jeroen Massar"  
>> To: "NANOG"  
>> Sent: Wednesday, September 18, 2019 2:15:49 AM
>> Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) 
>> for the enhanced privacy of your users
>> 
>> Hi Folks,
>> 
>> While in the US soon all Firefox users will *NOT* use your DNS Recursives 
>> configured using DHCP anymore
>> (NXDOMAIN use-application-dns.net  to avoid 
>> that[1]).
>> Next to that, it seems some of the root operators are now creating instances 
>> in the same networks that offer these kind of services for globally figuring 
>> out what queries are being made.
>> 
>> 
>> For those that thus either opt-out or otherwise want to use their own system 
>> resolvers, I suggest that all that run
>> DNS Recursive setups enable "QNAME minimization" as defined in 
>> (experimental) RFC7816 [2]
>> 
>> For pdns "qname-minimization=yes" [6]
>> For unbound "qname­-minimisation: yes" [5]
>> For BIND "qname-minimization" option [3] and [4]
>> 
>> Of course, do also provider your users with the option of using DoT or even 
>> DoH on your recursors...
>> 
>> Noting that DoH operators are supposed to enable RFC7816 also [7], guess 
>> they do not want others to see all the details they get...
>> 
>> Some more details in DNS Privacy Wiki [8]...
>> 
>> Discuss! :)
>> 
>> Greets,
>>  Jeroen
>> 
>> 
>> [1] 
>> https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
>>  
>> 
>> [2] https://tools.ietf.org/html/rfc7816 
>> [3] https://www.isc.org/blogs/qname-minimization-and-privacy/ 
>> 
>> [4] https://gitlab.isc.org/isc-projects/bind9/issues/16 
>> 
>> [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf 
>> 
>> [6] https://github.com/PowerDNS/pdns/issues/2311 
>> 
>> [7] https://wiki.mozilla.org/Security/DOH-resolver-policy 
>> 
>> [8] https://dnsprivacy.org/wiki/ 
>> 
> 
> 



Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-27 Thread Curtis Maurand
powerdns dnsdist supports dns over https so you don't have to be held 
hostage by cloudflare or google.




On 9/18/19 10:19 AM, Mike Hammett wrote:
Why on Earth would anyone want that (Firefox deciding to do it's own 
DNS) as default behavior?




-
Mike Hammett
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 


*From: *"Jeroen Massar" 
*To: *"NANOG" 
*Sent: *Wednesday, September 18, 2019 2:15:49 AM
*Subject: *DNS Recursive Operators: Please enable QNAME minimization 
(RFC7816) for the enhanced privacy of your users


Hi Folks,

While in the US soon all Firefox users will *NOT* use your DNS 
Recursives configured using DHCP anymore

(NXDOMAIN use-application-dns.net to avoid that[1]).
Next to that, it seems some of the root operators are now creating 
instances in the same networks that offer these kind of services for 
globally figuring out what queries are being made.



For those that thus either opt-out or otherwise want to use their own 
system resolvers, I suggest that all that run
DNS Recursive setups enable "QNAME minimization" as defined in 
(experimental) RFC7816 [2]


For pdns "qname-minimization=yes" [6]
For unbound "qname­-minimisation: yes" [5]
For BIND "qname-minimization" option [3] and [4]

Of course, do also provider your users with the option of using DoT or 
even DoH on your recursors...


Noting that DoH operators are supposed to enable RFC7816 also [7], 
guess they do not want others to see all the details they get...


Some more details in DNS Privacy Wiki [8]...

Discuss! :)

Greets,
 Jeroen


[1] 
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https

[2] https://tools.ietf.org/html/rfc7816
[3] https://www.isc.org/blogs/qname-minimization-and-privacy/
[4] https://gitlab.isc.org/isc-projects/bind9/issues/16
[5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf
[6] https://github.com/PowerDNS/pdns/issues/2311
[7] https://wiki.mozilla.org/Security/DOH-resolver-policy
[8] https://dnsprivacy.org/wiki/





Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread John Levine
In article <8580e3e4-98b8-2828-e43f-6115c92fa...@massar.ch> you write:
>Currently though:
>
>use-application-dns.net. 172800IN  NS  
>ns-cloud-b1.googledomains.com.
>use-application-dns.net. 172800IN  NS  
>ns-cloud-b2.googledomains.com.
>use-application-dns.net. 172800IN  NS  
>ns-cloud-b3.googledomains.com.
>use-application-dns.net. 172800IN  NS  
>ns-cloud-b4.googledomains.com.

Nope.

;; ANSWER SECTION:

;; AUTHORITY SECTION:
use-application-dns.net.172800  IN  NS  ns4-64.akam.net.
use-application-dns.net.172800  IN  NS  ns7-66.akam.net.
use-application-dns.net.172800  IN  NS  ns5-65.akam.net.
use-application-dns.net.172800  IN  NS  ns1-240.akam.net.

$ drill @ns5-65.akam.net. use-application-dns.net a
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 48353
;; flags: qr aa rd ; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; use-application-dns.net. IN  A

;; ANSWER SECTION:
use-application-dns.net.60  IN  A   185.199.108.153
use-application-dns.net.60  IN  A   185.199.109.153
use-application-dns.net.60  IN  A   185.199.111.153
use-application-dns.net.60  IN  A   185.199.110.153

I have this special-cased in my own resolver, of course.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


RE: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread Keith Medcalf


For efficiency of censorship.  If you want to stop some domain name from 
resolving you have to get everyone on the planet to block that DNS resolution 
in their recursive resolver.  However, if everyone uses the same single DNS 
server operated by a single entity, then you only have to coerce that one 
entity to block resolution of that DNS name.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: NANOG  On Behalf Of Mike Hammett
>Sent: Wednesday, 18 September, 2019 08:19
>To: Jeroen Massar 
>Cc: NANOG 
>Subject: Re: DNS Recursive Operators: Please enable QNAME minimization
>(RFC7816) for the enhanced privacy of your users
>
>Why on Earth would anyone want that (Firefox deciding to do it's own DNS)
>as default behavior?
>
>
>
>
>-
>Mike Hammett
>Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
><https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
><https://www.linkedin.com/company/intelligent-computing-solutions>
><https://twitter.com/ICSIL>
>Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
><https://www.linkedin.com/company/midwest-internet-exchange>
><https://twitter.com/mdwestix>
>The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
><https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>
>
>
>From: "Jeroen Massar" 
>To: "NANOG" 
>Sent: Wednesday, September 18, 2019 2:15:49 AM
>Subject: DNS Recursive Operators: Please enable QNAME minimization
>(RFC7816) for the enhanced privacy of your users
>
>Hi Folks,
>
>While in the US soon all Firefox users will *NOT* use your DNS Recursives
>configured using DHCP anymore
>(NXDOMAIN use-application-dns.net to avoid that[1]).
>Next to that, it seems some of the root operators are now creating
>instances in the same networks that offer these kind of services for
>globally figuring out what queries are being made.
>
>
>For those that thus either opt-out or otherwise want to use their own
>system resolvers, I suggest that all that run
>DNS Recursive setups enable "QNAME minimization" as defined in
>(experimental) RFC7816 [2]
>
>For pdns "qname-minimization=yes" [6]
>For unbound "qname­-minimisation: yes" [5]
>For BIND "qname-minimization" option [3] and [4]
>
>Of course, do also provider your users with the option of using DoT or
>even DoH on your recursors...
>
>Noting that DoH operators are supposed to enable RFC7816 also [7], guess
>they do not want others to see all the details they get...
>
>Some more details in DNS Privacy Wiki [8]...
>
>Discuss! :)
>
>Greets,
> Jeroen
>
>
>[1] https://support.mozilla.org/en-US/kb/configuring-networks-disable-
>dns-over-https
>[2] https://tools.ietf.org/html/rfc7816
>[3] https://www.isc.org/blogs/qname-minimization-and-privacy/
>[4] https://gitlab.isc.org/isc-projects/bind9/issues/16
>[5]
>https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf
>[6] https://github.com/PowerDNS/pdns/issues/2311
>[7] https://wiki.mozilla.org/Security/DOH-resolver-policy
>[8] https://dnsprivacy.org/wiki/
>






Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread Matt Corallo
Because getting each ISP in the world to comply with NSA monitoring requests 
was too hard, instead they get to centralize the full list of every website the 
everyone in the world visits on a single fleet of servers in Cloudflare's 
datacenters. This means we only need to compromise one person to monitor the 
world, saving the US taxpayer significantly. Progress!

Matt

> On Sep 18, 2019, at 16:19, Mike Hammett  wrote:
> 
> Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as 
> default behavior?
> 
> 
> 
> -
> Mike Hammett
> Intelligent Computing Solutions
> 
> Midwest Internet Exchange
> 
> The Brothers WISP
> 
> From: "Jeroen Massar" 
> To: "NANOG" 
> Sent: Wednesday, September 18, 2019 2:15:49 AM
> Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) 
> for the enhanced privacy of your users
> 
> Hi Folks,
> 
> While in the US soon all Firefox users will *NOT* use your DNS Recursives 
> configured using DHCP anymore
> (NXDOMAIN use-application-dns.net to avoid that[1]).
> Next to that, it seems some of the root operators are now creating instances 
> in the same networks that offer these kind of services for globally figuring 
> out what queries are being made.
> 
> 
> For those that thus either opt-out or otherwise want to use their own system 
> resolvers, I suggest that all that run
> DNS Recursive setups enable "QNAME minimization" as defined in (experimental) 
> RFC7816 [2]
> 
> For pdns "qname-minimization=yes" [6]
> For unbound "qname­-minimisation: yes" [5]
> For BIND "qname-minimization" option [3] and [4]
> 
> Of course, do also provider your users with the option of using DoT or even 
> DoH on your recursors...
> 
> Noting that DoH operators are supposed to enable RFC7816 also [7], guess they 
> do not want others to see all the details they get...
> 
> Some more details in DNS Privacy Wiki [8]...
> 
> Discuss! :)
> 
> Greets,
>  Jeroen
> 
> 
> [1] 
> https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
> [2] https://tools.ietf.org/html/rfc7816
> [3] https://www.isc.org/blogs/qname-minimization-and-privacy/
> [4] https://gitlab.isc.org/isc-projects/bind9/issues/16
> [5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf
> [6] https://github.com/PowerDNS/pdns/issues/2311
> [7] https://wiki.mozilla.org/Security/DOH-resolver-policy
> [8] https://dnsprivacy.org/wiki/
> 


Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread Mike Hammett
Why on Earth would anyone want that (Firefox deciding to do it's own DNS) as 
default behavior? 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Jeroen Massar"  
To: "NANOG"  
Sent: Wednesday, September 18, 2019 2:15:49 AM 
Subject: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) 
for the enhanced privacy of your users 

Hi Folks, 

While in the US soon all Firefox users will *NOT* use your DNS Recursives 
configured using DHCP anymore 
(NXDOMAIN use-application-dns.net to avoid that[1]). 
Next to that, it seems some of the root operators are now creating instances in 
the same networks that offer these kind of services for globally figuring out 
what queries are being made. 


For those that thus either opt-out or otherwise want to use their own system 
resolvers, I suggest that all that run 
DNS Recursive setups enable "QNAME minimization" as defined in (experimental) 
RFC7816 [2] 

For pdns "qname-minimization=yes" [6] 
For unbound "qname­-minimisation: yes" [5] 
For BIND "qname-minimization" option [3] and [4] 

Of course, do also provider your users with the option of using DoT or even DoH 
on your recursors... 

Noting that DoH operators are supposed to enable RFC7816 also [7], guess they 
do not want others to see all the details they get... 

Some more details in DNS Privacy Wiki [8]... 

Discuss! :) 

Greets, 
Jeroen 


[1] 
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
 
[2] https://tools.ietf.org/html/rfc7816 
[3] https://www.isc.org/blogs/qname-minimization-and-privacy/ 
[4] https://gitlab.isc.org/isc-projects/bind9/issues/16 
[5] https://netlabs.nl/downloads/presentations/unbound_qnamemin_oarc24.pdf 
[6] https://github.com/PowerDNS/pdns/issues/2311 
[7] https://wiki.mozilla.org/Security/DOH-resolver-policy 
[8] https://dnsprivacy.org/wiki/ 



Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread Jeroen Massar
On 2019-09-18 12:24, Brian J. Murrell wrote:
> On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote:
>> Hi Folks,
> 
> Hi.
> 
>> While in the US soon all Firefox users will *NOT* use your DNS
>> Recursives configured using DHCP anymore
>> (NXDOMAIN use-application-dns.net to avoid that[1]).
> 
> What am I misunderstanding?  Isn't use-application-dns.net supposed to
> return A results until "defeated"?  I have not configured my own DNS
> server to NXDOMAIN that yet, however:

That just means that somebody broke that setup as it worked last week and was 
pointing to Github Pages serving:

https://github.com/agrover/global-canary/

Maybe Google does not want Mozilla/CloudFlare to get all the DoH queries? :)
Nah likely just a failure somewhere, as both are supported heavily by Google 
(if there was no competition then Google would truly have a monopoly in the 
browser market and that would be bad, at least with them funding Mozilla and CF 
through the backdoor it looks like it isn't a monopoly as there "is that other 
thing")



There is a little thread about that domain here on dns-operations:
https://lists.dns-oarc.net/pipermail/dns-operations/2019-September/019179.html

Currently though:

use-application-dns.net. 172800 IN  NS  ns-cloud-b1.googledomains.com.
use-application-dns.net. 172800 IN  NS  ns-cloud-b2.googledomains.com.
use-application-dns.net. 172800 IN  NS  ns-cloud-b3.googledomains.com.
use-application-dns.net. 172800 IN  NS  ns-cloud-b4.googledomains.com.


$ dig @ns-cloud-b1.googledomains.com. use-application-dns.net. a
[..]
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21669
...


that is from my test host, but of course, from my other hosts it nicely 
NXDOMAINs but those hosts also route 1.1.1.1/8.8.8.8/8.8.4.4 and the IPv6 
equivalents and many other such IPs (OpenDNS, etc and even root servers) to the 
local anycasted edition cause I don't want that in my networks.

Then again, as that makes me not a sheep, I am likely more visible anyway...[1]

Greets,
 Jeroen

[1] 
https://jeroen.massar.ch/presentations/vid/27C3-JeroenMassar-HowTheInternetSeesYou/


Re: DNS Recursive Operators: Please enable QNAME minimization (RFC7816) for the enhanced privacy of your users

2019-09-18 Thread Brian J. Murrell
On Wed, 2019-09-18 at 09:15 +0200, Jeroen Massar wrote:
> Hi Folks,

Hi.

> While in the US soon all Firefox users will *NOT* use your DNS
> Recursives configured using DHCP anymore
> (NXDOMAIN use-application-dns.net to avoid that[1]).

What am I misunderstanding?  Isn't use-application-dns.net supposed to
return A results until "defeated"?  I have not configured my own DNS
server to NXDOMAIN that yet, however:

$ dig use-application-dns.net a

; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> use-application-dns.net a
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33589
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;use-application-dns.net.   IN  A

;; Query time: 1181 msec
;; SERVER: fd31:aeb1:48df::2#53(fd31:aeb1:48df::2)
;; WHEN: Wed Sep 18 06:22:19 EDT 2019
;; MSG SIZE  rcvd: 52

And even Google's global DNS:

$ dig @8.8.8.8 use-application-dns.net a

; <<>> DiG 9.11.10-RedHat-9.11.10-1.fc30 <<>> @8.8.8.8 use-application-
dns.net a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33725
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;use-application-dns.net.   IN  A

;; Query time: 1454 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Sep 18 06:22:42 EDT 2019
;; MSG SIZE  rcvd: 52

Cheers,
b.



signature.asc
Description: This is a digitally signed message part