- Test - lists.nanog.org

Re: New DNS Service
by Rod Beck 03 Apr '18

03 Apr '18

And any consensus regarding the service? My layman question is how does this provide privacy? The routers still need to know the IP address of the far end point. I would assume that it would be easy to deduce the domain name from the IP address. - R. ________________________________ From: Andy Ringsmuth <andy(a)andyring.com> Sent: Tuesday, April 3, 2018 4:03 PM To: Rod Beck Cc: nanog(a)nanog.org Subject: Re: New DNS Service > On Apr 3, 2018, at 8:55 AM, Rod Beck <rod.beck(a)unitedcablecompany.com> wrote: > > https://techxplore.com/news/2018-04-dns-privacy.html [https://3c1703fe8d.site.internapcdn.net/newman/gfx/news/hires/2018/dnsservi…]<https://techxplore.com/news/2018-04-dns-privacy.html> DNS service announced, puts privacy first<https://techxplore.com/news/2018-04-dns-privacy.html> techxplore.com A new service that is offering privacy protection when you browse the web was announced Sunday. The security company Cloudflare is delivering a consumer DNS service called 1.1.1.1. > > > Not associated with Cloudflare in any way. > > > Regards, > > > Roderick. > Mildly interesting but very much old news. The new Cloudflare DNS has been discussed extensively right here on NANOG for the last few days. -Andy

4 3

Yet another Quadruple DNS?
by Payam Poursaied 03 Apr '18

03 Apr '18

dig google.com @1.1.1.1 Cloudflare? Didn't find any news around it

44 88

New DNS Service
by Rod Beck 03 Apr '18

03 Apr '18

https://techxplore.com/news/2018-04-dns-privacy.html Not associated with Cloudflare in any way. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

2 1

From Nov 2017...
by Robert Mathews (OSIA) 03 Apr '18

03 Apr '18

To be clear..... *DNS resolver 9.9.9.9 will check requests against IBM threat database* *Group Co-founded by City of London Police promises 'no snooping on your requests'* By Richard Chirgwin 20 Nov 2017 at 06:58 The Register (UK) <https://forums.theregister.co.uk/forum/1/2017/11/20/quad9_secure_private_dn…>https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/

5 10

whoami.akamai.net and public DNS node replies
by Anurag Bhatia 02 Apr '18

02 Apr '18

Hello everyone, Anyone using whoami.akamai.net? I have used it quite a while especially with large anycast players because they tend to have customer facing (anycast) IPs and internet facing unicast IPs to reach to outside world. Thus for say 8.8.8.8 while query may be local to my country (India), I saw that Google was using unicast IP from their Singapore location (as per IPs published here <https://developers.google.com/speed/public-dns/faq> in their FAQ). dig @8.8.8.8 whoami.akamai.net used to give that IP. >From last few weeks, I see results are pretty inconsistent and just makes no sense whatsoever. E.g 5 consecutive queries to 8.8.8.8 asking whoami.akamai.net where Akamai should return me IP of recursor from where query came: dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 14.139.241.214 dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 This does not make sense since none of those unicast IPs belongs to Google. I see similar result for any other open DNS service like Cisco's OpenDNS: dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.146 dig @208.67.222.222 whoami.akamai.net a +short 103.252.111.156 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 Is anyone aware of any issues in the way whoami.akamai.net works? dig +trace whoami.akamai.net gives me back my unicast IP which is logical considering fact that +trace tends to use local DNS recursor within the machine. This gives an impression that probably TTL is too high and recursors are caching reply which they are not supposed to. But at the same time, I do not see the logic of getting non-Google IPs when querying via 8.8.8.8. ;; QUESTION SECTION: ;whoami.akamai.net. IN A ;; ANSWER SECTION: whoami.akamai.net. 180 IN A 103.252.111.173 I think in past TTL used to be very low to avoid caching for it. Anyone with ideas on what's going on? -- Anurag Bhatia anuragbhatia.com

2 1

Network Info Anonymizer
by Spencer Fraint 02 Apr '18

02 Apr '18

Sharing network configuration files (e.g. to get help debugging) can be quite tricky because they contain sensitive information. At the same time, simply removing the sensitive information (e.g. removing or changing all IP addresses) removes important structure from the files, defeating the purpose of sharing. We created Netconan to help. Netconan is an open source Python tool that anonymizes sensitive network information from text files, while preserving important structure. For example: it can take in router configuration files and remove passwords and anonymize IP addresses, while preserving IP address relationships (prefixes/subnets that matched before anonymization will still match after anonymization). Check it out on PyPI (https://pypi.python.org/pypi/netconan/) or GitHub ( https://github.com/intentionet/netconan) and let us know what you think! Thanks, Spencer

1 0

IPv6 addressing plan spreadsheet issue
by Job Snijders 02 Apr '18

02 Apr '18

Hi all, I made a list of the IPv6 addresses in my home LAN, but have trouble copy+pasting the list into a cloud spreadsheet. My address list is here: http://pete.meerval.net/~job/ How do other folks do this? Just administrate things in text files? Kind regards, Job

10 10

ARIN 41 - potential changes to Number Resource Policy (Fwd: [arin-announce] Participate in the Public Policy Process at ARIN 41)
by John Curran 02 Apr '18

02 Apr '18

NANOGers - ARIN operates the number registry according to community-developed policies, but ultimately such policies are shaped by the folks in this community who choose to participate in their development. There are several significant policy proposals that will be considered at ARIN 41, and I’d recommend taking a moment to review them and either comment on our public policy mail list (arin-ppml(a)arin.net<mailto:arin-ppml@arin.net>) or participate in the upcoming meeting (onsite in Miami or remotely, as one prefers) Please see the attached email summarizing potential changes to number resource policy that will be discussed at ARIN 41 two weeks from today. Thanks! /John John Curran President and CEO American Registry for Internet Numbers (ARIN) Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] Participate in the Public Policy Process at ARIN 41 Date: 2 April 2018 at 9:17:06 AM EDT To: <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> We hope you’ve heard about the upcoming ARIN 41 Public Policy and Members Meeting, taking place 15-18 April in Miami, and that you are planning to participate in this important policy discussion forum. These policies can have a direct impact on your business, so you will undoubtedly want to share your thoughts and contribute to the discussion! The policy discussions at ARIN 41 will include: -Recommended Draft Policy ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation -Recommended Draft Policy ARIN-2017-8: Amend Community Networks -Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers -Recommended Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) -Recommended Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment -Recommended Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations -Draft Policy ARIN-2018-1: Allows Inter-regional ASN Transfers -Draft Policy ARIN-2018-2: Clarification to ISP Initial Allocation and Permit Renumbering All draft policy text is available at: https://www.arin.net/policy/proposals/ You won’t want to miss other agenda highlights like updates on software development, the ARIN fee schedule, and data privacy, plus the latest news from the other RIRs. We will also provide an update on the website redesign project that is currently underway and review the results of our most recent customer satisfaction survey. The full ARIN 41 agenda is available at: https://www.arin.net/ARIN41_agenda We hope to see you in Miami, but if you are unable to make it in person, participating online can be equally rewarding. As a registered remote participant, you'll be able to access the live transcript and webcast on the ARIN website throughout the meeting, submit questions and comments alongside in-person attendees, and raise your virtual hand during straw polls. The webcast and live transcript are available to anyone, but if you want to join in the meeting chat room and add your voice to the discussion and participate in straw polls, you must register at: https://www.arin.net/ARIN41_remote Select "Register” and choose “Remote Participant” as your registration type. We are using Slack for ARIN 41 and all remote participants will be sent an invitation to create an account to access the meeting chat. We strongly encourage you to log in to Slack to test this functionality before the meeting begins so that you can participate fully when the meeting starts. Please note that all times listed on the agenda are Eastern Time. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP) found at: https://www.arin.net/participate/meetings/remote_aup.html Whether you attend in person or remotely, we look forward to your participation! Please contact us at meetings(a)arin.net if you have any questions. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN)

1 0

Re: Yet another Quadruple DNS?
by Willy MANGA 31 Mar '18

31 Mar '18

Hi, Le 30/03/2018 à 13:00, nanog-request(a)nanog.org a écrit : > >Date: Thu, 29 Mar 2018 09:13:06 -0400 >From: Doug Clements <dclements(a)gmail.com> > >>From https://1.1.1.1/: >For IPv6: *2001:2001::* and/or *2001:2001:2001::* No, it's 1dot1dot1dot1.cloudflare-dns.com (2606:4700:4700::1001 and 2606:4700:4700::1111 ) -- Willy Manga @ongolaboy https://ongola.blogspot.com/

1 0

Comcast engineer assistance
by Derrick Malilay 30 Mar '18

30 Mar '18

Can a Comcast engineer please contact me off-list. derrix(a)gmail.com We are seeing some unusual behavior with one prefix that looks like it's stopping in the Comcast network. Thanks! Derrick

1 0