September 2016 - Test - lists.nanog.org

QWEST.NET can you fix your nameservers
by Mark Andrews 16 Sep '16

16 Sep '16

In case anyone is wondering why I've been harping on about EDNS compliance this is why. Failure to follow the protocol can result in DNS lookup failures. nara.gov is signed and the recursive server performs DNSSEC validation and sends queries with DNS COOKIEs. BADVERS is NOT a valid response to a EDNS version 0 query. Can you please contact your DNS vendor for a fix. QWEST isn't the only DNS provider that has broken nameservers. One shouldn't have to try and contact every DNS operator to get them to use protocol compliant servers. Mark ;; BADCOOKIE, retrying. ; <<>> DiG 9.11.0rc1 <<>> nara.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5744 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 85faf1e39a1a6a149bebd00a57da4b266b8546c1b75015db (good) ;; QUESTION SECTION: ;nara.gov. IN A ;; Query time: 5000 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Sep 15 17:17:58 EST 2016 ;; MSG SIZE rcvd: 65 Checking: 'nara.gov' as at 2016-09-15T07:16:32Z nara.gov @63.150.72.5 (sauthns1.qwest.net.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok edns@512tcp=ok optlist=badvers,nosoa nara.gov @2001:428::7 (sauthns1.qwest.net.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok edns@512tcp=ok optlist=badvers,nosoa nara.gov @208.44.130.121 (sauthns2.qwest.net.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok edns@512tcp=ok optlist=badvers,nosoa nara.gov @2001:428::8 (sauthns2.qwest.net.) dns=ok edns=ok edns1=ok edns@512=ok ednsopt=badvers,nosoa edns1opt=ok do=nodo ednsflags=ok edns@512tcp=ok optlist=badvers,nosoa The Following Tests Failed EDNS - Unknown Option Handling (ednsopt) dig +nocookie +norec +noad +ednsopt=100 soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: that the option will not be present in response See RFC6891, 6.1.2 Wire Format EDNS - DO=1 (do) dig +nocookie +norec +noad +dnssec soa zone @server expect: SOA expect: NOERROR expect: OPT record with version set to 0 expect: DO flag in response if RRSIG is present in response See RFC3225 EDNS - Supported Options Probe (optlist) dig +edns +noad +norec +nsid +subnet=0.0.0.0/0 +expire +cookie -q zone @server expect: NOERROR expect: OPT record with version set to 0 See RFC6891 Codes ok - test passed. nodo - EDNS DO flag not echoed. nosoa - SOA record not found when expected. badvers - BADVERS returned. To retrieve this report in the future: https://ednscomp.isc.org/ednscomp/25f2ebe619 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

6 12

Lawsuits for falsyfying DNS responses ?
by Jean-Francois Mezei 15 Sep '16

15 Sep '16

As many may know, the province of Québec has passed a law to protect the interests of its lottery corporation. To do so, it will provide ISPs with list of web sites to block (aka: only allow its own gambing web site). There is an opportunity to comment this week in which I will submit. (I've gathered many arguments over the past little while already). But have a specific question today: Are there examples of an ISP getting sued because it redirected traffic that should have gone to original site ? For instance, user asks for www.google.com and ISP's DNS responds with an IP that points to a bing server? If the risk of a lawsuit is real, then it brings new dimension to arguments already made agains that (stupiod) Québec law. (And it also creates interesting issues for DNS servers from companies such as Google which may have a anycast server located in Québec but are not considered an ISP and won't receive those documenst from the gov with list of websites to block.

11 13

Re: ___Your___$ __l O O O Walmart___GiftCard
by Aaron C. de Bruyn 15 Sep '16

15 Sep '16

That's interesting. heyaaron.com is one big huge catch-all that funnels into my Google Apps for Domains mailbox. There's one account, it has a good password, and it's protected by a Ubikey. I'd be interested in seeing a copy of the headers from that e-mail. -A On Thu, Sep 15, 2016 at 3:15 PM, Brian majors <majors200(a)gmail.com> wrote: > I am reporting you to the Fed scammer > > On Sep 15, 2016 6:10 PM, "__WLM__" <textayaro(a)heyaaron.com> wrote: > > > > Congarts____This__is Your____$ l O O O ____GiftCard >

1 0

Can someone from Amazon please answer.
by Mark Andrews 14 Sep '16

14 Sep '16

I'm curious. What are you trying to achieve by blocking EDNS version negotiation? Is it really too hard to return BADVERS to a EDNS query with version != 0 along with the version of EDNS you support in the version field? Are you deliberately trying to prevent the IETF from deciding to bump the EDNS version in the future? Do you have firewalls that have this behaviour hard coded? Do you even test for RFC compliance? Mark lostoncampus.com.au. @205.251.195.156 (ns-924.awsdns-51.net.) dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok lostoncampus.com.au. @205.251.192.78 (ns-78.awsdns-09.com.) dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok lostoncampus.com.au. @205.251.196.198 (ns-1222.awsdns-24.org.) dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok lostoncampus.com.au. @205.251.199.20 (ns-1812.awsdns-34.co.uk.): dns=ok edns=ok edns1=timeout edns@512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=ok optlist=ok,nsid,subnet signed=ok ednstcp=ok -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

5 8

PCH peering survey 2016
by Bill Woodcock 14 Sep '16

14 Sep '16

Background: Five years ago PCH conducted the first, and to date only, comprehensive survey characterizing Internet peering agreements. The document that resulted can be found here: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011… <https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2011…> That document was one of the principal inputs to an important document that the OECD publishes every five years, one that recommends communications regulatory policy to OECD member nations: http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/I… <http://www.oecd.org/officialdocuments/publicdisplaydocumentpdf/?cote=DSTI/I…> The survey had several useful findings which hadn’t previously been established as fact—most notably the portion of peering relationships that are “handshake” agreements, without written contract. These findings have improved the regulatory environments in which many of us operate our networks. At the time of the 2011 survey, we committed to repeating the survey every five years, so as to provide an ongoing indication of the direction peering trends take. It’s now five years later, so we’re repeating the survey. The survey is global in scope, and our goal is to reflect the diversity of peering agreements in the world; we’re interested in large ISPs and small ISPs, ISPs in Afghanistan and in Zimbabwe, bilateral agreements and multilateral, private and public. Our intent is to be as comprehensive as possible. In 2011, the responses we received represented 86% of all of the world’s ISPs and 96 countries. We would like to be at least as inclusive this time. Privacy: In 2011, we promised to collect the smallest set of data necessary to answer the questions, to perform the analysis immediately, and not to retain the data after the analysis was accomplished. In that way, we ensured that the privacy of respondents was fully protected. We did as we said, no data was leaked, and the whole community benefited from the trust that was extended to us. We ask for your trust again now as we make the same commitment to protect the privacy of all respondents, using the same process as last time. We are asking for no more data than is absolutely necessary. We will perform the analysis immediately upon receiving all of the data. We will delete the data once the analysis has been performed. The Survey: We would like to know the following five pieces of information relative to each Autonomous System you peer with: • Your ASN • Your peer’s ASN (peers only, not upstream transit providers or downstream customers) • Whether a written and signed peering agreement exists (the alternative being a less formal arrangement, such as a "handshake agreement") • Whether the terms are roughly symmetric (the alternative being that they describe an agreement with different terms for each of the two parties, such as one compensating the other, or one receiving more or fewer than full customer routes) • Whether a jurisdiction of governing law is defined • Whether IPv6 routes are being exchanged (this year, we’ll still assume that IPv4 are) The easiest way for us to receive the information is as a tab-text or CSV file or an Excel spreadsheet, consisting of rows with the following columns: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean Symmetric: Boolean Governing Law: ISO 3166 two-digit country-code, or empty IPv6 Routes: Boolean For instance: 42 <tab> 715 <tab> false <tab> true <tab> us <tab> true <cr> 42 <tab> 3856 <tab> true <tab> true <tab> us <tab> true <cr> We are asking for the ASNs only so we can avoid double-counting a single pair of peers when we hear from both of them, and so that when we hear about a relationship in responses from both peers we can see how closely the two responses match, an important check on the quality of the survey. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published. We will never disclose any ASN or any information about any ASN. We already have more than 8,000 ASN-pair relationships documented, and we hope to receive as many more as possible. We'd like to finish collecting data by the end of September, about two weeks from now. If you’re peering with an MLPA route-server, you’re welcome to include just the route-server’s ASN, if that’s easiest, rather than trying to include each of the peer ASNs on the other side of the route-server. Either way is fine. If all of your sessions have the same characteristics, you can just tell us what those characteristics are once, your own ASN once, and give us a simple list of your peer ASNs. If your number of peers is small enough to be pasted or typed into an email, rather than attached as a file, and that’s simpler, just go ahead and do that. If you have written peering agreements that are covered by non-disclosure agreements, or if your organizational policy precludes disclosing your peers, but you’d still like to participate in the survey, please let us know, and we’ll work with whatever information you’re able to give us and try to ensure that your practices are statistically represented in our results. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Finally, if there are any other questions you’d like to see answered in the future, please let us know so that we can consider addressing them in the 2021 survey. The question about IPv6 routing in this year’s survey is there because quite a few of the 2011 respondents asked us to include it this time. Please respond by replying to this email, before the end of September. Thank you for considering participating. We very much appreciate it, and we look forward to returning the results to the community. -Bill Woodcock Executive Director Packet Clearing House

1 0

Re: "Defensive" BGP hijacking?
by Scott Weeks 14 Sep '16

14 Sep '16

--- Bryan(a)bryanfields.net wrote: From: Bryan Fields <Bryan(a)bryanfields.net> I'm a bit ambivalent about BGP hijacking as a DDOS mitigation strategy. Really there is no authority to say it's wrong. If your peers are cool with it, and their peers are cool with it who's to say it's wrong? --------------------------------------- Pretty much the entire BGP speaking world. scott

1 0

Re: "Defensive" BGP hijacking?
by Scott Weeks 14 Sep '16

14 Sep '16

--- jfmezei_nanog(a)vaxination.ca wrote: From: Jean-Francois Mezei <jfmezei_nanog(a)vaxination.ca> I got to think about this (dangerous thing :-( Ideally, law enforcement should have the smarts and tools to get involved in DDoS and other similar situations and have the power to compell upstream provider(s) to shut service to a suspect. --------------------------------------------------------- Yes, getting law enforcement involved in BGP and network engineering in any way is a dangerous thing. I agree 100%. scott

1 0

Akamai Edgescape query
by Janusz Jezowicz 13 Sep '16

13 Sep '16

Hello, We are doing some network research to various cloud/CDNs and we need to run few tests on Akamai Edgescape. Does anyone has access to run few queries to geo-locate IPs using Edgescape for us? We don't have Akamai contract and it would take us lot of time (and money) to get one just to run few tests. Many thanks for any help! Janusz Jezowicz *Speedchecker Ltd* *email*: janusz(a)speedchecker.xyz *skype*: jezowicz *phone*: +442032863573 *web*: www.speedchecker.xyz The Black Church, St. Mary’s Place, Dublin 7, D07 P4AX, Ireland

2 1

Re: "Defensive" BGP hijacking?
by Scott Weeks 13 Sep '16

13 Sep '16

--- bryant(a)backconnect.com wrote: From: Bryant Townsend <bryant(a)backconnect.com> @ca & Matt - No, we do not plan to ever intentionally perform a non-authorized BGP hijack in the future. -------------------------------------------- Bryant, Who was the upstream provider? scott

3 2

Re: "Defensive" BGP hijacking?
by Scott Weeks 13 Sep '16

13 Sep '16

--- hugo(a)slabnet.com wrote: On Tue 2016-Sep-13 13:32:56 -0700, Scott Weeks <surfer(a)mauigateway.com> wrote: >--- bryant(a)backconnect.com wrote: >From: Bryant Townsend <bryant(a)backconnect.com> >@ca & Matt - No, we do not plan to ever intentionally perform a >non-authorized BGP hijack in the future. >-------------------------------------------- > >Who was the upstream provider? 3223 / VOXILITY https://bgpstream.com/event/54711 ----------------------------------------------- Oops, I just realized that was mentioned earlier. Apologies for the noise. scott

1 0