Re: Charter DNS servers returning malware filtered IP addresses
* Owen DeLong [Sat 28 Oct 2023, 01:00 CEST]: If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so? It's generally a service that's offered for money. Quad9 definitely offer it: https://www.quad9.net/service/threat-blocking DNS isn’t the right place to attack this, IMHO. Why not (apart from a purity argument), and where should it happen instead? As others pointed out, network operators have a vested interest in protecting their customers from becoming victims to malware. -- Niels.
Re: ARIN email address (was cogent spamming directly from ARIN records?)
* morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 21:50 CEST]: I'm sure telling dave shaeffer: "Hey, your sales droids are being rude" is going to end as well as sending him ED pill emails. Such outreach to technical contacts is counterproductive anyway. Which is more likely, that noc@ leads to a person with purchasing power, or that it leads to one who happens to be rabidly anti-spam who may then help get you thrown off the PeeringDB island for a few seasons? -- Niels.
Re: ARIN email address (was cogent spamming directly from ARIN records?)
* morrowc.li...@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 18:29 CEST]: this sort of thing (provider X scrapes Y and mails Z for sales leads) every ~18 months. the same outrage and conversation happens every time. the same protection mechanisms are noted every time. Is there a reason that: "killfileand move on" is not the answer everytime for this? (why do we need to keep rediscussing it) It's a vicious circle: provider scrapes operational addresses and spams them, providers stop putting useful addresses in public databases to avoid spam, everybody who needs to find operational contacts in a variety of situations loses in the end. We keep discussing it because we care about keeping the internet running. It's similar to why we keep looking for new security holes in existing software: we don't stop because inevitably we'll find more so it's a lost cause, we keep looking because inevitably we'll find more so the product becomes more secure. -- Niels.
Re: New addresses for b.root-servers.net
* nanog@nanog.org (Cynthia Revström via NANOG) [Sun 18 Jun 2023, 20:52 CEST]: Naturally C root is fine on HE over IPv4, the issue is with IPv6. 2001:500:2::c is not reachable over HE. You're absolutely correct. Maybe their LG defaulting to IPv6 made my brain short-circuit. (Their looking glass took longer to render that than its own cache timeout.) -- Niels.
Re: New addresses for b.root-servers.net
* na...@as397444.net (Matt Corallo) [Sun 18 Jun 2023, 19:12 CEST]: If its not useful, please describe a mechanism by which an average recursive resolver can be protected against someone hijacking C root on Hurricane Electric (which doesn't otherwise have the announcement at all, last I heard) and responding with bogus data? No comment on DNSSEC but lg.he.net indicates that they do in fact carry a route to C-root: --- 1 76 ms * * port-channel2.core2.pao1.he.net (72.52.92.65) 2 44 ms 63 ms 78 ms palo-b24-link.ip.twelve99.net (195.12.255.209) 3 55 ms 66 ms 103 ms cogent-ic-344188.ip.twelve99-cust.net (62.115.174.65) 4 74 ms 57 ms 120 ms be2431.ccr41.sjc03.atlas.cogentco.com (154.54.88.189) 5 142 ms 99 ms 79 ms be3142.ccr21.sjc01.atlas.cogentco.com (154.54.1.193) 6 53 ms 75 ms 111 ms be3176.ccr41.lax01.atlas.cogentco.com (154.54.31.189) 7 82 ms 133 ms 85 ms te0-0-2-0.c-root.lax01.atlas.cogentco.com (154.54.27.138) 8 60 ms 152 ms 84 ms c.root-servers.net (192.33.4.12) Entry cached for another 60 seconds. 2023-06-18 17:57:17 UTC --- I don't see any ROAs for AS2149's two originated prefixes, though: https://irrexplorer.nlnog.net/prefix/192.33.4.0/24 so hijacks might still be easier than they could be. Regards -- Niels.
Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)
* g...@toad.com (John Gilmore) [Sat 17 Sep 2022, 04:14 CEST]: Now that markets exist for IP addresses, all that IP addresses need is a deed-registry to discourage fraud, like a county real-estate registrar's office. Are IP addresses like houses, though? Aren't they more like other intellectual property such as trademarks or patents? What happens to those when you don't pay the USPTO? -- Niels.
Re: FYI - 2FA to be come mandatory for ARIN Online?
* nanog@nanog.org (Laura Smith via NANOG) [Tue 24 May 2022, 22:22 CEST]: Its 2022. Do we really still need a consultation on why mandatory 2FA is a good thing ? Even more so for something like ARIN ? To many of us in 2022 it's clear that SMS 2FA isn't necessarily a good way to protect critical infrastructure, but apparently ARIN does need a consultation for that -- Niels.
Re: DNS pulling BGP routes?
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Sun 17 Oct 2021, 11:17 CEST]: Jay Hennigan wrote: Neutral backbone providers don't peer with access/retail ISPs. They sell transit to them. FYI, that is called paid peering. Can you please please please stop posting nonsense? -- Niels.
Re: DNS pulling BGP routes?
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Sat 16 Oct 2021, 15:50 CEST]: Access/retail ISPs have no problem by peering with neutral backbone providers. Getting strong Marie-Antoinette vibes here. -- Niels.
Re: public open resolver list?
$ whois AS16589 No match found for a 16589. * li...@benappy.com (Michel 'ic' Luczak) [Tue 02 Feb 2021, 14:48 CET]: whois -r AS16589 # perhaps? aut-num:AS16589 as-name:ELV-ANYCAST-NET You skipped the most important line: source: RIPE-NONAUTH In other words, this object dates back to the times when anybody could throw almost anything into RIPE's IRRdb. In other words, it's not authoritative and its presence doesn't mean anything. It's probably legit, the data is old but somewhat consistent. Comodo should probably try to clean up the RIR administration surrounding this ASN, though. -- Niels.
Re: Parler
* n...@foobar.org (Nick Hilliard) [Mon 11 Jan 2021, 13:56 CET]: Eric S. Raymond wrote on 11/01/2021 00:00: Yes, it would. This was an astonnishingly stupid move on AWS's part; I'm prett sure their counsel was not conmsulted. this is quite an innovative level of speculation. Care to provide sources? Of course he hasn't. And Amazon's response filing clearly demonstrates that he was talking out of his ass. -- Niels.
Re: Parler
* iz...@setec.org (Izaac) [Mon 11 Jan 2021, 00:22 CET]: Got links? Your message arrived like five times here but I did the google for you: https://www.buzzfeednews.com/article/johnpaczkowski/amazon-parler-aws | On Parler, reaction to the impending ban was swift and outraged, with | some discussing violence against Amazon. "It would be a pity if someone | with explosives training were to pay a visit to some AWS data | centers," one person wrote. -- Niels.
Re: Parler
* w...@typo.org (Wayne Bouchard) [Sun 10 Jan 2021, 16:40 CET]: On Sun, Jan 10, 2021 at 04:32:29PM +0100, niels=na...@bakker.net wrote: * sro...@ronan-online.com (sro...@ronan-online.com) [Sun 10 Jan 2021, 14:46 CET]: While Amazon is absolutely within their rights to suspend anyone they want for violation of their TOS, it does create an interesting problem. Amazon is now in the content moderation business, which could potentially open them up to liability if they fail to suspend any other customer who hosts objectionable content. Didn't that ship sail when they booted WikiLeaks off their platform? Yeah, pretty much. See, the real issue here is AUPs which initially were used to make sure users knew that their services could not be used to facilitate illegal things and then used to keep order on the platforms by restricting abusive behavior. However the definition of "abusive" has now been extended so greatly and with constantly changing rules that it's making the statement, effectively, "if we don't like what you say, or if we don't like you or your business, sucks to be you." It's amazing how far the world has stumbled that "fomenting violent insurrection and calling for the murder of elected officials" now falls under standard T against abusive behaviour where this used to be perfectly fine a year ago. (That was sarcasm.) -- Niels.
Re: Parler
* sro...@ronan-online.com (sro...@ronan-online.com) [Sun 10 Jan 2021, 14:46 CET]: While Amazon is absolutely within their rights to suspend anyone they want for violation of their TOS, it does create an interesting problem. Amazon is now in the content moderation business, which could potentially open them up to liability if they fail to suspend any other customer who hosts objectionable content. Didn't that ship sail when they booted WikiLeaks off their platform? -- Niels.
Re: nike.com->nike.com/ca
* bdant...@medline.com (Dantzig, Brian) [Thu 07 Jan 2021, 18:07 CET]: When you send a DNS query to 8.8.8.8 it goes to the “nearest” resolver. Not nearest in terms of location since 8.8.8.8 is an anycast address and exists in many locations. It’s the BGP path to 8.8.8.8 that determines nearest. Next, the resolver does it’s thing and sends a query to the akamai DNS. That DNS is probably also an anycast address so again, how close is it? Akamai then tries to geo locate you but they have the IP of Google, not you. You get an IP and connect to that. Everything up till now probably doesn’t matter as it’s probably not the DNS that is causing what you see. The IP is not Nike but rather an akamai proxy. When you connect to akamai proxy, the proxy can see your IP and may do the Geo location lookup and pass what it thinks as your location to the content server. When it gets to the content server, it may use that Geo information but possibly not. It’s likely it’s not the content server but a load balancer. In either case, they may ignore any Geo lookup done by akamai and try to locate the incoming IP. Well, that’s actually the address of the akamai proxy. Hopefully the developers thought of this and had akamai pass your IP in a header and geo locate on that. It’s probably the content server that is sending an HTTP redirect to get you to the “/ca” location on the site. I checked off list with Becki Kain and Akamai's geolocation is not placing her in Canada. I can't speculate as to what company Nike would be using for its decision to redirect to /ca on its website. -- Niels.
Re: Mystery CDN
* clin...@scripty.com (Clinton Work) [Wed 17 Jun 2020, 17:31 CEST]: I'm struggling to determine which CDN owns the servers in CenturyLink prefix 8.240.0.0/12. During the Call of Duty Season 4 update on June 11th from 06:00 UTC until 08:30 UTC, we had 240 Gbps of traffic steaming into our network from CenturyLink prefix 8.240.0.0/12. We originally thought it was Akamai, but they swear up and down that the servers don't belong to them. Akamai: % curl -sv http://95.100.96.208/ |& fgrep Server: < Server: AkamaiGHost Here are some of the HTTP/HTTPS servers in 8.240.0.0/12: 8.253.151.248 8.251.135.126 8.240.167.126 8.240.228.126 8.240.168.126 8.240.126.254 8.240.191.254 Not Akamai: % curl -sv http://8.240.191.254/ |& fgrep Server: < Server: FP6.1.1866.55 Have you tried a Shodan search for this fingerprint? HTH, -- Niels.
Re: RIPE NCC Executive Board election
* e...@netstyle.io (Elad Cohen) [Wed 13 May 2020, 15:46 CEST]: Ronald was called an antisemitic and a racist person here on Nanog in the following two links, by people which are not related to me: https://imgur.com/AQCmZlk Since you're quoting me here, let me reiterate that I was out of line in that posting, as I posted to the mailing list at the time as well. -- Niels.
Re: Hurricane Electric dead on NYIIX?
* fohdee...@gmail.com (Jon Sands) [Thu 05 Mar 2020, 23:50 CET]: Not sure when it happened, but our BGP session to HE via NYIIX is dead, can't even ping them anymore. Can hit all our other NYIIX peers without issue Did your email client accidentally autocomplete 'n...@he.net' (quite responsive people) to 'nanog@nanog.org' (a mailing list with thousands of curmudgeon subscribers)? -- Niels.
Re: Elad Cohen (was: Re: Cogent sales reps who actually respond)
* r...@tristatelogic.com (Ronald F. Guilmette) [Fri 20 Sep 2019, 00:50 CEST]: Leaving aside the minor quibble that "Dutch" is not, as far as I am aware, a "race" per se, I do apologize for having improperly and quite wrongly generalized the apparent confluence of of certain events and actions to the Dutch people generally. That was entirely incorrect and improper on my part and I do sincerly apologize. Apologies on my end as well, Ronald. I should not have said racist; bigoted would have been a more apt description of your earlier screed. Again, I do apologise, I was clearly in the wrong here. ... it's difficult for me not to infer a possible pattern. Yep. Sure. -- Niels.
Re: Elad Cohen (was: Re: Cogent sales reps who actually respond)
* r...@tristatelogic.com (Ronald F. Guilmette) [Thu 19 Sep 2019, 10:05 CEST]: I never like to generalize to entire populations, and I will therefore refrain from suggesting any endemic or widespread defect in the Dutch national psyche, but I cannot help but note that, as pointed out in the MyBroadband.co.za news report, a gentleman named Maikel Uerlings, who is also Dutch, and who presently appears to be notably absent from the Netherlands, perhaps due to certain less-than-friendly legal entanglements, is also, it appears, intimately connected to Mr. Cohen and to his business, such as it is. It would be entirely improper for me to say or even to suggest that the Dutch are any more inclined toward cybercrime, or toward looking the other way while it takes place, than anyone else. I will instead only paraphrase William Shakespeare and say that there is something rotten in the Netherlands, and that whatever it is, it ain't doing their national reputation any good at all. Couching your racism in some faux plausible deniability by using phrases such as "It would be entirely improper of me to" or "I will refrain from [making a certain racist suggestion]" and then immediately making that racist suggestion, doesn't make your remarks not racist. Nor can you hide behind the classics. Racism has no place in this community and you would do well to refrain from posting any more such remarks. -- Niels.
Re: IPAM recommendations
* m...@beckman.org (Mel Beckman) [Thu 05 Sep 2019, 14:17 CEST]: I don’t think this is a reasonable understanding of Nanog. Nanog members ask each other for operational tool recommendations all the time, and since these products are right up the alley of Nanog’s mission — network operations — it’s a perfectly reasonable use of Nanog. Did you read Todd's email at all? He asked the poster to do more homework before bothering the mailing list membership, an entirely reasonable request, especially given their recent posting history of similarly worded questions with lack of background supplied. But you read a single comment without researching any Nanog history, This is laughably wrong. Todd is a long-time NANOG attendee and has even served on its Program Committee. (Pot, kettle, black.) -- Niels.
Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland)
Apologies, it was in reply to a list mail. Just bad threading. * niels=na...@bakker.net (niels=na...@bakker.net) [Tue 19 Mar 2019, 16:51 CET]: Kind of bad netiquette to repost a private email to the list
Re: Contacts wanted: OVH, DigitalOcean, and Microsoft (Deutschland)
Kind of bad netiquette to repost a private email to the list -- Niels.
Re: BGP Experiment
Hi Saku, After seeing this initial result I'm wondering why the researchers couldn't set up their own sandbox first before breaking code on the internet. I believe FRR is a free download and comes with GNU autoconf. We probably should avoid anything which might demotivate future good guys from finding breaking bugs and reporting them, while sending perfectly standard-compliant messages. Only ones who will win are bad guys who collect libraries of how-to-break-internet. There are certainly several transit packet of deaths and BGP parser bugs in each implementation, I'd rather have good guy trigger them and give me details why my network broke, than have bad guy store them for future use. I fully agree with you. However, this doesn't give 'good guys' carte blanche to break stuff. I'm glad they've already taken action to improve their practices as confirmed by Italo Cunha in his earlier mail. -- Niels.
Re: BGP Experiment
* valdis.kletni...@vt.edu (valdis.kletni...@vt.edu) [Tue 08 Jan 2019, 18:06 CET]: (Personally, I'd never heard of FRR before) Martin Winter of OSR/FRR has attended many a NANOG, RIPE and other industry meetings, so it's not for their lack of trying -- Niels.
Re: BGP Experiment
* thomasam...@gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]: There are a fair number of open source BGP implementations now. It would require additional effort to test all of them. In the real world, doing the correct thing is often harder than doing an incorrect thing, yes. -- Niels.
Re: BGP Experiment
* cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]: [A] https://goo.gl/nJhmx1 For the archives, since goo.gl will cease to exist soon, this links to https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview After seeing this initial result I'm wondering why the researchers couldn't set up their own sandbox first before breaking code on the internet. I believe FRR is a free download and comes with GNU autoconf. -- Niels.
Re: CloudFlare D.N.S. Resolvers... (1.1.1.1 & 1.0.0.1)
* na...@ics-il.net (Mike Hammett) [Wed 26 Sep 2018, 13:14 CEST]: I recommend that eyeball networks don't run any external recursive server for optimal CDN performance. Yes, some CDNs support other methods, but not all. If not all do, then the requirement remains. +1 https://blog.powerdns.com/2018/09/04/on-firefox-moving-dns-to-a-third-party/ -- Niels.
Re: FWIW... Re: TEST Help? TEST
* sur...@mauigateway.com (Scott Weeks) [Wed 13 Jun 2018, 02:17 CEST]: Turns out that it's only the "Re: IPv6 faster/better proof?" thread I can't reply to. I still can't. All I wanted to say was: Then perhaps that thread was killed by the moderators. Please heed the list charter. Also, please get a mail client that generates proper In-Reply-To headers and knows how to quote... it's 2018. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com
Re: ICANN GDPR lawsuit
* l...@satchell.net (Stephen Satchell) [Fri 01 Jun 2018, 14:51 CEST]: How does your shop, Niels, go about making contact with an operator that is hijacking one of your netblocks, or is doing something weird with routing that is causing your customers problems, or has broken BGP? The same as we do now, by posting on NANOG "Can someone from ASx / largetelco.com contact me offlist?" -- Niels.
Re: ICANN GDPR lawsuit
* h...@efes.iucc.ac.il (Hank Nussbacher) [Fri 01 Jun 2018, 06:56 CEST]: The entire whois debacle will only get resolved when some hackers attack www.eugdpr.org, ec.europa.eu and some other key .eu sites. When the response they get will be "sorry, we can't determine who is attacking you since that contravenes GDPR", will the EU light bulb go on that something in GDPR needs to be tweaked. Please stop inciting lawbreaking, and stop spreading long debunked talking points. Both are really inappropriate for this list. -- Niels.
Re: Whois vs GDPR, latest news
* l...@satchell.net (Stephen Satchell) [Sun 27 May 2018, 23:17 CEST]: On 05/27/2018 12:54 PM, niels=na...@bakker.net wrote: You have this the wrong way around. You'll need permission to store their IP address in logs that you keep and to inform third parties about their visits to your site. And that is because that information belongs to the visitor, not to you. This is going to run afoul of some data retention laws currently on the books in some places. You *have* to keep logs, WITH IP addresses... Owen doesn't. -- Niels.
Re: Whois vs GDPR, latest news
* o...@delong.com (Owen DeLong) [Sun 27 May 2018, 21:42 CEST]: The way GDPR is written, if you want to collect (and store) so much as the IP address of the potential customer who visited your website, you need their informed consent and you can’t require that they consent as a condition of providing service. You have this the wrong way around. You'll need permission to store their IP address in logs that you keep and to inform third parties about their visits to your site. And that is because that information belongs to the visitor, not to you. Basically, the regulation is so poorly written that it is utterly nonsensical and I wonder how business in Europe intend to function when they can’t make collecting someone’s address a condition of allowing them to order something online. Basically, this example is so bad that it's not even wrong. -- Niels.
Re: EVERYTHING about Booters (and CloudFlare)
* goe...@sasami.anime.net (Dan Hollis) [Wed 27 Jul 2016, 20:21 CEST]: On Wed, 27 Jul 2016, b...@theworld.com wrote: There isn't even general agreement on whether (or what!) Cloudfare is doing is a problem. aiding and abetting. at the very least willful negligence. I hope the armchairs y'all are lawyering from are comfortable -- Niels.
Re: AS4788 Telecom Malaysia major route leak?
* milln...@gmail.com (Martin Millnert) [Fri 12 Jun 2015, 12:54 CEST]: Also, possible explanation for why nobody's fixing it: https://twitter.com/TMCorp/status/609167065300271104 :) https://scontent-sea1-1.xx.fbcdn.net/hphotos-xat1/t31.0-8/10914977_10152809997716851_748171875526832420_o.jpg Is that tweet for real? How is that company (not TM) still in business? -- Niels.
