Re: is it common to proxy register route objects for the purpose of grouping them for use in an as-set
* s...@internet2.edu (Steven Wallace) [Thu 26 Sep 2024, 18:36 CEST]: One of the DDoS mitigation providers we work with creates proxy route objects for its customers’ prefixes. These route objects specify a common origin ASN rather than the actual origin ASN that would be seen in routing tables. Their rationale is to bind the prefixes to a single ASN, allowing the entire set of customer routes to be announced via an as-set. Is this a common approach? I don't think there really are enough DDoS mitigation providers to speak of anything being common in that industry. Any IRRdb worth their salt will have such prefixes removed automatically if the protected entity is worth their salt and created RPKI ROAs for the prefixes in question, of course. Wouldn't route-set be the better way to create a collection of routes..? https://www.ripe.net/publications/docs/ripe-358/#1220 -- Niels.
Re: Any ideas how long gmail cache DNS records ?
* Laura Smith [Tue 13 Aug 2024, 17:39 CEST]: For the benefit of the list, I received a couple of off-list tip-offs to the link that Chrstopher suggested. I was a bit cynical as I assumed the tool would only have effect on Google's external caches (i.e. 8.8.8.8). The form was failing on Captcha on multiple browsers, which only helped to raise my level of unhappiness with Google. After a bit of searching, I found the same form on another Google page and having plugged the details into the form, caches were indeed cleared both internally and externally at Google and gmails started arriving in the right place. For the benefit of the list, was that https://dns.google/cache rather than the previously mentioned https://developers.google.com/speed/public-dns/cache ? --Niels.
Re: eero outage
* war...@kumari.net (Warren Kumari) [Wed 10 Jul 2024, 23:03 CEST]: More seriously, erm, you mean Eero like the wireless devices? Aren't they supposed to be mesh wifi thingies, and so traffic is local? Like, if eero.com / an eero service goes down, well, … ¯\_(ツ)_/¯? From what I can tell from reddit.com/r/amazoneero: existing systems keep running but deploying a new install isn't working. Which is problematic since quite a few ISPs deliver them as their standard WiFi router setup. Reconfiguring after a factory reset isn't possible either, and hasn't been for about a day, per that forum. I suspect I'm missing something hugely obvious here… Neither of us were the target audience for Jared's mail, I suspect. -- Niels.
Re: DNSSEC & WIldcards
* nanog@nanog.org (Dennis Burgess via NANOG) [Fri 15 Mar 2024, 16:26 CET]: So have *.app.linktechs.net that I have been trying to get to work, we have DNSSEC on this, and its failing, but cannot for the life of me understand why. I think it may have something to do with proving it exists as a wildcard, but any DNSSEC experts want to take a stab at it ? There are better mailing lists to ask this question (like dns-operations at dns-oarc.net) but have you checked https://dnsviz.net/d/www.app.linktechs.net/dnssec/ ? -- Niels.
Re: options for whois server
* shan...@more.net (Spurling, Shannon) [Mon 12 Feb 2024, 20:06 CET]: Anyone out there who has to run an whois or rWhois service know of a currently maintained server package or option? https://github.com/irrdnet/irrd4 -- Niels.
Re: Networks ignoring prepends?
* b...@herrin.us (William Herrin) [Tue 23 Jan 2024, 21:02 CET]: On Tue, Jan 23, 2024 at 11:45 AM Owen DeLong via NANOG wrote: The catch to all of that, however, is that he’s not directly peered with 3356 and many AS operators strip communities. And even if I didn't, the problem isn't just one ISP localprefing to prefer distant routes. Centurylink most directly impacts me, but as others have pointed out: many ISPs do the same darn thing. The only workable solution available to me appears to be tripling my presence in the DFZ tables. Why do you buy from ISPs when you don't want to receive traffic via them? Have you tried asking that upstream to interconnect more locally with certain other networks? Why do you buy from ISPs that strip TE communities from your announcements that don't affect them in the first place? Because big operators think it reasonable to localpref distance routes ahead of nearby ones so long as the distant routes arrive from customers. I'll remember that the next time folks complain about the size of the routing table. This one you did to yourselves. BGP, while a distance vector protocol, famously does not take latency into account when making routing decisions. -- Niels.
Re: Networks ignoring prepends?
* nanog@nanog.org (Owen DeLong via NANOG) [Tue 23 Jan 2024, 20:47 CET]: The catch to all of that, however, is that he’s not directly peered with 3356 and many AS operators strip communities. Are there recent statistics on that last assertion? -- Niels.
Re: Networks ignoring prepends?
* b...@herrin.us (William Herrin) [Mon 22 Jan 2024, 15:05 CET]: On Mon, Jan 22, 2024 at 5:24 AM Patrick W. Gilmore wrote: Standard practice is to localpref your customers up, which makes prepends irrelevant. Why would anyone expect different behavior? It gives me, your paying customer, less control over my routing through your network than if I wasn't your paying customer. That seems... backwards. Most sellers of IP transit offer a "treat as peer" BGP community which will flatten your localpref to that of peers rather than a customer. -- Niels.
Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block
* ayc...@avinta.com (Abraham Y. Chen) [Sat 13 Jan 2024, 18:16 CET]: 0) Your sender name is in an unusual format. It becomes just the generic NANOG address as the recipient for me to MSG send to. Your numbered lists are 0-indexed. So clever! Also, your MUA seems to understand Mail-Followup-To, which is nice. Thanks for catching the typo. My understanding is that there is a general desire (human nature) to get a larger netblock than 100.64/10 in CG-NAT. This could be used for either growing market or less dynamic reassignment. The 240/4 can provide additional benefits to So nobody in particular is asking for this. Thanks for confirming. CG-NAT operations such as static addressing that no one has realized possible. So, I am putting the solution on the table. This is a basic process of sharing the new discoveries. Is there anything wrong with the process? On the other hand, if RFC6598 had picked 240/4 instead of 100.64/10 as the netblock, we do not need today's discussions. What's wrong with the process is that you're wasting the time of a lot of people on this mailing list with this crusade that has already veered into personal attacks such as when you questioned Randy Bush's experience. In that respect it would indeed have been better for RFC6598 to have picked 240/4 in the sense that it would have saved us 94 out of the 104 mails currently in this thread and, unfortunately, counting. -- Niels.
Re: Burn Rate? Re: 202401100645.AYC Re: IPv4 address block
* ayc...@avinta.com (Abraham Y. Chen) [Fri 12 Jan 2024, 13:09 CET]: EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is reusable for each isolated geographical area. Thus, there is no "Burn-rate" to talk about. You have posted this statement like five times now in the past two days. Who is asking for this expansion of 100.64/10 (which you misspelled, by the way)? Where are the claims that the amount of private space behind a CGNAT is the limiting factor in CGNAT deployments? [five meters of superfluous quote history snipped] -- Niels.
Re: ipv6 address management - documentation
* aar...@gvtc.com (Aaron Gould) [Thu 16 Nov 2023, 19:04 CET]: For years I've used an MS Excel spreadsheet to manage my IPv4 addresses. IPv6 is going to be maddening to manage in a spreadsheet. What does everyone use for their IPv6 address prefix management and documentation? Are there open source tools/apps for this? The first three hits for "open source ipam" on a search engine are: - phpipam.net/ - spritelink.github.io/NIPAP/ - github.com/netbox-community/netbox I'd pick the last option, or possibly Nautobot. You may want to scroll through https://github.com/topics/ipam for more options. -- Niels.
Re: Your Input Needed: Can ROA Replace LOA? – Short Survey (7 mins)
Hi Christopher, No. Why would your survey take an additional 6.5 minutes to fill out? -- Niels. * ch...@thesysadmin.dev (Christopher Hawker) [Thu 16 Nov 2023, 15:20 CET]: Hello everyone, Aftab Siddiqui is currently exploring the possibility of using Route Object Authorisations (ROAs) as a potential replacement to LOAs. Separate to this (and unknowing of Aftab's research), I had started a discussion on the RPKI Community guild on Discord (https://discord.gg/9jYcqpbdRE) discussing the usage of ROAs instead of LOAs. An LOA, or "Letter of Authority" / "Letter of Authorization," is a formal document granting permission for third parties to take specific actions regarding network resources or services. In the service provider industry, its primary use is for advertising address resources (IPv4/v6 and ASN). When an organization intends to announce its IP prefixes through its own or a transit provider's ASN to the global internet, it typically needs to provide an LOA to their transit provider, confirming their custodianship or ownership of the resources. RPKI ROA, stands for "Resource Public Key Infrastructure Route Origin Authorization," is part of a security framework designed to validate the authenticity of internet routing information. It involves a digitally signed object that specifies which Autonomous Systems (ASes) are permitted to announce specific IP address prefixes. Could you please take a moment to fill out our brief survey? Your feedback will play a crucial role in our understanding of this topic. Survey Link: https://www.surveymonkey.com/r/JCHLWBB Thanks, Christopher Hawker
Re: Strange IPSEC traffic
* Shawn L [Mon 13 Nov 2023, 18:12 CET]: Is anyone else seeing a lot of 'strange' IPSEC traffic? This mail server running FreeBSD did: (timestamps in CET, UTC+1) Nov 10 00:58:55 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/77b4/50 Nov 10 01:26:09 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/03e8/50 Nov 11 10:15:22 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/62861b0e/50 Nov 11 14:35:34 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/048b828c/50 Nov 13 20:00:53 mailserver kernel: ipsec_common_input: no key association found for SA 77.174.253.13/a5ff/50 I don't remember ever seeing these log messages before. -- Niels.
Re: ARIN whois contact abuse from ipv4depot aka Silicon Desert International Inc
* Laura Smith [Thu 12 Oct 2023, 19:01 CEST]: I mean, most (all ?) of the registries still can't be bothered to validate the information the resource holders post to the database. Last time I asked, e.g. RIPE about it, they basically said "not my problem guv" , pointed me to some policy document that said members should provide correct details and well, that was about it. So if they don't do that, then what hope is there for them doing something about the harvesters ? RIPE have a policy that states members should submit correct contact details. Having spammers harvest the database discourages people from submitting correct contact details. Ergo, RIPE have a vested interest in ensuring the database doesn't get abused by spammers. Literally everybody hates spam and spammers so it's an easy choice. How an RIR would validate information, how often that should be done, and what would constitute valid information anyway is a very long discussion that has no bearing on abuse of said information. -- Niels.
Re: Using RFC1918 on Global table as Loopbacks
* gutierr...@westmancom.com (Javier Gutierrez) [Thu 05 Oct 2023, 19:25 CEST]: I have recently encountered some operational differences at my new organization that are not what I have been exposed to before, where the loopback of the core network devices is being set from RFC1918 while on the global routing table. I'm sure this is not a major issue but I have mostly seen that ISPs use global IPs for loopbacks on devices that would and hold global routing. My question is, what is the most used or recommended way to do this, if I continue to use RFC1918 I will save some very much desired public address space, but would this come back to bite me in the future? The recommendation is to make Router-IDs globally unique. They're used in collision detection. What if you and a peer pick the same non globally unique address? Any session will never come up. You need globally unique IP addresses on routers anyway, to send ICMP error packets from. -- Niels.
Re: AFRINIC placed in receivership
* nanog@nanog.org (Owen DeLong via NANOG) [Fri 15 Sep 2023, 19:26 CEST]: On Sep 15, 2023, at 06:30, Noah wrote: On Fri, 15 Sept 2023, 15:53 John Curran, wrote: Indeed, that was a less than ideal situation – but I will note that the technical advisor was sent away by the Receiver once the Receiver was apprised of his litigation against AFRINIC. It was not a less than ideal situation. Please dont take things lightly here. Not less than ideal? So was it ideal or more than ideal? I'd like to introduce you to a linguistic concept called the understatement. -- Niels.
Re: NTP Sync Issue Across Tata (Europe)
* m...@beckman.org (Mel Beckman) [Sun 06 Aug 2023, 04:26 CEST]: if you can eliminate such security problems for $400, I say it’s cheap at twice the price. You must be unfamiliar with the prices neutral colocation facilities charge for roof access. -- Niels.
Re: malware warning
* b...@uu3.net (b...@uu3.net) [Sat 22 Jul 2023, 10:24 CEST]: The only interesting action I ever saw was: "Shutting down email spam factory"; where some network was depeered from internet completly. Well done. (Somehow I cannot find post about that anymore). AGIS: https://en.wikipedia.org/wiki/Apex_Global_Internet_Services -- Niels.
Re: BKA Wiesbaden - Abteilung Cybercrime (Not sure if this is a phishing E-mail or real...)
* na...@ve4.ca (Glen A. Pearce) [Mon 24 Apr 2023, 17:42 CEST]: Well, I eventually had a friend open the attachment on his Linux machine Not necessarily a safe idea: https://www.welivesecurity.com/2023/04/20/linux-malware-strengthens-links-lazarus-3cx-supply-chain-attack/ (scroll down to "Operation DreamJob with a Linux payload", sadly no anchors) -- Niels.
Re: Flow Tools AS-Path
* na...@ics-il.net (Mike Hammett) [Tue 04 Apr 2023, 15:06 CEST]: 1) How common is it to have the additional extensions to include that data for analysis? pmacct is a commonly used tool to enrich flow data with such information. -- Niels.
Re: Issues with prefix / help needed
* charles.li...@camonson.com (Charles Monson) [Mon 27 Mar 2023, 16:31 CEST]: On Mon, Mar 27, 2023 at 9:05 AM Kevin McCormick wrote: IRR Explorer is showing RPKI-Invalid. Maybe RPKI is causing the issue or there is an issue with IRR Explorer? https://irrexplorer.nlnog.net/prefix/86.104.228.0/24 I do see RIPE and Cloudflare are showing RPKI as valid. https://rpki-validator.ripe.net/ui/86.104.228.0%2F24/45021?include=related_alloc https://rpki.cloudflare.com/?view=validator&validateRoute=45021_86.104.228.0%2F24 Curious why IRR Explorer is showing invalid. That seems to just be indicating there are route-objects in RADB that don't match RPKI, and not related to anything in BGP. It shows all green right now, perhaps RADb removed an object? (or IRR Explorer updated its own mirror between your mail and mine) -- Niels.
Re: AKAMAI CDN
I can put you in touch with your account manager, what's your ASN? -- Niels. * pascalma...@gmail.com (Pascal Masha) [Thu 12 Jan 2023, 12:21 CET]: Hello, Anyone from Akamai responsible for making decisions on cluster scaling /refresh here? Kindly contact me offlist. Regards Paschal Masha
Re: Akamai Contact/Issues
* t...@visnetworkrd.com (George Toma) [Tue 27 Sep 2022, 17:14 CEST]: Jared I would be also interested in what you said in reply to Dustin Brooks about Akamai contact as in the past we have experienced similar problem, and trying to resolve it with the Akamai EdgeScape support we ran into a stonewall of not being an Akamai client (I understand EdgeScape is the one which in charge of geolocation DB at Akamai) Unfortunately your reply was scrubbed by nanog and is blank. Jared's reply was perfectly readable: "You can ping me off list. Thanks." Mr Brooks' problem wasn't EdgeScape related, by the way. -- Niels.
Re: ARIN RPKI services terms/conditions - Change to Management of the Trust Anchor Locator for ARIN’s RPKI Service
* jcur...@arin.net (John Curran) [Tue 27 Sep 2022, 13:26 CEST]: Yes: the intent is that an RP validator may ship and use the ARIN TAL by default. If that is not clear in the revised RPA, then the RPA agreement will updated again for clarity. I feel like you're just gaslighting us at this point. "You have passed through terms that are at least as protective of ARIN ... via browse-wrap, clickwrap [...] for which such third party is legally obligated to said terms." So, no, software developers cannot ship and use the ARIN TAL by default, which means without having to interrupt an installation process with a question about Articles 5, 6, and 7 and Sections 8(a), 8(b), and 8(f) of the ARIN RPA. Why can't ARIN just grant distribution and use for any purpose rights like the other RIRs? -- 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)
* nanog@nanog.org (Owen DeLong via NANOG) [Sun 18 Sep 2022, 19:53 CEST]: I highly recommend that legacy holders who wish to ensure that their rights are respected transfer their registrations to RIPE-NCC, whether they have signed the LRSA or not. Would you say that in hindsight you would have advocated differently when ARIN decided not to allow transfer of IPv6 resources to other RIRs? -- Niels.
Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023
* b...@herrin.us (William Herrin) [Fri 16 Sep 2022, 22:58 CEST]: [..] * ARIN will not record a transfer of a legacy resource to another registrant absent ARIN's current approved contracts. RIPE NCC, however, will facilitate this. If you as a legacy resource holder in the RIPE NCC service region sign a contract with a sponsoring LIR they will happily allow creation of ROAs for your space. Psst: you can transfer IPv4 to other RIRs if you don't like your current RIR's charging scheme. ARIN discriminates against IPv6 so you're stuck with them for those resources, however. -- Niels.
Re: VZ FIOS and Intel TCP IPv6 Checksum Offload problems
* br...@2mbit.com (Brie) [Mon 29 Aug 2022, 19:38 CEST]: On 8/29/22 10:59 AM, Christopher Morrow wrote: Uhm, this includes various versions of the intel pro 1000 card... so that's a TON of gear, to include like lenovo laptops, for instance. I'd wager that this is super common in the field. The PDF in the download says; "Products Affected: All 1gbe and 10gbe intel ethernet controllers" So I keep seeing this being pushed as a problem with clients... but isn't it the ONT that is bugged out and appending the extra data after the checksum is already there (as Bill Herrin points out)? I know it's asking a lot to expect networking equipment vendors to fix their gear, but... Unless I'm totally not understanding the bug, which is entirely (and likely). Here's my speculation on what was happening at Casa Sean. The Ethernet frame has a length header. The IP frame has a length header. Ideally, the IP frame fits completely into the Ethernet frame, leaving room for the other required Ethernet bits but nothing more. I vaguely recall there being some equipment that interpreted the minimum MTU requirement in IPv6 as meaning that there was a minimum packet size, not a minimum for the *maximum* packet size. Perhaps the fiber NTU padded the Ethernet frame up to the minimum MTU, sending along a bunch of junk bytes, without otherwise touching the IP packet. The NIC would then perhaps forget that there were a bunch of junk bytes attached to the end of the frame beyond where the IP packet would end, and calculate the Ethernet checksum based on the IP packet length header, discarding otherwise valid frames as a result. I've had my own run-ins over the years with supposed checksum offloading absolutely not happening on other brands, so implementation errors appear to be relatively common. -- Niels.
Re: U.S. Court PACER system overloaded by public interest
* amitch...@isipp.com (Anne Mitchell) [Fri 26 Aug 2022, 20:36 CEST]: For anyone wanting the document and unable to get it through Pacer, we have it locally and I'm happy to make it available, just let me know. By now it's so widely available that even DuckDuckGo can find it for you. Not readers of The Guardian, though; the newspaper posted a brief update on their website that read "The affidavit is now out. It is here." and linked to https://file///Users/Shared/Internet%20Downloads/gov.uscourts.flsd.617854.102.1_1.pdf . (It's still there as I write this.) -- Niels.
Re: IPv6 internet broken, cogent/telia/hurricane not peering
* volki...@gmail.com (VOLKAN KIRIK) [Thu 11 Aug 2022, 15:52 CEST]: hello You're replying to a thread from 2009. Please advise. -- Niels.
Re: Rogers Outage Canada
* vic...@jvknet.com (Victor Kuarsingh) [Mon 11 Jul 2022, 17:17 CEST]: This is the most they can and will say. For liabilities reasons, specifics are likely not in the cards. I doubt it. Given that emergency services were impacted you can count on a proper assessment being made available to a parliamentary inquiry. Too much broke to cover this up any further. -- Niels.
Re: irrd or ...?
* ra...@psg.com (Randy Bush) [Sat 18 Jun 2022, 19:39 CEST]: i have been running irrd for some years. am about to dump that (virtual) server and move from freebsd to bullseye. is there anything more modern, and _simpler_, than irrd at which i should take a look? What are you running irrd for? Have you considered irrd4? Simpler than running your own would be querying e.g. rr.ntt.net. -- Niels.
Re: Upstream bandwidth usage
* m...@mtcc.com (Michael Thomas) [Thu 09 Jun 2022, 22:46 CEST]: If it's so tiny, why shape it aggressively? Why shouldn't I be able to burst to whatever is available at the moment? I would think most users would be happy with that. As SBC Global's peering policy roughly two decades ago stated, "No requirement for a balanced traffic exchange ratio due primarily to the asymmetric nature of current broadband metallic transmission systems such as ADSL and cable modems." -- Niels.
Re: Question re prevention of enumeration with DNSSEC (NSEC3, etc.)
* m...@beckman.org (Mel Beckman) [Sat 07 May 2022, 18:38 CEST]: I don’t think copyright can enter into it, by dint of the fact that registry data, being purely factual and publicly available, cannot be copyrighted. I'm not a lawyer nor pretend to be one on the internet but https://bitlaw.com/copyright/database.html provides some nuance to that statement. -- Niels.
Re: Gmail (thus Nanog) rejecting ipv6 email
* d...@prime.gushi.org (Dan Mahoney (Gushi)) [Sun 03 Apr 2022, 00:11 CEST]: I've been seeing a long thread about why ipv6 adoption isn't there yet. This is half a "paging someone with clue" post and half a "...really, guys?" Picard-facepalm post. I just (earlier this week) had to disable ipv6 outbound on one of $dayjob's MX servers, because Gmail, who hosts nanog.org, was rejecting our mail due to "our domain's very low reputation". (In this parlance, "Very Low" is an actual indicative metric.) Dayjob is the people who make BIND and run a root DNS server. Totally disreputable, I'm sure. I don't see anything indicating this in our postmaster tools. I am certain this action is happening completely transparently and invisibly to NANOG, unless others have complained. Whatever UI google gives them to manage their domain will not show this. There are no logs they can grep. I'm told that "gmail's filters for ipv6 are way tighter than ipv4" but that's from a non-canonical source. If this is the case, it does very little to further ipv6 adoption, that's for sure. I've posted over on mailop, and was given a contact (Brandon), but haven't heard back. Gmail's a black box. I've reached out to a few other people, but if anyone here can loan a bat-phone, please let me know. I'm loathe to randomly re-enable ipv6 without contact from someone saying why this happened, and how it's been fixed. -Dan (Who actually operates my own network) I also run my own mail server. I had to firewall off Google's MXes for this exact reason: silent and not-so-silent email rejection when offered over IPv6. Every now and then they rotate their IP addresses, which causes mail to get dropped for a while. There is no other conclusion possible than that Gmail is actively anti-email at this point. I'm pretty sure I receive more spam from them than I send to them, despite forwarding all emails for a few family members' domains. -- Niels.
Re: PoE, Comcast Modems, and Service Outages
On Tue, Mar 29, 2022 at 11:21:28AM -0700, Aaron de Bruyn via NANOG wrote: When I said "yes", he said I needed to disable PoE because it messes with the Comcast modems and he can see "buildups" in his graphs that show power is "leaking" to the Comcast modem every 24 hours. This guy must have a side business selling crystals, or those Faraday cages to contain the bad type of WiFi or 3/4/5G radiation, or some other scam. * jgr...@ns.sol.net (Joe Greco) [Tue 29 Mar 2022, 20:52 CEST]: People who can, do. People who can't, tech support. Worth remembering. I think this smearing of an entire line of work is uncalled for. -- Niels.
Re: Not Making Use of 240/4 NetBlock
* b...@theworld.com (b...@theworld.com) [Mon 14 Mar 2022, 00:31 CET]: Personally I'd rather hear from the RIRs regarding the value or not of making more IPv4 space such as 240/4 available. They're on the front lines of this. You've got your policy development process diagram upside down. The community decides what the RIRs implement. They're not in touch with merchant silicon manufacturers. -- Niels.
Re: Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)
* darkde...@darkdevil.dk (Arne Jensen) [Wed 08 Dec 2021, 15:23 CET]: To me, that part of it also points towards a broken implementation at CloudFlare, letting a bogus (insecure) responses take effect anyway. Or they prefer allowing people to visit websites over punishing system administrators for operational failures that less secure (read: nonvalidating) ISPs wouldn't inflict on their customers. It's been quite common for DNSSEC-enabled recursors to add overrides for outaged domains in situations like this. It looks like the error has been mitigated, by the way, so this manual override may not even have happened. -- Niels.
Re: Salesforce issues
* esundb...@nitelusa.com (Erik Sundberg) [Wed 24 Nov 2021, 20:57 CET]: We are receiving latency complaints to Salesforce, anyone else seeing this? [...] dig force.com +short force.com sends an immediate HTTP redirect to www.force.com. You should look up that hostname instead, and ideally you should have Salesforce customers file tickets with Salesforce, since they're in the best position to debug their web app that undoubtedly pulls in content from many different hostnames. -- Niels.
Re: possible rsync validation dos vuln
* nanog@nanog.org (Jean St-Laurent via NANOG) [Fri 29 Oct 2021, 19:57 CEST]: The link doesn't work. 404 https://www.ncsc.nl/actueel/nieuws/2021/oktober/29/aanstaande-bekendm | X-Mailer: Microsoft Outlook 16.0 The posted link works fine here but your MUA mangled it so you'll have to do some manual work to put the two parts together again. You're missing "aking-cvd-procedure-rpki" at the end. What are the specs of that possible dos vuln? ¯\_(ツ)_/¯ Is is reflection or amplification or something else? Maybe you missed the bit where the actual vulnerabilities are under embargo? -- Niels.
Re: S.Korea broadband firm sues Netflix after traffic surge
* mark@tinka.africa (Mark Tinka) [Mon 11 Oct 2021, 17:18 CEST]: To be fair, Jane + Thatho don't care about video resolution. I don't think that's being entirely fair. Netflix in plenty places differentiates its subscriptions based partly on video resolution: https://help.netflix.com/en/node/24926/us Some people will definitely care enough to sign up for a more expensive tier. -- Niels.
Re: S.Korea broadband firm sues Netflix after traffic surge
* do...@dougbarton.us (Doug Barton) [Sun 10 Oct 2021, 23:44 CEST]: First, I'm not saying "should." I'm saying that given the market economics, having the content providers who use "a lot" of bandwidth do something to offset those costs to the ISPs might be the best/least bad option. Whether "something" is a local cache box, peering, money, or is something I think that the market should determine. Sounds like you think SK should be paying Netflix for bringing their content all the way from the US to the Korean peninsula. That's some expensive wet cable being used there. -- Niels.
Re: Disaster Recovery Process
* deles...@gmail.com (jim deleskie) [Tue 05 Oct 2021, 19:13 CEST]: World broke. Crazy $$ per hour down time. Doors open with a fire axe. Please stop spreading fake news. https://twitter.com/MikeIsaac/status/1445196576956162050 |need to issue a correction: the team dispatched to the Facebook site |had issues getting in because of physical security but did not need to |use a saw/ grinder. -- Niels.
Re: Facebook post-mortems...
Ryan, thanks for sharing your data, it's unfortunate that it was seemingly misinterpreted by a few souls. * ryan.lan...@gmail.com (Ryan Landry) [Tue 05 Oct 2021, 17:52 CEST]: Niels, you are correct about my initial tweet, which I updated in later tweets to clarify with a hat tip to Will Hargrave as thanks for seeking more detail.
Re: Facebook post-mortems...
* telescop...@gmail.com (Lou D) [Tue 05 Oct 2021, 15:12 CEST]: Facebook stopped announcing the vast majority of their IP space to the DFZ during this. People keep repeating this but I don't think it's true. It's probably based on this tweet: https://twitter.com/ryan505/status/1445118376339140618 but that's an aggregate adding up prefix counts from many sessions. The total number of hosts covered by those announcements didn't vary by nearly as much, since to a significant extent it were more specifics (/24) of larger prefixes (e.g. /17) that disappeared, while those /17s stayed. (There were no covering prefixes for WhatsApp's NS addresses so those were completely unreachable from the DFZ.) -- Niels.
Re: facebook outage
* jllee9...@gmail.com (John Lee) [Tue 05 Oct 2021, 01:06 CEST]: I was seeing NXDOMAIN errors, so I wonder if they had a DNS outage of some sort?? Were you using host(1)? Please don't, and use dig(1) instead. There were as far as I know at no point NXDOMAINs being returned, but due to the SERVFAILs host(1) was silently appending your local search domain to your query which would lead to incorrect NXDOMAIN output. -- Niels.
Re: massive facebook outage presently
* b...@theworld.com (b...@theworld.com) [Tue 05 Oct 2021, 00:01 CEST]: I only mean a single, simple information page like the "sorry we're working on it" I saw just before they came back. Which would subsequently receive the world's FB session cookies. -- Niels.
Re: massive facebook outage presently
* m...@beckman.org (Mel Beckman) [Mon 04 Oct 2021, 18:23 CEST]: Here’s a screenshot: [cid:3E071EF9-BBC5-44BF-865D-2EDC36E05C71-L0-001] Please don't do this on the NANOG list. -- Niels.
Re: Rack rails on network equipment
* c...@cmadams.net (Chris Adams) [Sat 25 Sep 2021, 00:17 CEST]: Which - why do I have to order different part numbers for back to front airflow? It's just a fan, can't it be made reversible? Seems like that would be cheaper than stocking alternate part numbers. The fan is inside the power supply right next to the high-voltage capacitors. You shouldn't be near that without proper training. -- Niels.
Re: IPv6 woes - RFC
* Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]: IPv4 continues to increase in cost. Surely, there is a point where organizations start to cry uncle. In most western countries there isn't much growth in the total number of connections. It's mostly churn between providers. IPv4 addresses aren't wasted once a customer leaves (unlike for mobile numbers there is no mandated number portability for IP addresses), they can be reused for the next customer, they don't deteriorate when kept in stock, and they can likely be sold for more, later, eventually. (As long as you buy, not rent, that is, and LIR fees don't significantly increase.) -- Niels.
Re: if not v6, what?
* mo...@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Tue 07 Sep 2021, 18:36 CEST]: As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. This absolutely doesn't work. And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email). Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today. Oh and we need to work around the whole IP reputation system that governs email today. Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home? We may even develop transport protocols with 32 bit port numbers, which is a lot easier to deploy than IPv6. Do you have any more practical proposals, or..? -- Niels.
Re: IPv6 woes - RFC
* bj...@mork.no (Bjørn Mork) [Mon 06 Sep 2021, 15:08 CEST]: And as demonstrated in this thread: Even the few who still do care are not willing to pay extra, or sacrifice anything, for IPv6. They will run off to your competitor as soon as they discover the price is lower there. Which it will be since they saved a lot by building and running an IPv4 only access network. Is that why cable operators are shifting to native IPv6 + CGNAT for IPv4 instead of following your advice to build only native IPv4? -- Niels.
Re: IPv6 woes - RFC
* bj...@mork.no (Bjørn Mork) [Sun 05 Sep 2021, 18:24 CEST]: So where does that put us in a decade or two? Which protocol is optional? The one that costs money. You can already see this in mobile networks. -- Niels.
Re: IPv6 woes - RFC
* r...@rkhtech.org (Ryan Hamel) [Sat 04 Sep 2021, 23:04 CEST]: Not everyone has the luxury of picking their ISP, and the common consumer doesn't know or care about IPv6. They want Netflix to work and that's it. We just had a 100+ post thread about Netflix not working because CGNs were misclassified as VPN endpoints. -- Niels.
Re: The great Netflix vpn debacle!
* war...@kumari.net (Warren Kumari) [Tue 31 Aug 2021, 21:04 CEST]: So, RFC8805 is great and all, but it sure is annoying that you have to find webforms for a whole heap-o-geolocation providers, and figure out how to tell them where your geofeed file lives, etc. Introducing RFC9092 - "Finding and Using Geofeed Data" ( [..] This won't help at all against geolocation vendors marking proxies and VPN endpoints as such. -- Niels.
Re: An update on the AfriNIC situation
* rube...@gmail.com (Rubens Kuhl) [Fri 27 Aug 2021, 19:16 CEST]: But that doesn't prevent the other RIRs issuing those since all TAs sign 0/0. Nothing does except common sense -- Niels.
Re: [EXTERNAL] Re: An update on the AfriNIC situation
* rich.comp...@charter.com (Compton, Rich A) [Fri 27 Aug 2021, 18:47 CEST]: Can't AfriNIC just create ROAs for the prefixes and point them to AS0? That would pretty much make the prefixes unusable since most tier 1's are doing ROV now. I'm not a lawyer but that doesn't strike me as a great idea for an object under dispute once the presiding judge finds out about it -- Niels.
Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL. * sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 01:59 CEST]: The difference is, if you are able to use PeeringDB as a single source of truth, it is a lot easier to grab the data you need. But again, their database, their rules. So you were planning to abuse, er, creatively implement their datamodel to declare yourself an IXP and list all your peers as members of said IXP, and then convince the world to build filter lists based on said participant list? Creative, but indeed not what PeeringDB is about. -- Niels.
Re: PeerinDB refuses to register certain networks [was: Setting sensible max-prefix limits]
* sa...@cluecentral.net (Sabri Berisha) [Thu 19 Aug 2021, 00:55 CEST]: For example, if I were to register my peers (53356 and 136620) and AS5524 would all of a sudden start to advertise my AS as behind it, you'd be able to flag that. I'm confused. When did PeeringDB turn into a routing (policy) registry? You should use an IRRdb if you want to write RPSL. -- Niels.
Re: AS 3356 (Level 3) -- Community 3356:666
* Martijn Schmidt [Wed 04 Aug 2021, 18:01 CEST]: And it's also nice not to yank the old community in case your customers still depend on it, even if you do also support the RFC version as an alias of that one. Note that 3356:666 is applied on ingress to routes received from peers. They could easily rewrite their import policy to translate any 3356:666 to 3356: before passing it on to their RTBH systems, without impacting previous consumers of 3356:666 among their BGP customers. -- Niels.
Re: FreeBSD's ping Integrates IPv6
I just noticed (although it appears to have come in version 13.0) that FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6: * ra...@psg.com (Randy Bush) [Fri 02 Jul 2021, 18:48 CEST]: pola breakage. especially fun if you have tools which run on both sides of the koolaid. On the one hand, yes. On the other hand, Linux had already made this change for ping specifically. Almost all other tools you'd use regularly are dual-stack by default that follow what's configured for the system to prefer (for FreeBSD that's ip6addrctl_policy): tools like telnet, ssh, mtr all follow the system default with -4 and -6 command-line options to override the default if situationally needed. ping and traceroute were the only odd ones out, and now only traceroute is. I think this was an unavoidable change worth the temporary discomfort while tools using these tools are adjusted. -- Niels.
Re: FreeBSD's ping Integrates IPv6
* mark@tinka.africa (Mark Tinka) [Fri 02 Jul 2021, 16:02 CEST]: I just noticed (although it appears to have come in version 13.0) that FreeBSD's "ping" app now defaults to IPv6, i.e., no need for ping6: Yes, this broke some of my home network monitoring. Sadly there is no 'ping4' in the system, you have to add -4 to the commandline to return to the common BSD behaviour. -- Niels.
Re: Texas ERCOT power shortages (again) April 13
* brian.john...@netgeek.us (Brian Johnson) [Wed 14 Apr 2021, 17:37 CEST]: Not what I was saying. The demand for virtue-signaling green energy is not an effective strategy to actually having power available. The relevant virtue that's signaled with green energy is that its MWh prices are WAY lower than traditional fossil fuel-based generators. I appreciate the nuances, but the need to imply that a profit motive was the issue is not proven. This issue was NOT foreseeable except with the perfect reverse 20/20 vision. It’s like saying that I shouldn’t have built the house where the tornado hit. I've not done exhaustive research of the situation in Texas (although I am a stakeholder, being a customer in several datacentres there) but I'd be surprised if https://en.wikipedia.org/wiki/Regulatory_capture had nothing to do with it. -- Niels.
Re: wow, lots of akamai
* patr...@ianai.net (Patrick W. Gilmore) [Fri 02 Apr 2021, 01:01 CEST]: I know first hand that Akamai has explained to large customers the possible problems with multi-GB updates to millions of users simultaneously. If the game company does not care, then I do not see what you expect the CDN to do about it. Thanks, Patrick. In fact, Akamai has been a partner in this dialogue: https://blogs.akamai.com/2020/03/working-together-to-manage-global-internet-traffic-increases.html One of the positive results is described here: https://www.callofduty.com/blog/2021/03/Season-Two-Reloaded-Warzone-File-Size-Reduction "Enhancements to the overall content management system has been made possible through data optimization and streamlining content packs needed for individual game modes. This will come after a larger than usual, one-time update for Season Two Reloaded, which will include these optimizations and is necessary in order to reduce the overall footprint; future patch sizes for Modern Warfare and Warzone are expected to be smaller than the one set to release on March 30 at 11PM PST." So the ISPs as well as the CDNs and the players are being listened to by at least this publisher. -- Niels.
Re: wow, lots of akamai
* na...@ics-il.net (Mike Hammett) [Thu 01 Apr 2021, 23:17 CEST]: However, the game publisher queues those requests. I'm meaning request generically, not a GET request or anything like that. The game publisher that contracts to the CDNs decides when to fulfill those requests, in the big picture. The game publisher is the one that then tells 100 million devices "Content Available". The rate that they do that is at their discretion. Keep in mind that the publisher doesn't just create a bunch of new assets to give away for free from the goodness of their hearts. Every update comes with new hats, weapon finishes, heroes, trading cards etc. that players are expected to buy for real money. Any delay could kill the hype and impact revenue. There is a lot of "But muh discard counters!" in this thread that is perfectly valid and understandable and that I absolutely relate to, but it's not the only perspective. -- Niels.
Re: wow, lots of akamai
* na...@ics-il.net (Mike Hammett) [Thu 01 Apr 2021, 21:51 CEST]: I'm not sure what kind of time lines are expected or engineered for now, but it *seems* like its a 12 - 36 hour sprint to push the content out. If so, push it out to 36 - 72 hours? Adjust accordingly for however much off I am on the first time frame. Doesn't that mostly depend on when people turn on their gaming consoles to play? It's not on the publisher to dictate how often people want to play their game. -- Niels.
Re: wow, lots of akamai
* j...@ddostest.me (Jean St-Laurent) [Thu 01 Apr 2021, 21:41 CEST]: This would be a good compromises for all. Slowly deliver the assets few days/weeks ahead. Excellent compromise except for the people who paid for the game. Why do they need to spend storage to solve your bandwidth problem? CoD is being played on lots of devices with limited storage space, like PlayStation 4. Needing to have two versions of the game would be a heavy burden on owners. And not everybody has infinite disk space in their gaming PCs either. -- Niels.
Re: wow, lots of akamai
* nanog@nanog.org (Jean St-Laurent via NANOG) [Thu 01 Apr 2021, 21:03 CEST]: An artificial roll out penalty somehow? Probably not at the ISP level, but more at the game level. Well, ISP could also have some mechanisms to reduce the impact or even Akamai could force a progressive roll out. It's an online game. You can't play the game with outdated assets. You'd not see walls where other players would, for example. What you're suggesting is the ability of ISPs to market Internet access at a certain speed but not have to deliver it based on conditions they create. -- Niels.
Re: Perhaps it's time to think about enhancements to the NANOG list...?
* r...@gsp.org (Rich Kulawiec) [Sat 20 Mar 2021, 14:03 CET]: 2. This is a low-traffic list, so even without appropriate mail client support it's really not a big deal. The volume isn't the point, the S:N ratio is. Mails like this thread's starter are off-topic and reduce the value of the list to its subscribers. Your reasoning is easy, common and fallacious. -- Niels.
Re: SFI/SBI/Transit - Dumping
* fischerdoug...@gmail.com (Douglas Fischer) [Tue 16 Mar 2021, 11:32 CET]: And then?? Can this be considered an anti-competitive act? I think you're asking this on the wrong list. We're network operators, not lawyers with a specialisation in competitive markets regulation. -- Niels.
Re: bgp.he.net?
* h...@interall.co.il (Hank Nussbacher) [Thu 18 Feb 2021, 14:10 CET]: Is it down? -Hank I can access https://bgp.he.net/contact/ just fine from here. Also, it's 2021, please stop posting in HTML. -- Niels.
Re: [EXTERNAL] Re: dumb question: are any of the RIR's out of IPv4 addresses?
* nanog@nanog.org (Mann, Jason via NANOG) [Wed 17 Feb 2021, 00:44 CET]: Are their legtimate websites to go to purchase new blocks? IPv4 is not like Bitcoin, new addresses aren't being mined using gigantic amounts of electricity at enormous environmental cost. -- Niels.
Re: [External] Re: 10g residential CPE
* mpet...@netflight.com (Matthew Petach) [Tue 29 Dec 2020, 01:08 CET]: But as far as the physics goes, the conversion of biomatter into petrochemicals in the ground is more "renewable" than the conversion of hydrogen into helium in the sun. It's not. Where did Mr Metcalf think the energy comes from that is necessary for that process? You know, the energy that we can now extract by burning it? -- 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: 10g residential CPE
* mark.ti...@seacom.com (Mark Tinka) [Sat 26 Dec 2020, 06:48 CET]: On 12/25/20 23:22, Niels Bakker wrote: Download times:- 180GB at 100 Mbps: 4 hours 180GB at 1000 Mbps: 23 minutes For a number of reasons, highly unlikely your console will pull at 1Gbps, but yes, it would certainly pull quicker than 100Mbps :-). Why wouldn't it go even faster, assuming it got fitted out with a faster network controller than what they shipped with? The storage system in the PS5 as sold can transfer at 5 GB/sec and the APUs have the regular set of crypto acceleration instructions. https://www.theverge.com/2020/11/5/21551165/sony-ps5-playstation-5-no-m2-ssd-expansion-launch https://www.tweaktown.com/news/71340/understanding-the-ps5s-ssd-deep-dive-into-next-gen-storage-tech/ -- Niels.
Re: 10g residential CPE
* m...@mtcc.com (Michael Thomas) [Fri 25 Dec 2020, 21:18 CET]: On 12/25/20 11:34 AM, Niels Bakker wrote: Gigabit speeds are about bursting. Foreground activities like gaming, making online reservations, streaming won't take more than that, but anything faster is really nice to have when you're waiting for the odd software download to finish. (You may have noticed that they've been increasing in size this year.) Wouldn't cpe that implements proper queuing disciplines be a lot simpler and cheaper? I got bit by that once when a friend was downloading a game and it. I flashed a router with openwrt and fiddled with their queuing nobs and everything was golden. Let's take an example from earlier this year when Activision shipped a 180GB update to Call of Duty: Modern Warfare when they introduced the War Zone BR game mode update. Download times:- 180GB at 100 Mbps: 4 hours 180GB at 1000 Mbps: 23 minutes How will proper queuing disciplines possibly help here? -- Niels.
Re: 10g residential CPE
* mark.ti...@seacom.com (Mark Tinka) [Fri 25 Dec 2020, 19:11 CET]: I have a mate up the road who just paid for a 1Gbps FTTH service because it was the same price as a 100Mbps one. He generally lives between 900Kbps and 20Mbps. Gigabit-level FTTH services for the home, I feel, have always been about marketing ploys from providers, because they know there is no practical way users can ever hit those figures from their homes. [...] Gigabit speeds are about bursting. Foreground activities like gaming, making online reservations, streaming won't take more than that, but anything faster is really nice to have when you're waiting for the odd software download to finish. (You may have noticed that they've been increasing in size this year.) -- Niels.
Re: Changing DNS host records
* matt...@corp.crocker.com (Matthew Crocker) [Fri 11 Dec 2020, 20:27 CET]: I have many customers that have registered their domains against my authoritative servers (DNS-AUTH3.CROCKER.COM). I need to move that machine to a different network/IP address. I’ve made the updates in my domain (crocker.com) but I think I also need to update the host glue records in the gtld-servers as well. How do I go about doing that? Ultimately the customers need to update their registration with our new authoritative servers, many have but we still have some stragglers I don’t want to break when I shutdown the old servers. Normally you'd go to your registrar and update the host record there. However, you've not created one, presumably because you don't need one (crocker.com is on AWS nameservers), so you don't need to do anything except update your own zone. Check the output of % dig a DNS-AUTH3.CROCKER.COM @a.gtld-servers.net. for (the lack of) A records in the additional section. Replace your host with e.g. rip.psg.com to see the difference for an existing glue record. You used to be able to see host records using whois but that functionality appears to have gone away. -- Niels.
Re: Disney+ Geolocation (again)
* se...@rollernet.us (Seth Mattinen) [Sun 08 Nov 2020, 18:21 CET]: I've had 74.118.152.0/21 allocated to me since 2005. So many IPs in possession for so long, yet so little reverse DNS: --- $ (for j in `jot 7 2`; do for i in `jot 255`; do host 74.118.15$j.$i; done; done) | grep -c NXDOMAIN 1579 --- And a lame delegation for 159.118.74.in-addr.arpa. -- Niels.
Re: Apple Catalina Appears to Introduce Massive Jitter
* nanog@nanog.org (J. Hellenthal via NANOG) [Thu 29 Oct 2020, 15:10 CET]: [disabling checksum offload] Wireshark used to in Catalina rack up cksum errors a lot while these were all at their defaults. This is completely expected behaviour for outgoing packets. -- Niels.
Re: Circuit ordering software
* orothsch...@gmail.com (Oliver Rothschild) [Wed 21 Oct 2020, 22:39 CEST]: For those that have circuit ordering mechanisms in their environment, what sort of software do you use? If you're on the implementing side, you may want to take a look at https://ix-api.net/ to see how the three largest IXPs in Europe have done this. -- Niels.
Re: McAfee's certificate on akamai seems to be invalid
* drew.wea...@thenap.com (Drew Weaver) [Thu 07 May 2020, 16:50 CEST]: I contacted their support and CS but if anyone knows someone at either organization it appears that the certificate for downloadcenter.mcafee.com Is invalid. Has been this way for a while. It looks like you shouldn't attempt to access that site over HTTPS, just via plain HTTP. Do you have any official bit of documentation that links to the HTTPS version? -- Niels.
Re: Google peering pains in Dallas
* ja...@puck.nether.net (Jared Mauch) [Thu 30 Apr 2020, 20:10 CEST]: (Waits for others to crawl out of the woodwork who were more involved in this :-) Half duplex 10baseT ports, man. The collision LEDs never calmed down. -- Niels.
Re: akamai yesterday - what in the world was that
* xima...@gmail.com (Töma Gavrichenkov) [Fri 24 Jan 2020, 11:49 CET]: And now for our amusement Akamai can do it *accidentally*. What do you mean? The CDNs don't publish the games nor do they buy the games. The people downloading aren't even their customers. The publishers generally decide the % of traffic share each CDN serves if they contract with multiple CDNs for a project. -- Niels.
Re: help with diagnosing traffic blackhole to / from select akamai ranges?
* wimcl...@gmail.com (William McLendon) [Thu 09 Jan 2020, 20:18 CET]: thank you all for the rapid feedback and suggestions! since many have asked for more detail, the specific prefix in question is 168.8.214.0/24. The previous owner is still announcing 168.8.0.0/14. If you're shooting holes in netblocks like this you can expect routing issues. -- Niels.
Re: Elephant in the room - Akamai
* rod.b...@unitedcablecompany.com (Rod Beck) [Sun 08 Dec 2019, 18:18 CET]: Last time I spoke with an Akamai engineer many years ago the network was purely transit. Is that evolving? https://conference.apnic.net/data/41/ix_100-akamai-apricot2016-23feb2016_1456157526.pdf Per those slides, PAIX in 2000, LINX, DE-CIX, AMS-IX in 2001, JPIX in 2002, so you must have spoken with an engineer shortly after the company was founded in 1998. -- Niels.
Re: Disney+ Streaming
* mikeboli...@gmail.com (Mike Bolitho) [Wed 13 Nov 2019, 12:05 CET]: This has gone well beyond out of scope of the NANOG list. Discussing who watches what kind of content has nothing to do with networking. Can you guys take the conversation elsewhere? On the contrary. This discussion informs eyeball networks' capacity planning requirements for the upcoming years. It'd be nice to go from anecdata to data, though. -- Niels.
Re: This DNS over HTTP thing
* j...@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 23:21 CEST]: - Original Message - From: "Niels Bakker" To: nanog@nanog.org Sent: Wednesday, October 2, 2019 1:42:08 PM Subject: Re: This DNS over HTTP thing * j...@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]: From: "Livingood, Jason" What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place. HTTP/451 Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work. Closed captioned for the analogy-impaired: "The idea you're talking about, Jason, is analogous to that embodied in the 451 error code in HTTP." Oh, you weren't proposing a technical solution to a social problem? -- Niels.
Re: This DNS over HTTP thing
* j...@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]: From: "Livingood, Jason" What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place. HTTP/451 Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work. -- Niels.
Re: This DNS over HTTP thing
* nanog@nanog.org (Damian Menscher via NANOG) [Tue 01 Oct 2019, 23:04 CEST]: Should be obvious to non-trolls that I was referring to Google changing the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host. Funny because just last week there was a Google Chrome update that removed /var on macOS (on systems with SIP disabled). -- Niels.
Re: Consistent routing policy?
https://archive.nanog.org/meetings/nanog40/presentations/BGPcommunities.pdf Don’t let anyone send you Informational tags, these should only be set by you, and you should strip them from all BGP neighbors (customers, transits, peers, etc). Otherwise you have a massive security problem. * r...@tajvar.io (Ross Tajvar) [Mon 16 Sep 2019, 19:14 CEST]: I often see informational tags propagated through multiple ASes. What is the security risk there? Don't let anyone send you *your* informational tags. -- Niels.
Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17
* r...@tristatelogic.com (Ronald F. Guilmette) [Sat 10 Aug 2019, 02:26 CEST]: As far as I am aware, no RIR makes any effort whatsoever to vet changes to WHOIS records, either for IP blocks or ASNs or ORG records. This is hilarious. You should hear the whining from any EU-based operator who has to implement the transfer of RIPE NCC resources in a corporate acquisition. I recently was involved with one of those and the amount of due diligence required by the RIPE NCC was pretty intense. If I were at an RIR I'd be insulted by your claim of "no... effort whatsoever". -- Niels.
Re: RFC 5771 - Global Multicast Addresses
* bran...@brandonsjames.com (Brandon James) [Mon 05 Aug 2019, 17:17 CEST]: As a young network engineer (no historic perspective) and only SMB and enterprise experience. It seems like the intention was to allow these to be publicly routed, but it would be a nightmare to implement so it never was. Multicast was never popular with operators because it had the potential to create a lot of state across every router in a network, as well as lead to uncontrolled explosions of traffic, especially in network designs that relied on virtual circuits for significant portions of last-mile infrastructure. Some of these problems were addressed with SSM, IP DSLAMs, and having consumer connection speeds be significantly faster than what a Full HD video stream requires, but given that major network providers already don't have the in-house clue to implement IPv6, multicast will be very low priority. -- 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: What can ISPs do better? Removing racism out of internet
* m...@beckman.org (Mel Beckman) [Mon 05 Aug 2019, 17:21 CEST]: Cloudfare is being foolish, and hypocritical. They freely, for example, carry the equally offensive content of Antifa. Are they going to cut them off too? Finally, a centrist to point out the true culprits of all this violence
Re: Must have ISP Open Source & tools
* meh...@akcin.net (Mehmet Akcin) [Mon 08 Jul 2019, 02:07 CEST]: We are a growing ISP in Colombia and Latin America. I am interested in hearing from others regarding tools and software they recommend we must have such as LibreNMS, Rancid etc. You should reach out to Euro-IX if you haven't already, every member IXP has documented what software they use in their switch database -- Niels.
Re: Cost effective time servers
* j...@west.net (Jay Hennigan) [Fri 21 Jun 2019, 05:19 CEST]: On 6/20/19 07:39, David Bass wrote: What are folks using these days for smaller organizations, that need to dole out time from an internal source? If you want to go really cheap and don't value your time, but do value knowing the correct time, a GPS receiver with a USB interface and a Raspberry Pi would do the trick. Have you tried this? Because I have, and it's absolutely terrible. GPS doesn't give you the correct time, it's supposed to give you a good 1pps clock discipline against which you can measure your device's internal clock and adjust accordingly for drift due to it not being Cesium-based, influenced by room temperature etc. You're unlikely to get the 1pps signal across USB, and even then there'll likely be significant latencies in the USB stack compared to the serial interface that these setups traditionally use. -- Niels.
Re: Traffic ratio of an ISP
* na...@ics-il.net (Mike Hammett) [Wed 19 Jun 2019, 23:19 CEST]: PeeringDB has categories of ratios to choose from. What has the community decided is acceptable ratios for each category? It's fairly trivial for any network to determine what their ratio is as a number, but not necessarily as a PeeringDB label. The community has long ago decided that ratios are bullshit -- Niels.
Re: BGP person from Bell Canada/AS577
* jab...@hopcount.ca (Joe Abley) [Wed 19 Jun 2019, 17:24 CEST]: On 19 Jun 2019, at 10:27, Mike Hammett wrote: I'm curious as to why someone would want to do this? My interest is education, not combative. In previous lives I have had great success simply talking to people at Akamai about where my customers' traffic was landing, and where would make more sense for it to land. They were always very responsive; the people I used to talk to are no longer there, but I imagine there are replacements, even if you have to hunt a little further than the published noc address. I always took care to describe my problem in terms of clients and content rather than routing policy, which seemed like a better bet than making assumptions about how their content-steering machinery worked. Still happy to help out as will be other colleagues lurking on this list. Asking Akamai seems more likely to succeed than asking a third-party network to modify their BGP export policy for a non-customer, especially when the third-party network is large and, I am guessing, highly-automated and policy-rigid. But it would be interesting to me too to find out if I'm wrong. It's Akamai making the decision to serve networks from certain clusters so it's not really up to Bell to go against Akamai's request to send their own + customer prefixes for their cluster. Jason, if you are multi-homed you could always try AS_PATH prepending 18717 to the advertisments you send towards 577 (he said, over his shoulder, running away). Akamai caches generally ignore AS_paths so that may not help. -- Niels.
Re: Postmaster@
* m...@beckman.org (Mel Beckman) [Sat 15 Jun 2019, 03:49 CEST]: Postmaster@ is so widely spammed as to be useless. Not my experience at all (*knocks wood*). RIPE database contacts, on the other hand... -- Niels.
Re: Spamming of NANOG list members
* s...@ottie.org (Scott Christopher) [Sat 01 Jun 2019, 12:04 CEST]: I wonder if this crap corresponds positively with the price of Bitcoin. Only speculation (read: market manipulation) by holders of massive amounts of bitcoin drives the price of cryptocurrencies: https://davidgerard.co.uk/blockchain/2019/05/18/number-go-down-the-single-trade-that-crashed-bitcoin/ -- Niels.
Re: Spamming of NANOG list members
* br...@shout.net (Bryan Holloway) [Sat 01 Jun 2019, 01:54 CEST]: Anybody else noticed a significant uptick in these e-mails? When I first saw this thread, I hadn't seen any. A couple days later, I got my first one. (yay!) Now I'm getting 2-3 a day. (yay?) Yes. It's pretty annoying. And somebody seems to be burning through a lot of stolen credentials. I wonder what the success rate is... -- Niels.
Re: PSA: change your fedex.com account logins
* r...@gsp.org (Rich Kulawiec) [Fri 31 May 2019, 16:18 CEST]: [...] This is hardly surprising: many of them are spammers-for-hire, many of them use invasive tracking/spyware, and none of them actually care in the slightest about privacy or security -- after all, it's not *their* data, why should they? Which is why we now have GDPR. Care, or get fined. Which are some of the many reasons that outsourcing your mailing lists is a terrible idea, doubly so when it's quite easy to run your own with Mailman (or equivalent). Unfortunately it's not that easy; the few large remaining mail hosters at best have opaque procedures when it comes to accepting mail. -- Niels.
