A reminder to go back and watch the awesome talk from Nanog 49 about this: https://youtu.be/RBOPcLpQZ8w https://www.nanog.org/meetings/nanog49/presentations/Monday/karir-1slash8.pd... - Jared

On Mar 28, 2018, at 4:25 PM, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, probably doing some more data gathering on 1.1.1.1 and doesn't want to be smashed with Gigs of traffic. Transit is still quite expensive in Aus :)

https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt

On Thu, 29 Mar 2018 at 07:08 Bill Woodcock <woody@pch.net> wrote:

...

...

On Mar 28, 2018, at 11:14 AM, Payam Poursaied <me@payam124.com> wrote:

dig google.com @1.1.1.1 Cloudflare?

Yeah, Cloudflare did a deal with Geoff Huston to use it. It’s reserved for “experimental use."

-Bill

--

Best Wishes,

Aftab A. Siddiqui

On Mar 28, 2018, at 2:39 PM, David Ulevitch <david@ulevitch.com> wrote:

On Wed, Mar 28, 2018 at 1:27 PM Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote: 1.1.1.0/24 and 1.0.0.0/24 both are APNIC's Lab Research Prefixes. APNIC, probably doing some more data gathering on 1.1.1.1 and doesn't want to be smashed with Gigs of traffic.

Doubtful. This is most assuredly going to be a commercial production recursive DNS service. Matthew (CEO) has said as much on Twitter.

Yep, they’ve been trying to put something together in this space for several years. Sounds like it may be close now. I can’t say I envy them their task, as it will be very difficult for them to differentiate in that space, since they don’t have OpenDNS’s many years of experience and fine-tuning and security services, nor Google’s brand-recognition. Verisign have had a reasonably good commercial offering in this space for years, and hardly anyone’s heard of it, for instance. I believe even Neustar does. And they’re all DNS specialists, rather than web-content specialists. -Bill

On Thu, Mar 29, 2018 at 12:16:48PM +0100, Tony Finch <dot@dotat.at> 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

Out of 1,000 RIPE Atlas Probes, only 34 report it as unreachable. Very good latency from those who can reach it.. https://atlas.ripe.net/measurements/11859210/#!general <https://atlas.ripe.net/measurements/11859210/#!general> Antonis

On 28 Mar 2018, at 23:13, Michael Crapse <michael@wi-fiber.io> wrote:

Many providers filter out 1.1.1.1 because too many people use it in their examples/test code. I doubt that it's a usable IP/service.

On 28 March 2018 at 12:14, Payam Poursaied <me@payam124.com> wrote:

...

dig google.com @1.1.1.1

Cloudflare?

Didn't find any news around it

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?

On Thu, Mar 29, 2018 at 07:33:08AM -0400, Matt Hoppes <mattlists@rivervalleyinternet.net> 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 <https://www.nanog.org/sites/default/files/Bortzmeyer_Dns-Based_Censorship.pdf>

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, <DaKnOb> 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 >

* eric-list@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. --

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::8888 or 2620:fe::fe just aren't quite as catchy as 8.8.8.8 or 9.9.9.9.

On Thu, Mar 29, 2018 at 01:07:58PM +0000, 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? -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

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

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

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 AAAA record we want.. On 29 March 2018 at 09:29, Bill Woodcock <woody@pch.net> wrote:

...

\On Mar 29, 2018, at 7:27 AM, Brian Kantor <Brian@ampr.org> 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

On Thu, Mar 29, 2018 at 08:29:57AM -0700, Bill Woodcock <woody@pch.net> wrote a message of 53 lines which said:

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.

And the good thing is that RFC 8310 has been published one week ago. I'm waiting for its deployment in Quad9 :-) https://www.rfc-editor.org/info/rfc8310

On Thu, Mar 29, 2018 at 09:08:38AM -0500, Chris Adams <cma@cmadams.net> 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 waaaaay 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 <https://labs.ripe.net/Members/emileaben/a-ripe-atlas-view-of-internet-meddling-in-turkey>) which is simple, and packet-level interception devices like in China <https://labs.ripe.net/Members/pk/denic-case-study-using-ripe-atlas>, 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 <https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security>. Public DNS resolvers still help against "ordinary" adversaries. (If your ennemy is the NSA, you have other problems, anyway.)

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 +0000, Baldur Norddahl said:

...

Technically, tweaking your DNS resolver to lie (and/or to log) is much easier and faster (and waaaaay 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 - math@sizone.org Guelph Canada

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.

On Fri, Mar 30, 2018 at 5:30 AM, Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Thu, Mar 29, 2018 at 10:32 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:

...

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

If you're individually targeted by such an org, yes. If you want to raise the cost of slurping up everyone's traffic in bulk and then sifting/analytic-ing through it later, then some effort (encrypting/verifying everything feasible, using ciphers that support forward secrecy, MFA, etc.) is worthwhile. Bulk encryption is a reasonable response to bulk intercept. Raising the chances of *detecting* attempts at such interception is also warranted. I'm not aware of any browser extensions that incorporate the technique used by https://mitm.watch/ (or even if it's feasible at that layer), but that would be useful, too.

I think there's ample evidence that everyone's enemy is 'the nsa' (or other nation-state-actors) isn't there?

s/"nation-state"/"anyone who can intercept, alter, or inject traffic between you and your destination"/g. Of course, that neither solves the problem of manipulative use of your traffic *by* your destination (*cough*Facebook/everyone*cough*) nor the problem of compromise of the endpoint. Increasing intercept resistance does nothing for the former (only voting, or voting with your dollar, can impact that) ... but it can help with the latter (by making it harder for someone to compromise your endpoint by manipulating/mimicking traffic from your destination). (None of this is news to most of you, but IMO clarifying the breadth of the landscape has value). And of course, none of this is news to Stephane: https://tools.ietf.org/html/rfc7816 :) Royce

On Fri, Mar 30, 2018 at 06:46:19AM -0800, Royce Williams <royce@techsolvency.com> wrote a message of 19 lines which said:

Full survey - with owners of the largest bit-boundary-aligned blocks that contain them - here:

https://gist.github.com/roycewilliams/6cb91ed94b88730321ca3076006229f1

Unlike what you say, 112.112.112.112 works (note for the humour-impaired: there is a trick): % dig @112.112.112.112 facebook.com ; <<>> DiG 9.10.3-P4-Debian <<>> @112.112.112.112 facebook.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41543 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;facebook.com. IN A ;; ANSWER SECTION: facebook.com. 126 IN A 31.13.74.1 ;; Query time: 218 msec ;; SERVER: 112.112.112.112#53(112.112.112.112) ;; WHEN: Fri Mar 30 16:54:12 CEST 2018 ;; MSG SIZE rcvd: 57

On Fri, Mar 30, 2018 at 03:57:24PM +0100, William Waites <wwaites@tardis.ed.ac.uk> wrote a message of 48 lines which said:

...

77.77.77.77 - Dadeh Gostar Asr Novin P.J.S. Co. (Iran) | 77.77.64/19 | recursion-yes

Well, that one's a little odd:

I think that, for the government of this country, it is seen as a feature, not a bug.

uh, quad the f do you think you're doing?! you think anything.255 is routable by COTS gear? :) maybe everyone who operates x.y/16 should be setting up their open resolvers on x.y.x.y (can i get an rfc up in the hizzy? apr 1 is rsn.) /kc On Fri, Mar 30, 2018 at 05:02:27PM +0000, Feldman, Mark said:

Another one for the list... We're working on fielding our quad-255 (255.255.255.255) DNS. It's currently pingable but not yet providing resolution. We're aiming for an April 1st release. One of the most widley-distributed quads out there. We're thinking about calling it QUAdFF -- drink it up.

Mark

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

Greetings, On Fri, 30 Mar 2018, Feldman, Mark wrote:

Another one for the list... We're working on fielding our quad-255 (255.255.255.255) DNS. It's currently pingable but not yet providing resolution. We're aiming for an April 1st release. One of the most widley-distributed quads out there. We're thinking about calling it QUAdFF -- drink it up.

And serves as a combined DNS and DHCP server, too!!! --- Jay Nugent o Averaging at least 3 days of MTBWTF!?!?!? o The solution for long term Internet growth is IPv6.

On Fri, Mar 30, 2018 at 11:22 AM, Ken Chase <math@sizone.org> wrote:

On Fri, Mar 30, 2018 at 09:30:00AM -0400, Christopher Morrow said:

...

I think there's ample evidence that everyone's enemy is 'the nsa' (or other nation-state-actors) isn't there?

Or yourself, after you flip the EU off.

https://www.theregister.co.uk/2018/03/29/eu_dumps_300000_ ukowned_domains_into_brexit_bin/

pretty hilarious the places brexit is having effects.

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. -- . ___ ___ . . ___ . \ / |\ |\ \ . _\_ /__ |-\ |-\ \__

On Mar 29, 2018, at 10:19 AM, Seth Mattinen <sethm@rollernet.us> 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

On Thu, Mar 29, 2018 at 07:01:59AM -0700, Brian Kantor <Brian@ampr.org> 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 <https://omnia.turris.cz/>

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

Unfortunately, the users are often right here :-(

On Thu, 29 Mar 2018, Seth Mattinen wrote:

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

nameserver 1.1 /mark

On Mar 29, 2018, at 9:07 AM, Chip Marshall <chip@2bithacker.net <mailto:chip@2bithacker.net>> wrote:

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

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

-- Chip Marshall <chip@2bithacker.net <mailto:chip@2bithacker.net>> http://2bithacker.net/ <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.cutler@consultant.com <mailto:James.cutler@consultant.com> PGP keys at http://pgp.mit.edu <http://pgp.mit.edu/>

On Wed, Mar 28, 2018 at 9:13 PM, Michael Crapse <michael@wi-fiber.io> wrote:

Many providers filter out 1.1.1.1 because too many people use it in their examples/test code. I doubt that it's a usable IP/service.

having previously globally announce 1.1.1.1 ... and some other of it's friends... not nearly enough people filter it. We regularly saw ~10gbps+ of traffic to those prefixes.

On 28 March 2018 at 12:14, Payam Poursaied <me@payam124.com> wrote:

...

dig google.com @1.1.1.1

Cloudflare?

Didn't find any news around it

https://www.wired.com/story/new-encryption-service-adds-privacy-protection-f... On Sat, Mar 31, 2018 at 5:08 PM, <nop@imap.cc> wrote:

On Sat, Mar 31, 2018, at 2:18 PM, Mehmet Akcin wrote:

...

Very disappointing to see a popular prefix being allocated/reseved for research then being allocated to a company without public consultation. I am sure APNIC community will ask APNIC Sr. management for an explanation.

This prefix , if it will be given to any business , should go thru a transparent bidding process OR regular APNIC allocation process transprently.

From what I can tell, this has not been "allocated" (probably closer to a LOA)? All contacts and maintainers on the inetnum object are still APNIC's, Cloudflare does not have free access to do whatever they want here.

https://1.1.1.1 link has details of the service. No official announcement from APNIC (though Geoff replied my direct email inquiry privately) I don’t know why this prefix was handed over to any company for a service without public consultation but again this may or may not be required. I am just suprised to see lack of transparency about this allocation rather than anything else. World needs more services like this to make internet better and safer, i don’t think it is important what IPs are , ie: opendns , they might not have fancy ip block but they get the job done!(well done!) Mehmet On Sat, Mar 31, 2018 at 6:06 PM Jimmy Hess <mysidia@gmail.com> wrote:

On Sat, Mar 31, 2018 at 7:08 PM, <nop@imap.cc> wrote:

...

From what I can tell, this has not been "allocated" (probably closer to a LOA)? All contacts and maintainers on the inetnum object are still APNIC's, Cloudflare does not have free access to do whatever they want here.

Did you ask WHOIS? Looks like the /24 is Portable-Assigned to a joint project. I don't know that APNIC is necessarily required to make a public consultation;.

If it was from an ARIN block; ARIN wouldn't have to "ask the public either"... the Number Resource Policy allows for /24 micro-allocations for critical infrastructure, which exactly describes the nature of an anycasted /24 for the service IP of a shared open DNS recursive resolver service, and the RIR could potentially allocate from any block under their control that were deemed most suitable for the critical infrastructure.

Then again, maybe APNIC made a consultation at their February meeting in Nepal? One thing i'm sure is they wouldn't have to ask NANOG's permission.

$ whois 1.1.1.1 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

% Information related to '1.1.1.0 - 1.1.1.255' % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse@apnic.net'

inetnum: 1.1.1.0 - 1.1.1.255 netname: APNIC-LABS descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare descr: Research prefix for APNIC Labs country: AU org: ORG-ARAD1-AP admin-c: AR302-AP tech-c: AR302-AP mnt-by: APNIC-HM mnt-routes: MAINT-AU-APNIC-GM85-AP mnt-irt: IRT-APNICRANDNET-AU status: ASSIGNED PORTABLE remarks: --------------- remarks: All Cloudflare abuse reporting can be done via remarks: resolver-abuse@cloudflare.com remarks: --------------- last-modified: 2018-03-30T01:51:28Z source: APNIC

.....

-- -JH

Well that isnt optimal for root servers. Every cpe querying root would be waste really. Though we can copy root zone into recursive servers (not via DNS) and serve from CPEs that way. I think the real problem is restictions of networks who won’t let you run this on your devices. Mehmet On Sun, Apr 1, 2018 at 8:18 AM Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:

Do we? (Need more services like this?)

Why not just implement recursive cache severs on end user routers? Why does an end user CPE need to query one or two specific DNS servers?

Recursive servers like PowerDNS are extremely simple and light weight.

Is there a legitimate reason things don’t just query the root servers directly? Or at least have that option?

...

On Apr 1, 2018, at 11:05, Mehmet Akcin <mehmet@akcin.net> wrote:

https://1.1.1.1 link has details of the service.

No official announcement from APNIC (though Geoff replied my direct email inquiry privately)

I don’t know why this prefix was handed over to any company for a service without public consultation but again this may or may not be required. I am just suprised to see lack of transparency about this allocation rather than anything else.

World needs more services like this to make internet better and safer, i don’t think it is important what IPs are , ie: opendns , they might not have fancy ip block but they get the job done!(well done!)

Mehmet

...

On Sat, Mar 31, 2018 at 6:06 PM Jimmy Hess <mysidia@gmail.com> wrote:

...

On Sat, Mar 31, 2018 at 7:08 PM, <nop@imap.cc> wrote:

From what I can tell, this has not been "allocated" (probably closer to a LOA)? All contacts and maintainers on the inetnum object are still APNIC's, Cloudflare does not have free access to do whatever they want here.

Did you ask WHOIS? Looks like the /24 is Portable-Assigned to a joint project. I don't know that APNIC is necessarily required to make a public consultation;.

If it was from an ARIN block; ARIN wouldn't have to "ask the public either"... the Number Resource Policy allows for /24 micro-allocations for critical infrastructure, which exactly describes the nature of an anycasted /24 for the service IP of a shared open DNS recursive resolver service, and the RIR could potentially allocate from any block under their control that were deemed most suitable for the critical infrastructure.

Then again, maybe APNIC made a consultation at their February meeting in Nepal? One thing i'm sure is they wouldn't have to ask NANOG's permission.

$ whois 1.1.1.1 % [whois.apnic.net] % Whois data copyright terms http://www.apnic.net/db/dbcopyright.html

% Information related to '1.1.1.0 - 1.1.1.255' % Abuse contact for '1.1.1.0 - 1.1.1.255' is 'abuse@apnic.net'

inetnum: 1.1.1.0 - 1.1.1.255 netname: APNIC-LABS descr: APNIC and Cloudflare DNS Resolver project descr: Routed globally by AS13335/Cloudflare descr: Research prefix for APNIC Labs country: AU org: ORG-ARAD1-AP admin-c: AR302-AP tech-c: AR302-AP mnt-by: APNIC-HM mnt-routes: MAINT-AU-APNIC-GM85-AP mnt-irt: IRT-APNICRANDNET-AU status: ASSIGNED PORTABLE remarks: --------------- remarks: All Cloudflare abuse reporting can be done via remarks: resolver-abuse@cloudflare.com remarks: --------------- last-modified: 2018-03-30T01:51:28Z source: APNIC

.....

-- -JH

Unless you want optimum CDN performance, then your recursive servers belong pushed back in your network until there are no more diverse upstream\peer paths to choose from. Yes, I know there's an extension to DNS to help remove this need, but until that's universally supported, you can't abandon the old way. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Stephen Satchell" <list@satchell.net> To: nanog@nanog.org Sent: Sunday, April 1, 2018 11:22:10 AM Subject: Re: Yet another Quadruple DNS? On 04/01/2018 08:18 AM, Matt Hoppes wrote:

Why not just implement recursive cache severs on end user routers? Why does an end user CPE need to query one or two specific DNS servers? Recursive lookups take bandwidth and wall time. The closer you can get your recursive DNS server to the core of the internet, the faster the lookups. This is particularly true of mobile and satellite.

Implementing large caches in that close-to-the-core DNS server can add another benefit: lookups to common and popular endpoints, such as Google, would require far less real time to resolve. As the traffic tides change, the cache would change with it, so flash-in-the-pan sites would be served from cache, and forgotten in time when said sites drift back to obscurity. (I wonder if the Internet Systems Consortium has considered adding a cache-hit counter, or even a very coarse heat map (say, four 16-bit counters cycled every five minutes), to DNS entries, to figure out the best ones to drop? It would increase the complexity of BIND, but the benefit for a BIND server serving a largish customer population could be significant. If I were younger, I might try to model such a change. Sort by hits, then by time-to-die. Drop the oldest 250 or so entries when the cache is full. That way, the oldest least-used cache entries get dropped.) ISPs provide to their customers DNS addresses to servers that, allegedly, are closer to the core than the customers are. (Pipe dream, I know; which is why so many ISPs have decided to specify 8.8.8.8 and 8.8.4.4, because Google is closer to the core than the ISP is.) I've not personally measured the number of times a look-up could be satisfied from a cache in a production environment; it's been 15 years since I worked in such a job. It would be interesting to see if someone has taken the time to gather those statistics and published them. The main reason for *not* implementing recursion exclusively in CPE is that a recursive lookup is a complex operation, and I have my doubts if BIND or equivalent could be maintained properly in, say, a wireless access point (router) -- how would you update a hints table?

mhoppes> Why not just implement recursive cache severs on end user mhoppes> routers? Because who ever saw problems with old, unpatched code or misconfigured CPE routers? And they all use the best possible hardware and are at the end of uncongested, close to the core connections. Not. ;) mhoppes>> Why does an end user CPE need to query one or two specific DNS mhoppes>> servers? Better cache hit rates, professionally run and maintained DNS servers, better connectivity, all resulting in better performance. Yes, geo-ip is a bit off but in most large ISPs, caching recursive servers are very close to the same exit point for consumer connections and the CDN folks keep close track of this. And EDNS client subnet mostly works. And yes, running your own resolver is more private. So is running your own home linux server instead of antique consumer OSs on consumer grade gear and using VPNs. But how many folks can do that? This also ignores the shift if every house in the world did its own recursion. TLD servers and auth servers all over the world would have to massively up their capacity to cope. And you'd wind up consolidating small domain owners onto folks like godaddy, etc. because they couldn't run their own and survive. Large caches are a win for both users and auth DNS servers. None of these are bad or good. They all have tradeoffs. As long as ISPs don't actually disallow running of recursive servers (or do opt-in like some ISPs do with running your own MX), there are folks that will want to run their own. Some will want the ISP resolvers, some will want to use some of the well run public resolvers (like google, opendns, quad9, cloudflare). Choices aren't a bad thing.

Here is the update from Geoff himself. I guess they didn't want to publish it on April 1st (AEST). https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreemen... On Mon, 2 Apr 2018 at 09:51 Stephen Satchell <list@satchell.net> wrote:

On 04/01/2018 01:03 PM, Paul Ebersman wrote:

...

And yes, running your own resolver is more private. So is running your own home linux server instead of antique consumer OSs on consumer grade gear and using VPNs. But how many folks can do that?

<raises hand>

I gave up on Microsoft desktop products more than 15 years ago. Mac products more than 7 years ago. (When Apple refused to fix my broken MacBook screen, that was it for Apple.)

Why do I run my own servers, including a mail server? Court subpoenas. When I was working at a Web host company, I got several of these things, complete with gag orders. Mail captures, mostly.

One time the Nevada Gaming Commission wanted to take an image of a colo customer's hard drive. The fool they brought was a MSCE, and knew *nothing* about Unix and Linux. Ended up having to do the mirror myself, and sign an affidavit to boot. (Customer was running an on-line poker service without a license, which is unlawful in Nevada.)

I want to know when a LEO gets access to my data.

-- Best Wishes, Aftab A. Siddiqui

On Mon, Apr 02, 2018 at 09:07:07AM +0000, Baldur Norddahl wrote:

The problem I see here is the five year research term after which they may or may not revoke the use of the prefix.

This is harmful. Such services should be stable. If you are going to let cloudflare run this service, it should be permanent.

Regards

Baldur

I would maintain that in the context of hi-tech for-profit industry and the Internet, five years is a very close approximation of permanent. - Brian

On 2 Apr 2018, at 10:32, William Waites <wwaites@tardis.ed.ac.uk> wrote:

...

On 2 Apr 2018, at 02:57, Aftab Siddiqui <aftab.siddiqui@gmail.com> wrote:

Here is the update from Geoff himself. I guess they didn't want to publish it on April 1st (AEST). https://blog.apnic.net/2018/04/02/apnic-labs-enters-into-a-research-agreemen...

The research justification for a RIR to do this seems a little thin. Surely we, as a community already know about what happens when a company operates a public resolver. How will yet another one will tell us more?

The connectivity aspects could easily be done by using ripe atlas probe queries with dns type. Colin

On Sun, Apr 01, 2018 at 02:03:41PM -0600, Paul Ebersman <list-nanog2@dragon.net> wrote a message of 38 lines which said:

And EDNS client subnet mostly works.

It is awful, privacy-wise, complicates the cache a lot and seriously decreases hit rate in cache (since the key to a cached resource is no longer type+name but type+name+source_address).

And yes, running your own resolver is more private. So is running your own home linux server instead of antique consumer OSs on consumer grade gear and using VPNs. But how many folks can do that?

It is not just an issue of knowledge and skills. Even if you have both, you may lack time, and prefer a shrink-wrapped solution. The future is in "boxes" which are both ready-to-use (for the guy who lacks sysadmin skills, and/or lacks time) and open (for the tinkerer). The Turris Omnia <https://omnia.turris.cz/en/> is a very good example.

This also ignores the shift if every house in the world did its own recursion. TLD servers and auth servers all over the world would have to massively up their capacity to cope.

With my TLD operator hat, I tend to say it is not a problem, we already have a lot of extra capacity, to handle dDoS.

As long as ISPs don't actually disallow running of recursive servers

That would be a terrible violation of network neutrality. I hope that such ISP will go bankrupt.

On Tue, Apr 03, 2018 at 03:01:19AM -0700, Brian Kantor <Brian@ampr.org> wrote a message of 12 lines which said:

...

That would be a terrible violation of network neutrality. I hope that such ISP will go bankrupt.

On the contrary: it will enable them to collect more usage statistics and from that sell more directed advertising. They will make MORE money off doing so. And so they will.

Then, I'm going to stop reading NANOG and go to the movie instead. Because, in the movies, the bad guys lose.

...

This also ignores the shift if every house in the world did its own recursion. TLD servers and auth servers all over the world would have to massively up their capacity to cope.

With my TLD operator hat, I tend to say it is not a problem, we already have a lot of extra capacity, to handle dDoS.

...

As long as ISPs don't actually disallow running of recursive servers

That would be a terrible violation of network neutrality. I hope that such ISP will go bankrupt.

With my ISP hat on: I see no problem with this as long as the resolver is not open to the Internet. There are unfortunately plenty of home user equipment with an open DNS proxy (probably also some resolvers). This *will* be misused. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Tue, Apr 03, 2018 at 08:21:02AM -0600, Paul Ebersman wrote:

In the pipe dream category, it would be great to think that as IoT becomes unavoidable, we'll get more boxes that do auto-update.

Watch what you wish for: you might get it. The number of attack/abuse vectors (and the severity of their consequences for security and privacy) involved in doing auto-update may rival those involved in not doing auto-update. ---rsk

ebersman> In the pipe dream category, it would be great to think that as ebersman> IoT becomes unavoidable, we'll get more boxes that do ebersman> auto-update. rsk> Watch what you wish for: you might get it. The number of rsk> attack/abuse vectors (and the severity of their consequences for rsk> security and privacy) involved in doing auto-update may rival those rsk> involved in not doing auto-update. I used to hate auto-update but after doing some large scale consumer work, less than I used to. It's all "pick your poison". As Stephane points out too, all sorts of issues patching vs not patching. I'm thinking the "let's go to the movies" idea is looking better all the time...