Re: Yet another Quadruple DNS?

[Niels Bakker]

* eric-l...@truenet.com (Eric Tykwinski) [Fri 30 Mar 2018, 02:11 CEST]:
Still curious how they got a SSL cert for an IP address, as that was 
definitely interesting to me.


https://cabforum.org/guidance-ip-addresses-certificates/


-- Niels.

--

Re: Yet another Quadruple DNS?

[Eric Tykwinski]

> Is it just me, or is there a problem with the website? I get a nginx 403 
> Forbidden error when trying to access it.   
> 
> 
> 
> Regards, 
> Filip

I can verify it was working, but they might have gotten hammered after this 
thread.  Still curious how they got a SSL cert for an IP address, as that was 
definitely interesting to me.

Sincerely,

Eric Tykwinski
TrueNet, Inc.
P: 610-429-8300

Re: Re: Yet another Quadruple DNS?

[Filip Hruska]

  
  
Is it just me, or is there a problem with the website? I get a nginx 403 
Forbidden error when trying to access it.   
  

  
 Regards, 
Filip
  

  
  
  
  
  
>   
> On 29 Mar 2018 at 2:41 pm,wrote:
>   
>   
>  Cloudflare’s website provides some more information: https://1.1.1.1/ 
> According to Cloudflare’s CEO, we’ll have more news on 1/4, so in a few days. 
> https://twitter.com/eastdakota/status/979257292938911744 From their website I 
> can see that it is a low latency and privacy oriented service. Now whether 
> it’s actually needed, I think there’s place for it in the market. Currently 
> in Greece, 8.8.8.8 is ~65ms away. This is 11ms away. Antonis  >  On 29 Mar 
> 2018, at 14:46, Stephane Bortzmeyer wrote:  >   >  On Thu, Mar 29, 2018 at 
> 07:33:08AM -0400,  >  Matt Hoppes wrote  >  a message of 7 lines which said:  
> >   >>  We already have 8.8.8.8 and 8.8.4.4.  >   >  And 9.9.9.9 and several 
> others public DNS resolvers.  >   >>  And any reputable company or ISP should 
> be running their own.  >   >  I fully agree.  >   >>  What purpose would this 
> serve?  >   >  In Europe, the most common technique of censorship is through 
> lying  >  DNS resolvers. So, in order to go to forbidden Web sites (music and 
>  >  film sharing, for instance), many users switched from the ISP's  >  
> resolver (which implements the censorship) to a public resolver. See  >  my 
> talk at NANOG  >   
>   

Fwd: [vi...@isc.org: Planning to stop exporting BIND libraries]

[Rich Kulawiec]

Forwarding here to expose it to a larger, possibly-interested audience.
---rsk

- Forwarded message from Victoria Risk  -

> From: Victoria Risk 
> Date: Fri, 23 Mar 2018 12:30:26 +
> To: bind-annou...@lists.isc.org
> Subject: Planning to stop exporting BIND libraries
> 
> BIND currently exports number of libraries, including libisc, libisccfg, 
> libirs, libisccc, libdns and libbind9.
> 
> We don???t know of any external projects that use these libraries.  Keeping 
> the ABI and API stable is big burden, and we are exploring the possibility of 
> merging all the libraries into a tightly-coupled private library that 
> wouldn't be used outside of BIND (and tools). This change would effectively 
> make those libraries private.  
> 
> BIND 9.14 in 2019 would be the first release that would drop the libraries.
> 
> The BIND 9.11 ESV would keep those libraries until 2022, so any external 
> users would have enough time to migrate to other DNS libraries.
> 
> Known external users of libisc and friends:
> - ISC DHCP (will continue using BIND 9.11 libraries)
> - dnsperf (either use BIND 9.11 libraries, or offer ISC project)
> 
> Please let us know if you see a significant problem with this plan, including 
> which library you are using and how you are using it.
> 
> Thank you
> 
> Vicky
> 
> -
> Victoria Risk
> Product Manager
> Internet Systems Consortium
> vi...@isc.org
> 
> 

- End forwarded message -

Re: Yet another Quadruple DNS?

[joel jaeggli]

On 3/29/18 10:59 AM, Stephen Satchell wrote:
> In regards to: spoofing DNS to 8.8.8.8 et al
>
> On 03/29/2018 09:26 AM, Baldur Norddahl wrote:
>> Running your own resolver will not work.
>
> Why won't it work?  I run a Linux box with BIND 9 set up as a
> recursive resolver.  Are you saying that the rogues will also capture
> requests to the root DNS servers, as described in the hints file?
All destination port 53 udp packets.

Re: Yet another Quadruple DNS?

[Stephen Satchell]

In regards to: spoofing DNS to 8.8.8.8 et al

On 03/29/2018 09:26 AM, Baldur Norddahl wrote:

Running your own resolver will not work.


Why won't it work?  I run a Linux box with BIND 9 set up as a recursive 
resolver.  Are you saying that the rogues will also capture requests to 
the root DNS servers, as described in the hints file?

Re: Yet another Quadruple DNS?

[Ken Chase]

Who's got visible projects looking to detect this from various points/regimes
on the internet? 

(University of Toronto's IXMaps group whom I advised a few times over the
years did something similar for routes, not that BGPlay isnt out there, but
they translated it into human as a sociology project - borne of the Carnivore
era. https://www.ixmaps.ca/ )

Im glad no one said Namecoin yet.

Oops.

/kc


On Thu, Mar 29, 2018 at 04:26:47PM +, Baldur Norddahl said:
  >>
  >>
  >> Technically, tweaking your DNS resolver to lie (and/or to log) is much
  >> easier and faster (and way less expensive) than setting up a
  >> packet interception and rewriting device at line rate.
  >>
  >
  >It is just a static /32 route for well known DNS resolvers to the ISP
  >resolver. It is free and trivial. To make your resolver reply with the
  >correct IP you simply add all the well known /32 addresses to the localhost
  >interface.
  >
  >To get any service instead of just well known ones, you can use source
  >routing based on the port nummer 53. Direct this to a Linux server that
  >will NAT the traffic towards the ISP DNS. This is also trivial and free,
  >provided your routers support source routing (ours do).
  >
  >Detectable yes, but also hard to escape for the average user. They will
  >need to go full VPN. Running your own resolver will not work.
  >
  >Regards
  >
  >Baldur

-- 
Ken Chase - m...@sizone.org Guelph Canada

Re: Yet another Quadruple DNS?

[Hank Nussbacher]

On 29/03/2018 17:23, Jared Mauch wrote:
>> On Mar 29, 2018, at 10:19 AM, Seth Mattinen  wrote:
>>
>> On 3/29/18 7:17 AM, Izaac wrote:
 And I'd really like not to enrich my ISP's trove of information about
 my browsing habits by them recording all my DNS lookups.  Of course,
 9.9.9.9 could be collecting that information, but they're in less
 of a position to insert ads than my cableco is.
>>> Don't worry: they are.
>>>
>>>
>>> Needs more DNS over TLS.
> Good news everyone!
>
> https://datatracker.ietf.org/wg/doh/about/

H
https://threatpost.com/mozilla-tests-dns-over-https-meets-some-privacy-pushback/130765/
"Starting in the next several weeks, Mozilla plans to run tests using a
developer version of its Firefox browser with the help of the Mozilla
developer community and content management and delivery network firm
Cloudflare. Developers will be testing a proposed standard called
Trusted Recursive Resolver via DNS over HTTPS, or DoH for short."

Cloudflare and DoH.  Cloudflare and 1.1.1.1.  Coincidence?

-Hank

Re: Yet another Quadruple DNS?

[Baldur Norddahl]

>
>
> Technically, tweaking your DNS resolver to lie (and/or to log) is much
> easier and faster (and way less expensive) than setting up a
> packet interception and rewriting device at line rate.
>

It is just a static /32 route for well known DNS resolvers to the ISP
resolver. It is free and trivial. To make your resolver reply with the
correct IP you simply add all the well known /32 addresses to the localhost
interface.

To get any service instead of just well known ones, you can use source
routing based on the port nummer 53. Direct this to a Linux server that
will NAT the traffic towards the ISP DNS. This is also trivial and free,
provided your routers support source routing (ours do).

Detectable yes, but also hard to escape for the average user. They will
need to go full VPN. Running your own resolver will not work.

Regards

Baldur

Re: Yet another Quadruple DNS?

[Igor Krneta]

From 1.1.1.1 website:

Cloudflare DNS resolver:
**

 * For IPv4:*1.1.1.1*and/or*1.0.0.1*
 * For IPv6:*2001:2001::*and/or*2001:2001:2001::*

Its catchy enough for IPV6 :).

On 29.3.2018 15:07, Chip Marshall wrote:

I think the real question is "when are we going to get some memorable
IPv6 public recursive DNS servers?"

2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as
8.8.8.8 or 9.9.9.9.

RIPE NCC Global IPv6 Deployment Survey

[Massimiliano Stucchi]

Hi,

just a little reminder that there are a few days left to help the RIPE
NCC by filling up our Global IPv6 Deployment Survey.  We have already
received a considerable amount of responses, but would like to hear from
more people.

The goal of the survey is to get an overview of IPv6 deployment across
the world, and to assess how this is seen from the perspective of ISPs
and Enterprise users.

The 2018 survey is a follow up to similar surveys run between 2008 and
2013, and will serve as a comparison with the data acquired back then.

You can find the survey at the following address:

https://www.surveymonkey.com/r/GlobalIPv6survey2018

Responses can be submitted until 31 March 2018.

We will then collect the data with the aim of presenting the preliminary
results during the upcoming RIPE 76 meeting in Marseille.

If you have any question about the survey, please feel free to email us
at: ipv6survey2...@ripe.net.

Thank you very much in advance for your participation!

-- 

Massimiliano Stucchi
IPv6 Programme Manager
RIPE NCC
mstuc...@ripe.net

Follow us on Twitter for the fastest and latest RIPE NCC Training news!
@TrainingRIPENCC



signature.asc
Description: OpenPGP digital signature

Re: validating reachability via an ISP

[Alexander Azimov]

Hi Andy,

You can use Qrator.Radar API: https://api.radar.qrator.net/.
The get-all-paths method will return the set of active paths for selected
prefix.


2018-03-29 2:22 GMT+03:00 Andy Litzinger :

> Hi all,
>   I have an enterprise network and do not provide transit. In one of our
> datacenters we have our own prefixes and rely on two ISPs as BGP neighbors
> to provide global reachability for our prefixes.  One is a large regional
> provider and the other is a large global provider.
>
> Recently we took our link to the global provider offline to perform
> maintenance on our router.  Nearly immediately we were hit with alerts that
> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our
> route had been withdrawn.  We were not unreachable from every AS, but we
> certainly were from some of the largest.
>
> The root cause is that the our prefix is not being adequately
> re-distributed globally by the regional ISP.  This is unexpected and we are
> working through this with them now.
>
> My question is, how can I monitor global reachability for a prefix via this
> or any specific provider I use over time?  Are there various route-servers
> I can programmatically query for my prefix and get results that include AS
> paths? Then I could verify that an "acceptable" number of paths exist that
> include the AS of the all the ISPs I rely upon.  And what would an
> "acceptable" number of alternate paths be?
>
>
> thanks in advance,
>   -andy
>



-- 
| Alexander Azimov  | HLL l QRATOR
| tel.: +7 499 241 81 92
| mob.: +7 915 360 08 86
| skype: mitradir
| mailto: a...@qrator.net
| visit: www.qrator.net

Re: Yet another Quadruple DNS?

[Alan Buxey]

exactly.

intercept/inject? why. an ISP can just run its own standard DNS
servers on 8.8.8.8 and 8.8.4.4 and point
their customers to those - they own their routing space, they can just
route to those locallyso anyone thinking they
can avoid their ISP by choosing some other addresses are mistaken
the only way to avoid is through encrypted lookups
to a known/trusted/and signed endpoint etc

Re: Yet another Quadruple DNS?

[Bill Woodcock]

> On Mar 29, 2018, at 7:01 AM, Brian Kantor  wrote:
> 
> I use 9.9.9.9 for my home desktop to avoid the interception of my
> DNS queries by my cable company.  I'd very much rather get an
> NXDOMAIN than a connection to some web server that wants to offer
> me a "helpful" web page, even when I'm running a non-web client
> like ssh or 'dig'.
> 
> And I'd really like not to enrich my ISP's trove of information about
> my browsing habits by them recording all my DNS lookups.  Of course,
> 9.9.9.9 could be collecting that information, but they're in less
> of a position to insert ads than my cableco is.

The only queries for which the query string is collected are those which match 
the malware block-lists.

IP addresses are not collected for any queries, not even for ones which match 
the malware block-lists.

https://quad9.net/privacy/

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: Yet another Quadruple DNS?

[Michael Crapse]

Along these same lines, we have a service that captures all DNS requests
regardless the server(only non-TLS, albeit), that people pay $9.99/mo for,
so they definitely want this.. We just NAT all requests to Open DNS servers
to provide internet filtering as a service. It would be arbitrarily trivial
to run our own DNS service and reply to any unencrypted DNS request to any
DNS server with whatever A or  record we want..

On 29 March 2018 at 09:29, Bill Woodcock  wrote:

> > \On Mar 29, 2018, at 7:27 AM, Brian Kantor  wrote:
> >
> > On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote:
> >> I've never really understood this - if you don't trust your ISP's DNS,
> >> why would you trust them not to transparently intercept any well-known
> >> third-party DNS?
> >
> > Of course they could.  But it's testable; experiments show that they
> > aren't doing so currently.
>
> Experiments may show that in some tested cases they aren’t, but in the big
> picture, yes, there are ISPs who are internally capturing 8.8.8.8, and who
> try to do the same with 9.9.9.9.  Which is why it’s so important to do
> cryptographic validation of the server and encryption of the transport, as
> well as DNSSEC validation.
>
> -Bill
>
>

Re: Yet another Quadruple DNS?

[Bill Woodcock]

> \On Mar 29, 2018, at 7:27 AM, Brian Kantor  wrote:
> 
> On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote:
>> I've never really understood this - if you don't trust your ISP's DNS,
>> why would you trust them not to transparently intercept any well-known
>> third-party DNS?
> 
> Of course they could.  But it's testable; experiments show that they
> aren't doing so currently.

Experiments may show that in some tested cases they aren’t, but in the big 
picture, yes, there are ISPs who are internally capturing 8.8.8.8, and who try 
to do the same with 9.9.9.9.  Which is why it’s so important to do 
cryptographic validation of the server and encryption of the transport, as well 
as DNSSEC validation.

-Bill



signature.asc
Description: Message signed with OpenPGP

Re: validating reachability via an ISP

[Andrew Wentzell]

On Wed, Mar 28, 2018 at 7:22 PM, Andy Litzinger
 wrote:
> Hi all,
>   I have an enterprise network and do not provide transit. In one of our
> datacenters we have our own prefixes and rely on two ISPs as BGP neighbors
> to provide global reachability for our prefixes.  One is a large regional
> provider and the other is a large global provider.
>
> Recently we took our link to the global provider offline to perform
> maintenance on our router.  Nearly immediately we were hit with alerts that
> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our
> route had been withdrawn.  We were not unreachable from every AS, but we
> certainly were from some of the largest.
>
> The root cause is that the our prefix is not being adequately
> re-distributed globally by the regional ISP.  This is unexpected and we are
> working through this with them now.
>
> My question is, how can I monitor global reachability for a prefix via this
> or any specific provider I use over time?  Are there various route-servers
> I can programmatically query for my prefix and get results that include AS
> paths? Then I could verify that an "acceptable" number of paths exist that
> include the AS of the all the ISPs I rely upon.  And what would an
> "acceptable" number of alternate paths be?

I did something similar a few years ago, by querying routeviews and
validating AS paths using python and pexpect. You could adapt it for
your use pretty easily. The code's here:

https://github.com/awentzell/check-as-path

Re: Yet another Quadruple DNS?

[James R Cutler]

> On Mar 29, 2018, at 9:07 AM, Chip Marshall  > wrote:
> 
> ...
> I think the real question is "when are we going to get some memorable
> IPv6 public recursive DNS servers?"
> 
> 2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as
> 8.8.8.8 or 9.9.9.9.
> 
> -- 
> Chip Marshall >
> http://2bithacker.net/ 

Perhaps the real question is why is this important. The great mass of users 
simply does not even know what DNS is. And, supposedly, we wise NANOG people 
know how to cut and paste.

- 75.75.75.75
James R. Cutler
james.cut...@consultant.com 
PGP keys at http://pgp.mit.edu 

Re: Yet another Quadruple DNS?

[Seth Mattinen]

On 3/29/18 7:24 AM, Stephane Bortzmeyer wrote:

That's certainly a more important issue. Even when someone has skills,
he or she may not have the time and inclination to do system
administration at home. The solution is proper packaging of this
DNS function in ready-made boxes such as the Turris Omnia




I'm lazy and have been using 9.9.9.9 at home.

Re: Yet another Quadruple DNS?

[Stephane Bortzmeyer]

On Thu, Mar 29, 2018 at 09:08:38AM -0500,
 Chris Adams  wrote 
 a message of 12 lines which said:

> I've never really understood this - if you don't trust your ISP's
> DNS, why would you trust them not to transparently intercept any
> well-known third-party DNS?

Technically, tweaking your DNS resolver to lie (and/or to log) is much
easier and faster (and way less expensive) than setting up a
packet interception and rewriting device at line rate.

You're right, it is technically possible to "transparently intercept
any well-known third-party DNS". Two main ways, a routing trick (like
the one used in Turkey against Google Public DNS
)
which is simple, and packet-level interception devices like in China
,
which is not for the ordinary ISP.

That's why public DNS resolvers are not really a solution against
strong adversaries *unless* you authenticate and encrypt the
connection. Quad9 allows that
.

Public DNS resolvers still help against "ordinary" adversaries. (If
your ennemy is the NSA, you have other problems, anyway.)

Re: Yet another Quadruple DNS?

[Stephane Bortzmeyer]

On Thu, Mar 29, 2018 at 07:01:59AM -0700,
 Brian Kantor  wrote 
 a message of 20 lines which said:

> I believe that centralized DNS resolvers such as 8.8.8.8 are of
> benefit to those folks who can't run their own recursive resolver
> because of OS, hardware,

Hardware is not a real problem. A Raspberry Pi is more than enough to
run a resolver for a typical home.

> or skill limitations,

That's certainly a more important issue. Even when someone has skills,
he or she may not have the time and inclination to do system
administration at home. The solution is proper packaging of this
DNS function in ready-made boxes such as the Turris Omnia


> and yet do not trust the ones provided by their ISPs.

Unfortunately, the users are often right here :-(

Re: Yet another Quadruple DNS?

[Brian Kantor]

On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams wrote:
> I've never really understood this - if you don't trust your ISP's DNS,
> why would you trust them not to transparently intercept any well-known
> third-party DNS?

Of course they could.  But it's testable; experiments show that they
aren't doing so currently.
- Brian

Re: Yet another Quadruple DNS?

[Jared Mauch]

> On Mar 29, 2018, at 10:19 AM, Seth Mattinen  wrote:
> 
> On 3/29/18 7:17 AM, Izaac wrote:
>>> And I'd really like not to enrich my ISP's trove of information about
>>> my browsing habits by them recording all my DNS lookups.  Of course,
>>> 9.9.9.9 could be collecting that information, but they're in less
>>> of a position to insert ads than my cableco is.
>> Don't worry: they are.
> 
> 
> Needs more DNS over TLS.

Good news everyone!

https://datatracker.ietf.org/wg/doh/about/

- Jared

Re: Yet another Quadruple DNS?

[Seth Mattinen]

On 3/29/18 7:17 AM, Izaac wrote:

And I'd really like not to enrich my ISP's trove of information about
my browsing habits by them recording all my DNS lookups.  Of course,
9.9.9.9 could be collecting that information, but they're in less
of a position to insert ads than my cableco is.

Don't worry: they are.



Needs more DNS over TLS.

Re: Yet another Quadruple DNS?

[Izaac]

On Thu, Mar 29, 2018 at 07:01:59AM -0700, Brian Kantor wrote:
> do not trust the ones provided by their ISPs.

Ohhh!  Is that a thing?  Network operators doing crazy shit like
throwing A records to local machines instead of NXDOMAIN in order to
splash advertising at users?  Imagine users getting so frustrated at
this broken behavior that they engage in another broken behavior.

Whoever mentions "opt-out" gets a virtual smack on the back of the head.
Correct behavior is not "opt-in."

> And I'd really like not to enrich my ISP's trove of information about
> my browsing habits by them recording all my DNS lookups.  Of course,
> 9.9.9.9 could be collecting that information, but they're in less
> of a position to insert ads than my cableco is.

Don't worry: they are.

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: Yet another Quadruple DNS?

[Brian Kantor]

On Thu, Mar 29, 2018 at 09:38:09AM -0400, Izaac wrote:
> No, the real question is: why do you find it desirable to centralize a
> distributed service?

I believe that centralized DNS resolvers such as 8.8.8.8 are of
benefit to those folks who can't run their own recursive resolver
because of OS, hardware, or skill limitations, and yet do not trust
the ones provided by their ISPs.

I use 9.9.9.9 for my home desktop to avoid the interception of my
DNS queries by my cable company.  I'd very much rather get an
NXDOMAIN than a connection to some web server that wants to offer
me a "helpful" web page, even when I'm running a non-web client
like ssh or 'dig'.

And I'd really like not to enrich my ISP's trove of information about
my browsing habits by them recording all my DNS lookups.  Of course,
9.9.9.9 could be collecting that information, but they're in less
of a position to insert ads than my cableco is.
- Brian

aol login problems - my.screenname.aol.com

[Aaron Gould]

When going to aol.com and click "login/join" in top-right corner, brings you
to a login page. when I try to login, I get nothing. just tries and tries to
take me to the next page, which seems to be my.screenname.aol.com. but it
never gets there.  If I try from different subnets in my network, it does
work.  But from other subnets it does not.

 

Has anyone ever heard/seen this problem ?

 

Anyone from aol here that can assist with this please ?  You can contact me
directly if you can assist.

 

-Aaron

 

Re: Yet another Quadruple DNS?

[John Kinsella]

> On Mar 29, 2018, at 6:38 AM, Izaac  wrote:
> 
> On Thu, Mar 29, 2018 at 01:07:58PM +, Chip Marshall wrote:
>> I think the real question is "when are we going to get some memorable
>> IPv6 public recursive DNS servers?"
> 
> No, the real question is: why do you find it desirable to centralize a
> distributed service?

Any distributed service is made up of centralized services. This is one example.

Re: Yet another Quadruple DNS?

[Izaac]

On Thu, Mar 29, 2018 at 01:07:58PM +, Chip Marshall wrote:
> I think the real question is "when are we going to get some memorable
> IPv6 public recursive DNS servers?"

No, the real question is: why do you find it desirable to centralize a
distributed service?

-- 
. ___ ___  .   .  ___
.  \/  |\  |\ \
.  _\_ /__ |-\ |-\ \__

Re: Yet another Quadruple DNS?

[Doug Clements]

On Thu, Mar 29, 2018 at 9:07 AM, Chip Marshall  wrote:

> I think the real question is "when are we going to get some memorable
> IPv6 public recursive DNS servers?"
>
> 2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as
> 8.8.8.8 or 9.9.9.9.


>From https://1.1.1.1/:

For IPv6: *2001:2001::* and/or *2001:2001:2001::*

Those are pretty catchy.

--Doug

Re: Yet another Quadruple DNS?

[Chip Marshall]

On 2018-03-29, Stephane Bortzmeyer  sent:
> On Thu, Mar 29, 2018 at 07:33:08AM -0400,
>  Matt Hoppes  wrote 
>  a message of 7 lines which said:
> 
> > We already have 8.8.8.8 and 8.8.4.4.
> 
> And 9.9.9.9 and several others public DNS resolvers.

I think the real question is "when are we going to get some memorable
IPv6 public recursive DNS servers?"

2001:4860:4860:: or 2620:fe::fe just aren't quite as catchy as
8.8.8.8 or 9.9.9.9.

-- 
Chip Marshall 
http://2bithacker.net/

Re: Yet another Quadruple DNS?

[DaKnOb]

Cloudflare’s website provides some more information: https://1.1.1.1/ 


According to Cloudflare’s CEO, we’ll have more news on 1/4, so in a few days.
https://twitter.com/eastdakota/status/979257292938911744

From their website I can see that it is a low latency and privacy oriented 
service. Now whether it’s actually needed, I think there’s place for it in the 
market. Currently in Greece, 8.8.8.8 is ~65ms away. This is 11ms away. 

Antonis 

> On 29 Mar 2018, at 14:46, Stephane Bortzmeyer  wrote:
> 
> On Thu, Mar 29, 2018 at 07:33:08AM -0400,
> Matt Hoppes  wrote 
> a message of 7 lines which said:
> 
>> We already have 8.8.8.8 and 8.8.4.4.
> 
> And 9.9.9.9 and several others public DNS resolvers.
> 
>> And any reputable company or ISP should be running their own.
> 
> I fully agree.
> 
>> What purpose would this serve?
> 
> In Europe, the most common technique of censorship is through lying
> DNS resolvers. So, in order to go to forbidden Web sites (music and
> film sharing, for instance), many users switched from the ISP's
> resolver (which implements the censorship) to a public resolver. See
> my talk at NANOG
> 

Re: Yet another Quadruple DNS?

[Stephane Bortzmeyer]

On Thu, Mar 29, 2018 at 07:33:08AM -0400,
 Matt Hoppes  wrote 
 a message of 7 lines which said:

> We already have 8.8.8.8 and 8.8.4.4.

And 9.9.9.9 and several others public DNS resolvers.

> And any reputable company or ISP should be running their own.

I fully agree.
 
> What purpose would this serve?

In Europe, the most common technique of censorship is through lying
DNS resolvers. So, in order to go to forbidden Web sites (music and
film sharing, for instance), many users switched from the ISP's
resolver (which implements the censorship) to a public resolver. See
my talk at NANOG

Re: Yet another Quadruple DNS?

[Mike Hammett]

Oddly, Matt, we agree again. 





- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Matt Hoppes"  
To: "Stephane Bortzmeyer"  
Cc: "NANOG list"  
Sent: Thursday, March 29, 2018 6:33:08 AM 
Subject: Re: Yet another Quadruple DNS? 

Why do we need this? 

We already have 8.8.8.8 and 8.8.4.4. 

And any reputable company or ISP should be running their own. 

What purpose would this serve? 

Re: Yet another Quadruple DNS?

[Stephane Bortzmeyer]

On Thu, Mar 29, 2018 at 12:16:48PM +0100,
 Tony Finch  wrote 
 a message of 15 lines which said:

> Also the very amusing
> 
> https://twitter.com/eastdakota/status/970359846548549632

Less amusing, for a DNS service, the brokenness of reverse service:

% dig -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> -x 1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24536
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 516 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Mar 29 13:37:54 CEST 2018
;; MSG SIZE  rcvd: 49


% dig @ns1.apnic.net. NS 1.1.1.in-addr.arpa

; <<>> DiG 9.10.3-P4-Debian <<>> @ns1.apnic.net. NS 1.1.1.in-addr.arpa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48493
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;1.1.1.in-addr.arpa.IN NS

;; AUTHORITY SECTION:
1.1.1.in-addr.arpa. 86400 IN NS ns7.cloudflare.com.
1.1.1.in-addr.arpa. 86400 IN NS ns3.cloudflare.com.
1.1.1.in-addr.arpa. 172800 IN NSEC 113.1.1.in-addr.arpa. NS RRSIG NSEC
1.1.1.in-addr.arpa. 172800 IN RRSIG NSEC 5 5 172800 (
20180427150337 20180328140337 2371 
1.in-addr.arpa.
h44NAaTSpn5wvzTtddlUEKJ8+bikdaTDXnxh5M1bisO0
/NibM7iWfwcuaaWPvNeOutMdA0OBxGwbmErattfyXbRI
KWrBWopBkr8+uVo7BgBYBa2SqY7PdUyYIt40PTjwnsrl
lxBgaHMe1yz6qvQh2oljUJL45HkJnVWoHnuTRq8= )

;; Query time: 317 msec
;; SERVER: 2001:dc0:2001:0:4608::25#53(2001:dc0:2001:0:4608::25)
;; WHEN: Thu Mar 29 13:38:05 CEST 2018
;; MSG SIZE  rcvd: 313


% dig @ns7.cloudflare.com -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> @ns7.cloudflare.com -x 1.1.1.1
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 10538
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 7 msec
;; SERVER: 2400:cb00:2049:1::a29f:606#53(2400:cb00:2049:1::a29f:606)
;; WHEN: Thu Mar 29 13:38:25 CEST 2018
;; MSG SIZE  rcvd: 49


% dig @ns3.cloudflare.com -x 1.1.1.1

; <<>> DiG 9.10.3-P4-Debian <<>> @ns3.cloudflare.com -x 1.1.1.1
; (4 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 27962
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1.1.1.1.in-addr.arpa.  IN PTR

;; Query time: 6 msec
;; SERVER: 2400:cb00:2049:1::a29f:21#53(2400:cb00:2049:1::a29f:21)
;; WHEN: Thu Mar 29 13:38:33 CEST 2018
;; MSG SIZE  rcvd: 49

Re: Yet another Quadruple DNS?

[Matt Hoppes]

Why do we need this?

We already have 8.8.8.8 and 8.8.4.4. 

And any reputable company or ISP should be running their own. 

What purpose would this serve?

Re: Yet another Quadruple DNS?

[Stephane Bortzmeyer]

On Wed, Mar 28, 2018 at 11:16:15PM +0300,
 DaKnOb  wrote 
 a message of 25 lines which said:

> Out of 1,000 RIPE Atlas Probes, only 34 report it as unreachable.

It's still a lot for IPv4. And it measures ony filtering, not hijacking
(which seems to exist, some probes get a DNS reply without the AD
bit, for instance).

Because of the heavy use of 1.1.1.1 in documentation, you can expect a
lot of networks to have trouble. Hey, 1.1.1.1 is even used in
Cloudflare's own documentation!

Re: Yet another Quadruple DNS?

[Tony Finch]

David Ulevitch  wrote:

> https://twitter.com/eastdakota/status/970214433598275584
> https://twitter.com/eastdakota/status/970359846548549632

Also the very amusing

https://twitter.com/eastdakota/status/970359846548549632

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Hebrides, Bailey: East 5 to 7, occasionally gale 8 at first. Rough,
occasionally very rough at first. Rain or showers. Good, occasionally
moderate.

Re: validating reachability via an ISP

[Baldur Norddahl]

Also the only traffic you will be receiving on the other provider will be
from parties that did not pick up the more specific prefix. It should
therefore be really obvious. You should not receive any traffic at all, not
even from the transit provider.

Regards,

Baldur


Den tor. 29. mar. 2018 10.41 skrev Baldur Norddahl <
baldur.nordd...@gmail.com>:

> If your prefix is larger than /24 you can test with a more specific prefix
> such as a /24. Announce the test prefix on just one transit provider. Then
> check with BGP services such as the looking glass service provided by the
> NLNOG RING network.
>
> There will be no interruption in the traffic as it will follow the less
> specific prefix everywhere the test prefix was not picked up.
>
> If you only have a /24 you will need to test in a service window.
>
> Regards
>
> Baldur
>
>
> Den tor. 29. mar. 2018 01.24 skrev Andy Litzinger <
> andy.litzinger.li...@gmail.com>:
>
>> Hi all,
>>   I have an enterprise network and do not provide transit. In one of our
>> datacenters we have our own prefixes and rely on two ISPs as BGP neighbors
>> to provide global reachability for our prefixes.  One is a large regional
>> provider and the other is a large global provider.
>>
>> Recently we took our link to the global provider offline to perform
>> maintenance on our router.  Nearly immediately we were hit with alerts
>> that
>> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted
>> our
>> route had been withdrawn.  We were not unreachable from every AS, but we
>> certainly were from some of the largest.
>>
>> The root cause is that the our prefix is not being adequately
>> re-distributed globally by the regional ISP.  This is unexpected and we
>> are
>> working through this with them now.
>>
>> My question is, how can I monitor global reachability for a prefix via
>> this
>> or any specific provider I use over time?  Are there various route-servers
>> I can programmatically query for my prefix and get results that include AS
>> paths? Then I could verify that an "acceptable" number of paths exist that
>> include the AS of the all the ISPs I rely upon.  And what would an
>> "acceptable" number of alternate paths be?
>>
>>
>> thanks in advance,
>>   -andy
>>
>

Re: validating reachability via an ISP

[Baldur Norddahl]

If your prefix is larger than /24 you can test with a more specific prefix
such as a /24. Announce the test prefix on just one transit provider. Then
check with BGP services such as the looking glass service provided by the
NLNOG RING network.

There will be no interruption in the traffic as it will follow the less
specific prefix everywhere the test prefix was not picked up.

If you only have a /24 you will need to test in a service window.

Regards

Baldur


Den tor. 29. mar. 2018 01.24 skrev Andy Litzinger <
andy.litzinger.li...@gmail.com>:

> Hi all,
>   I have an enterprise network and do not provide transit. In one of our
> datacenters we have our own prefixes and rely on two ISPs as BGP neighbors
> to provide global reachability for our prefixes.  One is a large regional
> provider and the other is a large global provider.
>
> Recently we took our link to the global provider offline to perform
> maintenance on our router.  Nearly immediately we were hit with alerts that
> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted our
> route had been withdrawn.  We were not unreachable from every AS, but we
> certainly were from some of the largest.
>
> The root cause is that the our prefix is not being adequately
> re-distributed globally by the regional ISP.  This is unexpected and we are
> working through this with them now.
>
> My question is, how can I monitor global reachability for a prefix via this
> or any specific provider I use over time?  Are there various route-servers
> I can programmatically query for my prefix and get results that include AS
> paths? Then I could verify that an "acceptable" number of paths exist that
> include the AS of the all the ISPs I rely upon.  And what would an
> "acceptable" number of alternate paths be?
>
>
> thanks in advance,
>   -andy
>