Re: This DNS over HTTP thing

[David Conrad]

Jay,

On Oct 1, 2019, at 12:18 PM, Jay R. Ashworth  wrote:
> This is thought to be about security?
> 
> Didn't we already *fix* DNS SECurity?

No.  DNSSEC solves a different problem (being able to verify what you get is 
what the domain owner published).

DoH (and DoT) encrypt (and authenticate) the application <-> recursive resolver 
channel (NOT the DNS data) which I gather some view as an attack vector. 
Mozilla has decided to _also_ redefine the default resolver (unless 
use-application-dns.net  NXDOMAINs), instead 
of the resolver (typically) assigned by the ISP, for browser queries.  That 
last bit is generating a bit of ‘discussion’ as it can bypass efforts by 
network operators to modify DNS responses for whatever reason (e.g., protect 
customers from phishing sites, censoring domain names due in response to court 
orders, monetizing typos, etc.).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Optical training

[Brandon Martin]

On 10/01/2019 17:05, Mel Beckman wrote:
If you’re looking for DWDM design and provisioning, you’ll probably have 
to pay for vendor-specific courses.


Are there really even any significant (i.e. usefully deployed) 
vendor-neutral mechanisms for DWDM provisioning?  All the systems I know 
of are either vendor-specific or essentially manual.


I know there was an effort to generalize the MPLS control plane to this 
sort of thing (GMPLS), but I'm of the impression that it didn't really 
take off.


--
Brandon Martin

Re: AWS issues with 172.0.0.0/12

[Jim Popovitch via NANOG]

On October 1, 2019 9:39:03 PM UTC, Matt Palmer  wrote:
>On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG
>wrote:
>> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
>> > possible that this is various AWS customers making
>iptables/firewall mistakes?
>> >"block that pesky rfc1918 172/12 space!!"
>> 
>> AWS also uses some 172/12 space on their internal network (e.g. the
>network
>> that sits between EC2 instances and the AWS external firewalls)
>
>Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're
>different
>things, after all.
>

I don't know their entire operations, but they do use some 172.16.0.0/12
addresses internally. And yes, that is very different than 172/12, sorry
for the confusion.

-Jim P.

Re: AWS issues with 172.0.0.0/12

[Matt Palmer]

On Tue, Oct 01, 2019 at 04:50:33AM -0400, Jim Popovitch via NANOG wrote:
> On 10/1/2019 4:09 AM, Christopher Morrow wrote:
> > possible that this is various AWS customers making iptables/firewall 
> > mistakes?
> >"block that pesky rfc1918 172/12 space!!"
> 
> AWS also uses some 172/12 space on their internal network (e.g. the network
> that sits between EC2 instances and the AWS external firewalls)

Does AWS use 172.0.0.0/12 internally, or 172.16.0.0/12?  They're different
things, after all.

- Matt

Re: This DNS over HTTP thing

[Frank Habicht]

Hi,

On 01/10/2019 23:24, Warren Kumari wrote:
> On Tue, Oct 1, 2019 at 3:42 PM K. Scott Helms  wrote:
>>
>> They almost have to change the default since there are (comparatively) very 
>> few DoH providers compared to DNS providers.
> 
> From the link that Damian sent (emphasis mine):
> "More concretely, the experiment in Chrome 78 will **check if the
> user’s current DNS provider** is among a list of DoH-compatible
> providers, and upgrade to the equivalent DoH service **from the same
> provider**. If the DNS provider isn’t in the list, Chrome will
> **continue to operate as it does today.**"

can we not also understand this as testing the waters in terms of
changes of browser behaviour without user knowledge?

and once one's browser uses DoH, how will we be sure that not half of
queries (DoH) are going to another server - maybe even google's?

slippery slope?

PS: in my opinion it would look a lot more not-evil-doing if the same
would be done with s/DoH/DoT/


Frank

Re: This DNS over HTTP thing

[bzs]

Everyone's (who's anyone) is looking for free curation of the net!

Maybe one more law or regulation will do it. Look at how well it
stomped out spam!

Put more grimly:

For over 100 years Europe, and others, have imagined the path to
paradise is paved with new and improved censorship.

Results have been sub-optimal.

Perhaps one really needs to go after the perps rather than their
digital images.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: This DNS over HTTP thing

[Valdis Klētnieks]

On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:

> "More concretely, the experiment in Chrome 78 will **check if the
> user’s current DNS provider** is among a list of DoH-compatible
> providers, and upgrade to the equivalent DoH service **from the same
> provider**. If the DNS provider isn’t in the list, Chrome will
> **continue to operate as it does today.**"

I suppose this is the point somebody has to put the words "nostrils", "tent",
and "camel" in the same sentence?

I'd not say it, except..  All the articles on how to disable this in Chrome say
stuff like:

If users don't want to be included in the Chrome DoH experiment, they can use a
DNS provider that's not on Google's list (which most of the Chrome userbase
already does), or they can disable DoH support by modifying the 
chrome://flags/#dns-over-https flag.

However, the Linux build of "Version 79.0.3921.0 (Official Build) unknown 
(64-bit)"
does not have that flag in chrome://flags (or at least Chrome can't find ot with
control-F dns-over   and the in-page search box returns 1 result for 'dns'

Anonymize local IPs exposed by WebRTC.
Conceal local IP addresses with mDNS hostnames.
 Mac, Windows, Linux, Chrome OS

#enable-webrtc-hide-local-ips-with-mdns

There are still 3 occurrences of the string 'dns-over-http' in the binary, but 
none of them
seem to be wired up to the chrome://flags page.

It may be a bug - I was unable to find mention of it, but I may not have had
the right keywords to scare up a search hit.  If it *is* a bug, I'd appreciate 
if
somebody pointed me at the support page for it



pgpuHPKskD9e6.pgp
Description: PGP signature

Re: This DNS over HTTP thing

[Damian Menscher via NANOG]

On Tue, Oct 1, 2019 at 2:06 PM Jeroen Massar  wrote:

> On 2019-10-01 23:03, Damian Menscher wrote:
> > On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar  jer...@massar.ch>> wrote:
> >
> > On 2019-10-01 21:38, Damian Menscher wrote:
> >
> > > Could someone provide a reference of Google saying they'll change
> the default nameserver?  Without that, I think all of Jeroen's arguments
> fall apart?
> >
> > While I stated:
> >
> > >> Moving only your DNS to Cloudflare or Google does not solve the
> security stance,
> > >> even though that is what people are marketing this whole DoH move
> for
> >
> > I did not state what you write above ("Changing the default
> nameserver").
> > (Noting also, that the 'default nameserver' is the system one, not
> the one being just being used by the browser...)
> >
> >
> > Heh, nice troll -- I wasted a few minutes writing a long response about
> how you did, in fact, say that multiple times in this thread.
> >
> > Should be obvious to non-trolls that I was referring to Google changing
> the default nameserver *in Chrome*, as obviously Google doesn't have root
> access to change it on the host.
>
> Fortunately list archives exist.
>
> Thanks for playing.. and name calling.
>

I apologize for calling you a troll, if that was not your intent.  (It's
seriously hard to tell sometimes.)

Apologies that these problems that your company are causing are hurting you
> personally so much that you need to resort to that.
>

I'm also sorry that the facts do not match your preconceived world-view.

Damian

Re: This DNS over HTTP thing

[Jeroen Massar]

On 2019-10-01 23:03, Damian Menscher wrote:
> On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar  > wrote:
> 
> On 2019-10-01 21:38, Damian Menscher wrote:
> 
> > Could someone provide a reference of Google saying they'll change the 
> default nameserver?  Without that, I think all of Jeroen's arguments fall 
> apart?
> 
> While I stated:
> 
> >> Moving only your DNS to Cloudflare or Google does not solve the 
> security stance,
> >> even though that is what people are marketing this whole DoH move 
> for
> 
> I did not state what you write above ("Changing the default nameserver").
> (Noting also, that the 'default nameserver' is the system one, not the 
> one being just being used by the browser...)
> 
> 
> Heh, nice troll -- I wasted a few minutes writing a long response about how 
> you did, in fact, say that multiple times in this thread.
> 
> Should be obvious to non-trolls that I was referring to Google changing the 
> default nameserver *in Chrome*, as obviously Google doesn't have root access 
> to change it on the host.

Fortunately list archives exist.

Thanks for playing.. and name calling.

Apologies that these problems that your company are causing are hurting you 
personally so much that you need to resort to that.

Greets,
 Jeroen

Re: Optical training

[Mel Beckman]

FiberU (https://fiberu.org) has a lot of decent free training materials. Their 
emphasis is on physical installation, but they do cover DWDM, Bi-Di, and 
related physics in some of their videos. If you’re looking for DWDM design and 
provisioning, you’ll probably have to pay for vendor-specific courses.

Here’s the FiberU syllabus that covers optical fiber testing along with DWDM 
and OTDR.

https://fiberu.org/OSP/LP8.html

 -mel

On Oct 1, 2019, at 1:24 PM, James Chang  wrote:

Sorry... forgot to mention that I'm looking for recommendation of training 
courses in this particular area.

Thanks,
James

On Tue, Oct 1, 2019 at 4:21 PM James Chang 
mailto:traceroute...@gmail.com>> wrote:
Hi All,

Hopefully this is the right place to post this question.I'm a routing guy 
mainly working with ISIS/BGP for my company in our core space.  I have an 
opportunity to get involve with our L2 DWDM network.  We are a Cisco shop using 
NCS2K as DWDM nodes.  But before jump into learning the NCS specific stuff, I 
would like to take a vendor neutral training course in Optical fiber testing 
with OSA/OTDR, OTN, DWDM signaling, OSNR/dispersionetc.  I think this will 
help me understand how to build out a DWDM network from ground up.  I'm hoping 
someone I could get into designing network for my company.

Thanks in advance,
James

Re: This DNS over HTTP thing

[Damian Menscher via NANOG]

On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar  wrote:

> On 2019-10-01 21:38, Damian Menscher wrote:
>
> > Could someone provide a reference of Google saying they'll change the
> default nameserver?  Without that, I think all of Jeroen's arguments fall
> apart?
>
> While I stated:
>
> >> Moving only your DNS to Cloudflare or Google does not solve the
> security stance,
> >> even though that is what people are marketing this whole DoH move
> for
>
> I did not state what you write above ("Changing the default nameserver").
> (Noting also, that the 'default nameserver' is the system one, not the one
> being just being used by the browser...)
>

Heh, nice troll -- I wasted a few minutes writing a long response about how
you did, in fact, say that multiple times in this thread.

Should be obvious to non-trolls that I was referring to Google changing the
default nameserver *in Chrome*, as obviously Google doesn't have root
access to change it on the host.

But, likely in the long run that will happen won't it? As Firefox is
> already being used as a test base if it works...
>

My crystal ball stopped working when I dropped it last week.  Need to get
it repaired before I can answer.

Damian

Noting also, that none of my arguments fall apart with that. But hey, just
> skip over the whole thread, or even the TLDR... kthx!
>
> Greets,
>  Jeroen
>

Re: Optical training

[James Chang]

Sorry... forgot to mention that I'm looking for recommendation of training
courses in this particular area.

Thanks,
James

On Tue, Oct 1, 2019 at 4:21 PM James Chang  wrote:

> Hi All,
>
> Hopefully this is the right place to post this question.I'm a routing
> guy mainly working with ISIS/BGP for my company in our core space.  I
> have an opportunity to get involve with our L2 DWDM network.  We are a
> Cisco shop using NCS2K as DWDM nodes.  But before jump into learning the
> NCS specific stuff, I would like to take a vendor neutral training course
> in Optical fiber testing with OSA/OTDR, OTN, DWDM signaling,
> OSNR/dispersionetc.  I think this will help me understand how to build
> out a DWDM network from ground up.  I'm hoping someone I could get into
> designing network for my company.
>
> Thanks in advance,
> James
>

Re: This DNS over HTTP thing

[Warren Kumari]

On Tue, Oct 1, 2019 at 3:42 PM K. Scott Helms  wrote:
>
> They almost have to change the default since there are (comparatively) very 
> few DoH providers compared to DNS providers.

>From the link that Damian sent (emphasis mine):
"More concretely, the experiment in Chrome 78 will **check if the
user’s current DNS provider** is among a list of DoH-compatible
providers, and upgrade to the equivalent DoH service **from the same
provider**. If the DNS provider isn’t in the list, Chrome will
**continue to operate as it does today.**"

W


>
> On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG  
> wrote:
>>
>> On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth  wrote:
>>>
>>> - Original Message -
>>> > From: "Stephane Bortzmeyer" 
>>> > To: "Jeroen Massar" 
>>>
>>> >> While the 'connection to the recursor' is 'encrypted', the recursor
>>> >> is still in clear text... one just moves who can see what you are
>>> >> doing with this.
>>> >
>>> > As with any cryptographic protocol. Same thing with VPNs, SSH and
>>> > whatever: the remote end can see what you do. What's your point?
>>>
>>> I'm still assimilating this, but based on what I've read this half hour,
>>> his point is that "*it's none of Alphabet's damn business* where I go that
>>> isn't Google".
>>
>>
>> What's missing from this discussion are some basic facts, like "is Google 
>> going to change your DNS settings to 8.8.8.8?"
>>
>> The opening paragraph of 
>> https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html 
>> reads:
>>
>> "This experiment will be done in collaboration with DNS providers who 
>> already support DoH, with the goal of improving our mutual users’ security 
>> and privacy by upgrading them to the DoH version of their current DNS 
>> service. With our approach, the DNS service used will not change, only the 
>> protocol will. As a result, existing content controls of your current DNS 
>> provider, including any existing protections for children, will remain 
>> active."
>>
>> Could someone provide a reference of Google saying they'll change the 
>> default nameserver?  Without that, I think all of Jeroen's arguments fall 
>> apart?
>>
>> Damian



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

Optical training

[James Chang]

Hi All,

Hopefully this is the right place to post this question.I'm a routing
guy mainly working with ISIS/BGP for my company in our core space.  I
have an opportunity to get involve with our L2 DWDM network.  We are a
Cisco shop using NCS2K as DWDM nodes.  But before jump into learning the
NCS specific stuff, I would like to take a vendor neutral training course
in Optical fiber testing with OSA/OTDR, OTN, DWDM signaling,
OSNR/dispersionetc.  I think this will help me understand how to build
out a DWDM network from ground up.  I'm hoping someone I could get into
designing network for my company.

Thanks in advance,
James

Re: This DNS over HTTP thing

[Jeroen Massar]

On 2019-10-01 21:38, Damian Menscher wrote:

> Could someone provide a reference of Google saying they'll change the default 
> nameserver?  Without that, I think all of Jeroen's arguments fall apart?

While I stated:

>> Moving only your DNS to Cloudflare or Google does not solve the security 
>> stance,
>> even though that is what people are marketing this whole DoH move for

I did not state what you write above ("Changing the default nameserver").
(Noting also, that the 'default nameserver' is the system one, not the one 
being just being used by the browser...)


But, likely in the long run that will happen won't it? As Firefox is already 
being used as a test base if it works...


Noting also, that none of my arguments fall apart with that. But hey, just skip 
over the whole thread, or even the TLDR... kthx!

Greets,
 Jeroen

Re: This DNS over HTTP thing

[Jay R. Ashworth]

- Original Message -
> From: "Matt Corallo" 

> I’m not sure that google has announced any plans to, but Firefox has announced
> plans to switch everyone to Cloudflare’s DNS.
> 
> Hope none of  y’all are running competing CDNs, cause they’re about to get 
> real
> slow on Firefox.

But wait!  I was told we didn't *need* regs or laws to enforce Net Neutrality...

Cheers,
-- jr 'paging Mr Oliver, Mr John Oliver' a
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: This DNS over HTTP thing

[John R. Levine]

I assumed my point was obvious but evidently I overestimated my audience.

While it is stupid to assert that the only reason to circumvent DNS 
filters is to look at child abuse material, it is equally stupid to assert 
that the only reason to filter is to lie, or to censor.


There are plenty of good reasons to filter DNS responses, with the most 
obvious being to block malware sites whose links are sent out in spam (a 
whole lot of spam these days.)  There are also reasons that enterprises 
filter DNS on their networks, to block stuff that creates a hostile work 
environment, or is obviously unrelated to what employees are hired to do 
(i.e., facebook.)


R's,
John


On Tue, 1 Oct 2019, Aaron C. de Bruyn wrote:


"For the children!"
"Stop resisting!"
"I was in fear for my life!"

The age-old cries of the oppressor. ...



On Tue, Oct 1, 2019 at 11:33 AM John Levine  wrote:


In article <20191001074011.n4xjouqg6lhsv...@nic.fr> you write:

Note that the UK is probably the country in Europe with the biggest
use of lying DNS resolvers for censorship. No wonder that the people
who censor don't like anti-censorship techniques.


Most UK ISPs use the Internet Watch Foundation's advice intended to
block child sexual abuse material.

Circumventing it enables people to access that material.

We can shout CHILD PORNOGRAPHY just as loud as you can shout
CENSORSHIP so perhaps we should both stop now.  There are plenty of
valid reasons for a DNS resolver to block some results.


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: This DNS over HTTP thing

[K. Scott Helms]

They almost have to change the default since there are (comparatively) very
few DoH providers compared to DNS providers.

On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG 
wrote:

> On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth  wrote:
>
>> - Original Message -
>> > From: "Stephane Bortzmeyer" 
>> > To: "Jeroen Massar" 
>>
>> >> While the 'connection to the recursor' is 'encrypted', the recursor
>> >> is still in clear text... one just moves who can see what you are
>> >> doing with this.
>> >
>> > As with any cryptographic protocol. Same thing with VPNs, SSH and
>> > whatever: the remote end can see what you do. What's your point?
>>
>> I'm still assimilating this, but based on what I've read this half hour,
>> his point is that "*it's none of Alphabet's damn business* where I go that
>> isn't Google".
>>
>
> What's missing from this discussion are some basic facts, like "is Google
> going to change your DNS settings to 8.8.8.8?"
>
> The opening paragraph of
> https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html
>  reads:
>
> "This experiment will be done in collaboration with DNS providers who
> already support DoH, with the goal of improving our mutual users’ security
> and privacy by upgrading them to the DoH version of their current DNS
> service. With our approach, the DNS service used will not change, only the
> protocol will. As a result, existing content controls of your current DNS
> provider, including any existing protections for children, will remain
> active."
>
> Could someone provide a reference of Google saying they'll change the
> default nameserver?  Without that, I think all of Jeroen's arguments fall
> apart?
>
> Damian
>

Re: This DNS over HTTP thing

[Damian Menscher via NANOG]

On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth  wrote:

> - Original Message -
> > From: "Stephane Bortzmeyer" 
> > To: "Jeroen Massar" 
>
> >> While the 'connection to the recursor' is 'encrypted', the recursor
> >> is still in clear text... one just moves who can see what you are
> >> doing with this.
> >
> > As with any cryptographic protocol. Same thing with VPNs, SSH and
> > whatever: the remote end can see what you do. What's your point?
>
> I'm still assimilating this, but based on what I've read this half hour,
> his point is that "*it's none of Alphabet's damn business* where I go that
> isn't Google".
>

What's missing from this discussion are some basic facts, like "is Google
going to change your DNS settings to 8.8.8.8?"

The opening paragraph of
https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html
 reads:

"This experiment will be done in collaboration with DNS providers who
already support DoH, with the goal of improving our mutual users’ security
and privacy by upgrading them to the DoH version of their current DNS
service. With our approach, the DNS service used will not change, only the
protocol will. As a result, existing content controls of your current DNS
provider, including any existing protections for children, will remain
active."

Could someone provide a reference of Google saying they'll change the
default nameserver?  Without that, I think all of Jeroen's arguments fall
apart?

Damian

Re: This DNS over HTTP thing

[Michael Thomas]

On 10/1/19 12:18 PM, Jay R. Ashworth wrote:

- Original Message -

From: "Stephane Bortzmeyer" 
On Mon, Sep 30, 2019 at 11:56:33PM -0400,
Brandon Martin  wrote
a message of 10 lines which said:


It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
will go back to using your local DNS server list as per usual.

Unless, I hope, the user explicitely overrides this. (Because this
canary domain contradicts DoH's goals, by allowing the very party you
don't trust to remotely disable security.)

Security?

This is thought to be about security?

Didn't we already *fix* DNS SECurity?



DNSSEC only deals with authentication, not confidentiality...



No, I tend to buy the "Alphabet looking over your shoulder" argument
a lot more than 'security', here, so far.


...of course the main people you'd like to keep this confidential from 
are the ones on the other end of the DNS pipe, be it ISP's or Google, et 
al. So i'm not exactly sure what problem this solves, beyond giving 
Google and the rest a shot at seeing all of that yummy data.


Mike

Re: This DNS over HTTP thing

[Jay R. Ashworth]

- Original Message -
> From: "Stephane Bortzmeyer" 
> To: "Jeroen Massar" 

>> While the 'connection to the recursor' is 'encrypted', the recursor
>> is still in clear text... one just moves who can see what you are
>> doing with this.
> 
> As with any cryptographic protocol. Same thing with VPNs, SSH and
> whatever: the remote end can see what you do. What's your point?

I'm still assimilating this, but based on what I've read this half hour,
his point is that "*it's none of Alphabet's damn business* where I go that
isn't Google".

I concur.

I see no reasonable justification for this from a network engineering
standpoint, and I'll be stomping on it wherever necessary.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Clueful netops/sysops persons at Canon

[Eric Dugas]

Hello,

One of our customers is having issues with his Canon printers that needs to
connect to https://ugwportal.net for whatever reason. The issue is only
visible from one of our netblock to a few IPs in 202.248.100.0/24. I don't
believe this is a routing issue.

The netblock is routed by Fujitsu's AS2510 and the servers may be even
managed by Fujitsu so I've tried to reach fip-idcst...@ml.jp.fujitsu.com
and fip-idcst...@dl.jp.fujitsu.com who are listed as the admin and tech
contact for 202.248.100.0/24 but the tech contact email bounced. The second
address didn't seem to bounce back but I am not convinced we're reaching
the right company/group so I'm trying to find a clueful contact
specifically from Canon in North America or even Europe to take a look help
us find the right group to address the situation.

Thanks in advance

Re: This DNS over HTTP thing

[Jay R. Ashworth]

- Original Message -
> From: "Stephane Bortzmeyer" 

> On Mon, Sep 30, 2019 at 11:56:33PM -0400,
> Brandon Martin  wrote
> a message of 10 lines which said:
> 
>> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
>> will go back to using your local DNS server list as per usual.
> 
> Unless, I hope, the user explicitely overrides this. (Because this
> canary domain contradicts DoH's goals, by allowing the very party you
> don't trust to remotely disable security.)

Security?

This is thought to be about security?

Didn't we already *fix* DNS SECurity?

No, I tend to buy the "Alphabet looking over your shoulder" argument
a lot more than 'security', here, so far.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: This DNS over HTTP thing

[Jay R. Ashworth]

- Original Message -
> From: "Matt Corallo" 

> It was mentioned in this (partially related) thread, with all the responses
> being the predictable “lol these folks in Silicon Valley need to lay off the
> drugs”.
> 
> https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html

Well, the parent message there seems to think it's inevitable that Firefox
is going to do that, whereas my view is 

1) Firefox will do as I damn well tell it, or
2) Firefox will be removed.

They continue to expand past the size of what we coloquially call "their
britches", and it's gotten about as tiresome as I -- for the seats under
my responsibility -- propose to let it get.

If there isn't a knob I can turn off, they're gone; no appeal.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   http://www.bcp38.info  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: This DNS over HTTP thing

[Aaron C. de Bruyn via NANOG]

"For the children!"
"Stop resisting!"
"I was in fear for my life!"

The age-old cries of the oppressor.

The problem is that children are being kidnapped, trafficked, and abused.
DNS blocking doesn't solve that.  It's not a technical problem.
Go to the source--the kidnappers, traffickers, and abusers and give them 50
years in the electric chair.
Go to the consumers and do the same.  That will solve the problem.

-A





On Tue, Oct 1, 2019 at 11:33 AM John Levine  wrote:

> In article <20191001074011.n4xjouqg6lhsv...@nic.fr> you write:
> >Note that the UK is probably the country in Europe with the biggest
> >use of lying DNS resolvers for censorship. No wonder that the people
> >who censor don't like anti-censorship techniques.
>
> Most UK ISPs use the Internet Watch Foundation's advice intended to
> block child sexual abuse material.
>
> Circumventing it enables people to access that material.
>
> We can shout CHILD PORNOGRAPHY just as loud as you can shout
> CENSORSHIP so perhaps we should both stop now.  There are plenty of
> valid reasons for a DNS resolver to block some results.
>
> R's,
> John
>
>
>
>

Re: This DNS over HTTP thing

[John Levine]

In article <20191001074011.n4xjouqg6lhsv...@nic.fr> you write:
>Note that the UK is probably the country in Europe with the biggest
>use of lying DNS resolvers for censorship. No wonder that the people
>who censor don't like anti-censorship techniques.

Most UK ISPs use the Internet Watch Foundation's advice intended to
block child sexual abuse material.

Circumventing it enables people to access that material.

We can shout CHILD PORNOGRAPHY just as loud as you can shout
CENSORSHIP so perhaps we should both stop now.  There are plenty of
valid reasons for a DNS resolver to block some results.

R's,
John

Re: AWS issues with 172.0.0.0/12

[Jim Popovitch via NANOG]

On 10/1/2019 4:09 AM, Christopher Morrow wrote:

possible that this is various AWS customers making iptables/firewall mistakes?
   "block that pesky rfc1918 172/12 space!!"


AWS also uses some 172/12 space on their internal network (e.g. the 
network that sits between EC2 instances and the AWS external firewalls)


-Jim P.

Re: This DNS over HTTP thing

[Grimes, Greg]

DNS over HTTPS. And yesDNS over TLS would be better in my opinion.

--
Greg Grimes
Senior Network Analyst
Information Technology Services
Mississippi State University
662-325-9311(w)


From: NANOG  on behalf of Jay R. Ashworth 

Sent: Monday, September 30, 2019 9:25:07 PM
To: North American Network Operators' Group 
Subject: This DNS over HTTP thing

I've been embroiled in my first house-move in 28 years, and just got back
to the table.  I don't see any threads here about whatever this thing-which-
appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it?

Is there an official name for it I should be searching for?

Is it in fact not a monstrosity, and I'm just not smart enough?  :-)

Cheers,
-- jra

--
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth & Associates   
http://secure-web.cisco.com/1vEcpsLgAGJkFDMQebtpSHArLROwG5eAPeyR0_tVM-DvbzRe3YaDD-pZx_Liq3vnrIHvxIG6YxsPAACuL4XF9vKdvt5CZ-3krDpKirbkwHtFjbKUMp0-wsC9Yxsb4V3IB3PXes7bwJj47e7kEhdI_4T3rm1HxwsR2wPf-cjxNKUFlWerQsLHB0mqwTeCfzotYzqhbf-JI0OpNxnUehlHPP9WW8gfdsPGm6c5Z6nIqRurHZneSJOc_MGxGQPseeDOZYL2_6TMMQqwa9o5rR5amQ4MgrgV-icXD30Cv7LQ5l7RPEI1d3hS8s6IrtM_N7bcSGH5Qe9LBRHiI1XyHURAB9g/http%3A%2F%2Fwww.bcp38.info
  2000 Land Rover DII
St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274

Re: This DNS over HTTP thing

[Tom Hill]

On 01/10/2019 08:40, Stephane Bortzmeyer wrote:
> Note that the UK is probably the country in Europe with the biggest
> use of lying DNS resolvers for censorship. No wonder that the people
> who censor don't like anti-censorship techniques.


Do you have a (reputable) source to go with that claim? :)

-- 
Tom

Re: This DNS over HTTP thing

[Matt Harris]

On Tue, Oct 1, 2019 at 8:22 AM Stephane Bortzmeyer 
wrote:

> On Tue, Oct 01, 2019 at 12:11:32PM +0200,
>  Jeroen Massar  wrote
>  a message of 101 lines which said:
>
> >  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
> >  or even plain old Do53
>
> Yes, but people using a public DNS resolver (of a big US corporation)
> over UDP is quite an old thing and nobody complained. I really wonder
> why there was so little reaction against OpenDNS or Google Public DNS
> and suddently a lot of outcry against DoH...
>

Mainly because no one was ever forcibly-defaulted to those, while browser
makers are now going to be defaulting to sending queries to a specific set
of DoH servers not set by dhcp/etc locally, but rather chosen by the
browser maker, in a way that most users won't even realize/notice, hence
allowing the browser maker to determine who gets to see the queries the
user is making while surfing the web in that browser. This is a major
change from how browsers and other applications have historically behaved,
where DNS servers were set either locally on the host, or via dhcp or
somesuch at the LAN level. This change will almost certainly be made
without the user explicitly consenting to it.

Effectively, there is no outcry against DoH. There is outcry against how
some browser makers are implementing some configuration changes. It
wouldn't matter what protocol they were using, even if they simply skipped
local/LAN resolver configs and went straight to udp/tcp 53 on their chosen
servers for recursive queries.

Browser makers rule the world in a number of ways already, like choosing
which TLS root certificates to include, and setting default search engines
and settings (sometimes on update, even overriding explicit user settings,
as was the case when Firefox switched to a paid arrangement with Yahoo.)
There's a lot of potential for abuse here, and so oversight in the form of
"outcry" seems entirely justified when such changes occur.

Re: This DNS over HTTP thing

[Ca By]

On Tue, Oct 1, 2019 at 6:23 AM Stephane Bortzmeyer 
wrote:

> On Tue, Oct 01, 2019 at 12:11:32PM +0200,
>  Jeroen Massar  wrote
>  a message of 101 lines which said:
>
> >  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
> >  or even plain old Do53
>
> Yes, but people using a public DNS resolver (of a big US corporation)
> over UDP is quite an old thing and nobody complained. I really wonder
> why there was so little reaction against OpenDNS or Google Public DNS
> and suddently a lot of outcry against DoH...
>

There is only a reaction to changing the defaults of millions of users to
key internet infrastructure.

As Mao Zedong said, let a thousand flowers bloom. It only got messy when it
turned out everyone effectively could only have 1.



> > You might also want to look into this amazing thing called Tor if
> > you really want privacy.
>
> I know it, and use it and it is awfully slow. Telling to people who
> want privacy that they need to adopt the difficult and costly (in
> performance) solutions made for iranian opponents won't help to
> improve security.
>
> > Noting that many ISPs are deploying both DoT and DoH next to Do53.
>
> Fact-checking: could you name some? (I do not know even one.)
>

Re: This DNS over HTTP thing

[Jeroen Massar]

On 2019-10-01 15:22, Stephane Bortzmeyer wrote:
> On Tue, Oct 01, 2019 at 12:11:32PM +0200,
>  Jeroen Massar  wrote 
>  a message of 101 lines which said:
> 
>>  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
>>  or even plain old Do53
> 
> Yes, but people using a public DNS resolver (of a big US corporation)
> over UDP is quite an old thing and nobody complained. I really wonder
> why there was so little reaction against OpenDNS or Google Public DNS
> and suddently a lot of outcry against DoH...

Those services the user decides on themselves.

It is not a default in the browser.

>> You might also want to look into this amazing thing called Tor if
>> you really want privacy.
> 
> I know it, and use it and it is awfully slow. Telling to people who
> want privacy that they need to adopt the difficult and costly (in
> performance) solutions made for iranian opponents won't help to
> improve security.

Then Tor is not for your purpose indeed.

Use a VPN, or better switch ISP so that you do not keep paying an entity that 
you do not trust.

>> Noting that many ISPs are deploying both DoT and DoH next to Do53.
> 
> Fact-checking: could you name some? (I do not know even one.)

https://www.as15600.net/

And there are many others who have announced it.

Greets,
 Jeroen

Re: This DNS over HTTP thing

[Ca By]

On Mon, Sep 30, 2019 at 7:27 PM Jay R. Ashworth  wrote:

> I've been embroiled in my first house-move in 28 years, and just got back
> to the table.  I don't see any threads here about whatever this
> thing-which-
> appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed
> it?
>
> Is there an official name for it I should be searching for?
>
> Is it in fact not a monstrosity, and I'm just not smart enough?  :-)
>

Oof. It is a bit of a mess.

1. For most PEOPLE in North America, DNS hacking, clear text dns is not a
legit threat in their threat model.  So, in short, encrypted dns is not
solving a major hacker vector. It is not materially making the web more
secure since on-path attacks from hackers are hard. Spare me the coffee
shop wifi case.  It’s definitely not an issue on mobile.

2.  For GOOGLE (And it’s minions Cloudflare, which GOOG owns a chunk of,
and Firefox [which is dominantly funded by GOOG] — data is key in their
billion dollars ad game.

3. The billion dollar ad game has heated up. FB and Amazon are becoming a
real threat to Google’s dollars.  Apple too, is a threat with their focus
on apps.
https://www.google.com/amp/s/fortune.com/2019/06/25/amazon-ad-business/amp/

4. GOOG tracks you all around the web with their ad platform.  But GOOG
cannot see what you do when you are on FB, Amazon, Apple..: because these
companies are enemies fighting over the same ad bucks.  Your computer will
leak to GOOG what / when you do thing on FB and Amazon

5. To make the world better, Google needs to see ALL your traffic, not just
their ad network cookie traffic.  Hence they launched these efforts

1. Chrome with a FREE proxy for all your traffic
https://developer.chrome.com/multidevice/data-compression

2. Android with a FREE vpn

https://support.google.com/nexus/answer/6327199?hl=en

3. Google Fiber

4. 8.8.8.8

5.  AMP for websites

6. Gmail

https://www.google.com/amp/s/www.theverge.com/platform/amp/2019/5/17/18629789/google-purchase-history-gmail-email-receipts

But these things were not really getting into enough high end Apple hands,
there was a dark spot in their view of all the Apple traffic.  Also, some
telcos had ham-fisted  attempts to be ad business (vz bought yahoo, aol,
and tumbr...), but Google wanted to further ice them out. Who needs another
competitor for all your data, right ?

https://www.google.com/amp/s/www.washingtonpost.com/technology/2019/09/06/google-receives-demand-documents-doj-acknowledging-federal-antitrust-scrutiny/%3foutputType=amp

So:

6. Using it’s “paid friends” Cloudflare and Mozilla, as it usually does,
Google pushes them over the cliff to be the canaries and test public
reaction to centralize more of your data and normalize the google data
grab... and hiding that data from competitors. Google pushes firefox and
cloudflare in to the public ... just like they did with centralize dns
(1.1.1.1) and funny vpns that are not VPNs
https://twitter.com/notdan/status/1178339685795598336?s=21 , they now want
to make chrome and firefox DoH by default. Why?  Because 1 they want all
your data 2 they can, they control the browser and dont need to coordinate
with anyone else to do it (unlike DoT)

Ps. Yes, i know i sent AMP links from my gmail account, this is my real
world internet experience.



> Cheers,
> -- jra
>
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: This DNS over HTTP thing

[Jared Mauch]

> On Oct 1, 2019, at 9:22 AM, Stephane Bortzmeyer  wrote:
> 
> On Tue, Oct 01, 2019 at 12:11:32PM +0200,
> Jeroen Massar  wrote 
> a message of 101 lines which said:
> 
>> - Using a centralized/forced-upon DNS service (be that over DoT/DoH
>> or even plain old Do53
> 
> Yes, but people using a public DNS resolver (of a big US corporation)
> over UDP is quite an old thing and nobody complained. I really wonder
> why there was so little reaction against OpenDNS or Google Public DNS
> and suddently a lot of outcry against DoH…

I get people not wanting to use 8.8.8.8 1.1.1.1 4.2.2.1 or even their local DNS 
resolver because various people have tried to treat it as a revenue stream at 
times.  There needs to be more middle ground here than people have drawn with 
their battle lines.

>> Noting that many ISPs are deploying both DoT and DoH next to Do53.
> 
> Fact-checking: could you name some? (I do not know even one.)

I’ve gone and enabled DoTLS on my server and (wow, the number is finally 
non-zero!) haven’t seen a lot of TLS adoption.  I see a lot more IPv6 than TLS 
at my authority server.

num.edns=433691276
num.ednserr=96
num.udp=299934993
num.udp6=154946379
num.tcp=820001
num.tcp6=292693
num.tls=15
num.tls6=0
num.answer_wo_aa=1117887
num.rxerr=0
num.txerr=6
num.raxfr=49
num.truncated=1420526
num.dropped=86596

- Jared

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Tue, Oct 01, 2019 at 12:11:32PM +0200,
 Jeroen Massar  wrote 
 a message of 101 lines which said:

>  - Using a centralized/forced-upon DNS service (be that over DoT/DoH
>  or even plain old Do53

Yes, but people using a public DNS resolver (of a big US corporation)
over UDP is quite an old thing and nobody complained. I really wonder
why there was so little reaction against OpenDNS or Google Public DNS
and suddently a lot of outcry against DoH...

> You might also want to look into this amazing thing called Tor if
> you really want privacy.

I know it, and use it and it is awfully slow. Telling to people who
want privacy that they need to adopt the difficult and costly (in
performance) solutions made for iranian opponents won't help to
improve security.

> Noting that many ISPs are deploying both DoT and DoH next to Do53.

Fact-checking: could you name some? (I do not know even one.)

Re: This DNS over HTTP thing

[Jared Mauch]

> On Oct 1, 2019, at 6:11 AM, Jeroen Massar  wrote:
> 
> TDLR:
> - Using DoT or DoH as a protocol is fine, though the recursor still 
> controls/views the DNS queries
> - Using a centralized/forced-upon DNS service (be that over DoT/DoH or even 
> plain old Do53 is does not improve security or privacy...
>   Getting that forced fed by the monopolies controlling the browser bad 
> for the Internet.
> - Use a VPN if you do not trust your network provider.
> - Use Tor if you really want 'privacy’.

I would also be concerned about the lock-in this creates.  Cloudflare (at 
previous DNS-OARC meetings) has said their main reason for paying Mozilla & 
1.1.1.1 is to improve the performance for their customers.  I think this is a 
great thing for their customers, but is also an issue - if you take it to the 
privacy extreme here it harm not only their competitors but the end-users 
involved as well.

I’m personally very concerned about the very extreme stance taken by some 
people & organizations with the overall protocols and how they will harm the 
internet of the future.

I for one am awaiting the DoHoToQUICo53 overlords to appear.

- jared

Re: This DNS over HTTP thing

[Jeroen Massar]

TDLR:
 - Using DoT or DoH as a protocol is fine, though the recursor still 
controls/views the DNS queries
 - Using a centralized/forced-upon DNS service (be that over DoT/DoH or even 
plain old Do53 is does not improve security or privacy...
   Getting that forced fed by the monopolies controlling the browser bad 
for the Internet.
 - Use a VPN if you do not trust your network provider.
 - Use Tor if you really want 'privacy'.


On 2019-10-01 11:57, Stephane Bortzmeyer wrote:
> On Tue, Oct 01, 2019 at 10:35:31AM +0200,
>  Jeroen Massar  wrote 
>  a message of 29 lines which said:
> 
>> Correct: for the DoH protocol it is not that goal, there it solely
>> is "encryption". But DoT already solves that.
> 
> DoT is fine, (and my own public resolver activates it) but, as you
> know, it is too easy to block, either explicitely, or as a by-product
> of a "only port 443" policy.

Sounds like you don't trust the network you get access from (and possibly pay).

Use a VPN to get out of there. Though then you also move your trust point of 
course, but at least you do it for everything.

Just doing this for your webbrowser is not solving your problem (till encrypted 
SNI is a thing *everywhere*), there are other services on the Internet than 
this "HTTP" thing...

You might also want to look into this amazing thing called Tor if you really 
want privacy.

> Also, most of the complaints (for instance by the lobby who wrote to
> the US congress) about DoH apply also to DoT (for instance, like DoH,
> it prevents the ISP to modify or even to see the DNS requests and
> responses, so the lobbies who don't like DoH won't like DoT either).

You just moved your problem to the entity that now runs your DNS recursor.

Before "encryption" the network and the recursor could view/change your 
requests.
Likely these where both your ISP.

Encrypting to the recursor will still allow that recursor to see and modify 
answers.

Btw enabling DNSSEC only allows you to verify that there was a lie (or no 
answer).


Most users currently use their network provided DNS server. As such, they are 
likely using the one from the ISP...


The question is: who do you trust, in this question: the one that offers the 
recursive service.

If you do not trust your local network, VPN/Tor out of there.

If you trust your local network (as you pay them, just trust them, or live in a 
country with strong privacy enforcement and data collection policies), then 
just use them.


Browsers forcing upon a user per default a DNS provider does not address any of 
these things.


>> For the implementation though of DoH (what most people have a
>> problem with), the sole goal is centralization
> 
> This is your personal opinion, not a fact. (Speaking as someone who
> deployed a DoH resolver.)

You are mixing things.


A) Anybody can deploy DoT or DoH for their recursors (I have too).

B) Browser vendors are doing this "DoH" thing to centralize DNS to their 
recursors.


Noting that many ISPs are deploying both DoT and DoH next to Do53.

And Mozilla claims that suddenly that is a good thing as 'it is encrypted', 
while it does not change the adversary: recursor still run by an ISP, that 
apparently one does not trust...


>> and moving the information collection from the ISP to single
>> entities that are already collection so much data,
> 
> That's why we need more DoH resolvers. Install one!

Installed a whole bunch of them

But not using them myself. DoT is the technically better version.


>> The point is that the claimed goal (for the deployment) is that it
>> gives users 'privacy', but in the end that 'privacy' just moves from
>> the ISP that the user pays to an unrelated company that wants to see
>> it all...
> 
> Security is often moving stuff to a different trusted party (think of
> VPNs, for instance).

See above.


Moving only your DNS to Cloudflare or Google does not solve the security 
stance, even though that is what people are marketing this whole DoH move 
for


Greets,
 Jeroen

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Tue, Oct 01, 2019 at 10:35:31AM +0200,
 Jeroen Massar  wrote 
 a message of 29 lines which said:

> Correct: for the DoH protocol it is not that goal, there it solely
> is "encryption". But DoT already solves that.

DoT is fine, (and my own public resolver activates it) but, as you
know, it is too easy to block, either explicitely, or as a by-product
of a "only port 443" policy.

Also, most of the complaints (for instance by the lobby who wrote to
the US congress) about DoH apply also to DoT (for instance, like DoH,
it prevents the ISP to modify or even to see the DNS requests and
responses, so the lobbies who don't like DoH won't like DoT either).

> For the implementation though of DoH (what most people have a
> problem with), the sole goal is centralization

This is your personal opinion, not a fact. (Speaking as someone who
deployed a DoH resolver.)

> and moving the information collection from the ISP to single
> entities that are already collection so much data,

That's why we need more DoH resolvers. Install one!

> The point is that the claimed goal (for the deployment) is that it
> gives users 'privacy', but in the end that 'privacy' just moves from
> the ISP that the user pays to an unrelated company that wants to see
> it all...

Security is often moving stuff to a different trusted party (think of
VPNs, for instance).

Re: This DNS over HTTP thing

[Grzegorz Janoszka]

On 01/10/2019 09:22, Brandon Butterworth wrote:

Here are some UKNOF presentations on it -

Also very interesting from NLNOG (but in English):

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

--
Grzegorz Janoszka

Re: This DNS over HTTP thing

[Jeroen Massar]

On 2019-10-01 10:08, Stephane Bortzmeyer wrote:
> On Tue, Oct 01, 2019 at 09:55:54AM +0200,
>  Jeroen Massar  wrote 
>  a message of 26 lines which said:
> 
>>> (Because this canary domain contradicts DoH's goals, by allowing
>>> the very party you don't trust to remotely disable security.)
>>
>> The goal is centralization of DNS
> 
> Hmmm, no, read RFC 8484 (section 1).

Correct: for the DoH protocol it is not that goal, there it solely is 
"encryption". But DoT already solves that.

For the implementation though of DoH (what most people have a problem with), 
the sole goal is centralization and moving the information collection from the 
ISP to single entities that are already collection so much data, this just 
gives them more and for properties they do not even operate.

>> While the 'connection to the recursor' is 'encrypted', the recursor
>> is still in clear text... one just moves who can see what you are
>> doing with this.
> 
> As with any cryptographic protocol. Same thing with VPNs, SSH and
> whatever: the remote end can see what you do. What's your point?

The point is that the claimed goal (for the deployment) is that it gives users 
'privacy', but in the end that 'privacy' just moves from the ISP that the user 
pays to an unrelated company that wants to see it all...

False advertising anyone?

Greets,
 Jeroen

Re: AWS issues with 172.0.0.0/12

[Stephane Bortzmeyer]

On Tue, Oct 01, 2019 at 09:09:38AM +0100,
 Christopher Morrow  wrote 
 a message of 27 lines which said:

> possible that this is various AWS customers making iptables/firewall mistakes?
>   "block that pesky rfc1918 172/12 space!!"

May be, but I used the same target as Mehmet.

Re: AWS issues with 172.0.0.0/12

[Christopher Morrow]

possible that this is various AWS customers making iptables/firewall mistakes?
  "block that pesky rfc1918 172/12 space!!"

On Tue, Oct 1, 2019 at 8:51 AM Stephane Bortzmeyer  wrote:
>
> On Mon, Sep 30, 2019 at 11:38:25PM -0700,
>  Mehmet Akcin  wrote
>  a message of 131 lines which said:
>
> > Here you go
>
> The two RIPE Atlas probes in the AT prefix seem able to reach AWS:
>
> %  blaeu-traceroute --protocol TCP --size=0 --port=80 --first_hop=64 --format 
> --prefix 172.0.0.0/12 --requested 10 52.21.66.90
> Measurement #22932983 Traceroute 52.21.66.90 from prefix 172.0.0.0/12 uses 2 
> probes
> 2 probes reported
> Test #22932983 done at 2019-10-01T07:46:00Z
> From:  172.10.12.57018ATT-INTERNET4 - AT Services, Inc., US
> Source address:  172.10.12.5
> Probe ID:  11203
> 6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[11.43, 
> 11.158, 10.806]
>
> From:  172.8.16.487018ATT-INTERNET4 - AT Services, Inc., US
> Source address:  192.168.1.73
> Probe ID:  51354
> 6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[22.301, 
> 21.612, 21.615]
>

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Tue, Oct 01, 2019 at 09:55:54AM +0200,
 Jeroen Massar  wrote 
 a message of 26 lines which said:

> > (Because this canary domain contradicts DoH's goals, by allowing
> > the very party you don't trust to remotely disable security.)
> 
> The goal is centralization of DNS

Hmmm, no, read RFC 8484 (section 1).

> While the 'connection to the recursor' is 'encrypted', the recursor
> is still in clear text... one just moves who can see what you are
> doing with this.

As with any cryptographic protocol. Same thing with VPNs, SSH and
whatever: the remote end can see what you do. What's your point?

Re: This DNS over HTTP thing

[Robert Kisteleki]

> The bare about:config pref you want is "network.trr.mode".  Short and
> sweet of it, set to 5 (off by choice), and it should disable the
> function entirely.  3 would be the opposite: always use it.

Thank you, IMO this is by far the most useful piece of information on
the subject!

Robert

RE: This DNS over HTTP thing

[Keith Medcalf]

On Tuesday, 1 October, 2019 01:39, Stephane Bortzmeyer
 wrote:

>On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin
 wrote

>> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
>> will go back to using your local DNS server list as per usual.

> Unless, I hope, the user explicitely overrides this. (Because this
> canary domain contradicts DoH's goals, by allowing the very party you
> don't trust to remotely disable security.)

According to Mozilla:
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-ov
er-https

Network administrators may configure their networks to treat DNS
requests for a canary domain differently, to signal that their local DNS
resolver implements special features that make the network unsuitable
for DoH.

In addition to the canary domain signal described above, Firefox will
perform some checks for network features that are incompatible with DoH
before enabling it for a user. These checks will be performed at browser
startup, and each time the browser detects that it has moved to a
different network, such as when a laptop is used at home, work, and a
coffee shop. When any of these checks indicates a potential issue,
Firefox will disable DoH for the remainder of the network session,
unless the user has enabled the "DoH always" preference as mentioned
above.

The additional checks that will be performed for content filtering are:

Resolve canary domains of certain known DNS providers to detect
content filtering
Resolve the "safe-search" variants of google.com and youtube.com to
determine if the network redirects to them
On Windows and macOS, detect parental controls enabled in the
operating system

The additional checks that will be performed for private "enterprise"
networks are:

Is the Firefox security.enterprise_roots.enabled preference set to
true?
Is any enterprise policy configured?

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

Re: This DNS over HTTP thing

[Jeroen Massar]

On 2019-10-01 09:38, Stephane Bortzmeyer wrote:
> On Mon, Sep 30, 2019 at 11:56:33PM -0400,
>  Brandon Martin  wrote 
>  a message of 10 lines which said:
> 
>> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
>> will go back to using your local DNS server list as per usual.
> 
> Unless, I hope, the user explicitely overrides this. (Because this
> canary domain contradicts DoH's goals, by allowing the very party you
> don't trust to remotely disable security.)

The goal is centralization of DNS and being to see more what users (or at least 
the aggregate stats, so that they can claim "we do not keep your 
data/IP/lookups") do, the goal is not that of 'security' or 'privacy'.


While the 'connection to the recursor' is 'encrypted', the recursor is still in 
clear text... one just moves who can see what you are doing with this.


Also keep a split between the protocol and the implementation. DoT and DoH both 
serve the same goal of "encryption", but that is not being used here: they also 
want to move the recursor to another entity...



At least the use-application-dns.net zone is now not DNSSEC signed anymore as 
it was before, thus at least a NXDOMAIN can now be caused instead of SERVFAIL 
as .net indicated a signature, while one overrode that locally...

Greets,
 Jeroen

Re: AWS issues with 172.0.0.0/12

[Stephane Bortzmeyer]

On Mon, Sep 30, 2019 at 11:38:25PM -0700,
 Mehmet Akcin  wrote 
 a message of 131 lines which said:

> Here you go

The two RIPE Atlas probes in the AT prefix seem able to reach AWS:

%  blaeu-traceroute --protocol TCP --size=0 --port=80 --first_hop=64 --format 
--prefix 172.0.0.0/12 --requested 10 52.21.66.90
Measurement #22932983 Traceroute 52.21.66.90 from prefix 172.0.0.0/12 uses 2 
probes
2 probes reported
Test #22932983 done at 2019-10-01T07:46:00Z
From:  172.10.12.57018ATT-INTERNET4 - AT Services, Inc., US
Source address:  172.10.12.5
Probe ID:  11203
6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[11.43, 
11.158, 10.806]

From:  172.8.16.487018ATT-INTERNET4 - AT Services, Inc., US
Source address:  192.168.1.73
Probe ID:  51354
6452.21.66.9014618AMAZON-AES - Amazon.com, Inc., US[22.301, 
21.612, 21.615]

Re: This DNS over HTTP thing

[Brandon Martin]

On 10/1/19 3:38 AM, Stephane Bortzmeyer wrote:

It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
will go back to using your local DNS server list as per usual.

Unless, I hope, the user explicitely overrides this. (Because this
canary domain contradicts DoH's goals, by allowing the very party you
don't trust to remotely disable security.)


Indeed.  It seemed like a glaring hole in the implementation.  The 
Mozilla page on the topic implies it's temporary until some sort of 
"standard" solution can be found, but since you will always have folks 
who control DNS and want/need to enforce something like this 
(enterprises, for example), I'm not sure how you'd go about this without 
resorting to e.g. group policy-like things which is messy in its own right.


There are some additional checks for "enterprise" networks including 
checking whether "enterprise roots" is enabled which I guess is 
different from simply loading in extra root certificates.  Why Mozilla 
and Google are SO insistent that I must not have control over my root 
certificate list is beyond me.


But yes, there's a Firefox pref to force it (or completely disable it 
regardless of the canary).  Amusingly, unlike most of the 
actually-useful Firefox prefs, this one is apparently in the GUI [1]. 
It also allows you to pick the provider (Cloudflare or "custom", of course).


The bare about:config pref you want is "network.trr.mode".  Short and 
sweet of it, set to 5 (off by choice), and it should disable the 
function entirely.  3 would be the opposite: always use it.


[1] https://support.mozilla.org/en-US/kb/firefox-dns-over-https
--
Brandon Martin

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Tue, Oct 01, 2019 at 08:22:58AM +0100,
 Brandon Butterworth  wrote 
 a message of 37 lines which said:

> Here are some UKNOF presentations on it -

Note that the UK is probably the country in Europe with the biggest
use of lying DNS resolvers for censorship. No wonder that the people
who censor don't like anti-censorship techniques.

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Mon, Sep 30, 2019 at 11:56:33PM -0400,
 Brandon Martin  wrote 
 a message of 10 lines which said:

> It's use-application-dns.net.  NXDOMAIN it, and Mozilla (at least)
> will go back to using your local DNS server list as per usual.

Unless, I hope, the user explicitely overrides this. (Because this
canary domain contradicts DoH's goals, by allowing the very party you
don't trust to remotely disable security.)

Re: This DNS over HTTP thing

[Stephane Bortzmeyer]

On Mon, Sep 30, 2019 at 11:46:04PM -0400,
 Fred Baker  wrote 
 a message of 28 lines which said:

> > Is there an official name for it I should be searching for?
> 
> The IETF calls it "DoH", pronounced like
> "Dough". https://datatracker.ietf.org/wg/doh/about/

And it is standardized in RFC 8484, which was published one year ago. 

> There are a number of such services from Google, Amazon, and
> others.

And you can build your own quite easily, these days, to avoid being
dependent on a few US corporations.

> One thing that bothers me about the Google implementation is that
> they apparently download the IANA zone and, in effect, operate as an
> informal root server. Not that I am protective of the root per se,
> but the root operators operate by an ethos described in RSSAC001
> (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf.).

This is in line with RFC 7706 "Decreasing Access Time to Root Servers
by Running One on Loopback", and the root zone operators explicitely
authorize zone transfer, partially for this purpose.

Re: This DNS over HTTP thing

[Brandon Butterworth]

On Mon Sep 30, 2019 at 10:38:31PM -0700, Matt Corallo wrote:
> It was mentioned in this (partially related) thread, with all the responses 
> being the predictable ???lol these folks in Silicon Valley need to lay off 
> the drugs???.
> 
> https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html

Here are some UKNOF presentations on it -

UKNOF43 - Potential ISP challenges with DNS over HTTPS
https://youtu.be/wRtpb7VRhGQ

UKNOF44 - The latest news in the DNS resolution
https://youtu.be/iDQ9axaaREU

UKNOF44 - Update on DoH and emerging IETF / IRTF standards
https://youtu.be/4SS9kEBgX1k

UKNOF44 - Panel: Operational Considerations of DoH Deployment
https://youtu.be/FqVX8WplEPg

> > On Sep 30, 2019, at 19:25, Jay R. Ashworth  wrote:
> > 
> > ???I've been embroiled in my first house-move in 28 years, and just got back
> > to the table.  I don't see any threads here about whatever this thing-which-
> > appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed 
> > it?
> > 
> > Is there an official name for it I should be searching for?
> > 
> > Is it in fact not a monstrosity, and I'm just not smart enough?  :-)
> > 
> > Cheers,
> > -- jra
> > 
> > -- 
> > Jay R. Ashworth  Baylink   
> > j...@baylink.com
> > Designer The Things I Think   RFC 
> > 2100
> > Ashworth & Associates   http://www.bcp38.info  2000 Land Rover 
> > DII
> > St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 
> > 1274

Re: AWS issues with 172.0.0.0/12

[Mehmet Akcin]

Hey Andras

Here you go

Warning: www.reolink.com has multiple addresses; using 52.21.66.90
traceroute to www.reolink.com (52.21.66.90) , 5 relative hops max, 52 byte
packets
   1 192.168.7.1 (192.168.7.1) 4.200 ms 55.354 ms 56.375 ms
   2 192.168.1.254 (192.168.1.254) 5.175 ms 56.006 ms 57.214 ms
   3 75-55-252-1.lightspeed.irvnca.sbcglobal.net (75.55.252.1) 7.264 ms
380.989 ms 382.969 ms
   4  *
 71.147.164.53 (71.147.164.53) 5899.218 ms 5979.390 ms
   5 71.147.164.53 (71.147.164.53) 0.394 ms
 cr1.la2ca.ip.att.net (12.123.30.78) 40.402 ms 214.075 ms
   6 cr1.la2ca.ip.att.net (12.123.30.78) 0.452 ms
 12.122.2.166 (12.122.2.166) 39.478 ms 213.425 ms
   7 12.122.2.166 (12.122.2.166) 0.393 ms
 12.122.2.81 (12.122.2.81) 36.410 ms 210.089 ms
   8 12.122.2.81 (12.122.2.81) 0.508 ms
 12.123.18.209 (12.123.18.209) 35.774 ms 111.450 ms
   9 12.123.18.209 (12.123.18.209) 0.383 ms
 12.244.76.10 (12.244.76.10) 36.579 ms 136.809 ms
 10 12.244.76.10 (12.244.76.10) 0.454 ms * *
 11  * * *
 12  * * *
 13  *

On Mon, Sep 30, 2019 at 23:32 Andras Toth  wrote:

> Hi Mehmet,
>
> A traceroute would be particularly useful.
>
> Have you tried accessing http://ec2-reachability.amazonaws.com/ to verify
> if the green icons load? If not, any particular region that's broken? Could
> you collect a traceroute towards some of the working and non-working IPs
> listed there?
>
> Andras
>
> On 1 Oct 2019, at 16:29, Mehmet Akcin  wrote:
>
> 
>
> Hey there
>
> AT is using 172.0.0.0/12 block as public IP for customers in USA. AWS
> seems to be blocking this block, I can reach to many sites just fine but i
> can’t get to some sites hosted on AWS such as reolink.com
>
> If someone from AWS is reading the list, please fix this issue
>
> Mehmet
> --
> Mehmet
> +1-424-298-1903
>
> --
Mehmet
+1-424-298-1903

Re: AWS issues with 172.0.0.0/12

[Andras Toth]

Hi Mehmet,

A traceroute would be particularly useful.

Have you tried accessing http://ec2-reachability.amazonaws.com/ to verify if 
the green icons load? If not, any particular region that's broken? Could you 
collect a traceroute towards some of the working and non-working IPs listed 
there?

Andras

> On 1 Oct 2019, at 16:29, Mehmet Akcin  wrote:
> 
> 
> Hey there
> 
> AT is using 172.0.0.0/12 block as public IP for customers in USA. AWS seems 
> to be blocking this block, I can reach to many sites just fine but i can’t 
> get to some sites hosted on AWS such as reolink.com
> 
> If someone from AWS is reading the list, please fix this issue
> 
> Mehmet
> -- 
> Mehmet
> +1-424-298-1903

AWS issues with 172.0.0.0/12

[Mehmet Akcin]

Hey there

AT is using 172.0.0.0/12 block as public IP for customers in USA. AWS
seems to be blocking this block, I can reach to many sites just fine but i
can’t get to some sites hosted on AWS such as reolink.com

If someone from AWS is reading the list, please fix this issue

Mehmet
-- 
Mehmet
+1-424-298-1903