Re: Disney+ Issues
> On Apr 29, 2022, at 11:09 AM, Nick Suan via NANOG wrote: > > The fact that it even has to come to this idea is ridiculous but I wonder > about the success of holding a normal customer account with repeat offending > streaming services so you could report this, by proxy, /as/ a customer. > As ridiculous as it sounds, I can confirm I had an experience like this. I once had an issue where a customer was having issues with streaming from Netflix where they kept getting the message that they were using a proxy/vpn. They wouldn’t even talk to me about it until I provided them an account that had an active subscription applied. By the time I finally got someone to look into it the problem had resolved itself in their backend. I still keep an account around with the base subscription in my back pocket just in case it crops back up again.
Re: V6 still not supported
I think you’re jumping to conclusions that Sony is doing this purely from the darkness in their hearts. The same thing could be said about Netflix and Hulu blocking traffic from addresses that appear as proxies/VPNs. Like it or not we had many years where the primary expectation of the Internet was that you could map a single ISP customer back to an IP address and MANY services still cling to this belief. https://news.slashdot.org/story/21/05/22/0151220/6th-grader-expelled-after-zoom-provided-possibly-inaccurate-ip-address This is why we have situations like this where even law enforcement agencies can’t seem to wrap their heads around multiple customers all sharing the same IP address. You have to remember that a majority of people do not see all this behind the scenes stuff so as far as they are concerned the Internet will continue working as it always has and any deviation in that is a problem with the ISP when all of their friends can connect fine except for them. > On > Apr 4, 2022, at 8:00 AM, Jared Brown wrote: > > A root cause fix would address Sony's hostile behavior.
Re: ISP data collection from home routers
That link is more reflective of the FCC circa 2011. More recent actions taken by the FCC under Pai had weakened consumer protections for data collected by ISPs and was reflected in multiple news articles from 2017-2019. https://en.wikipedia.org/wiki/2017_Broadband_Consumer_Privacy_Proposal_repeal https://transition.fcc.gov/Daily_Releases/Daily_Business/2017/db0328/DOC-344116A1.pdf https://www.ftc.gov/news-events/news/press-releases/2019/08/ftc-revises-list-companies-subject-broadband-privacy-study Including this relatively recent article by the FTC. The same FTC tapped by the FCC as being the more responsible party for enforcing privacy protections for consumers. They are even saying that their privacy study showed very little protections for consumer data being harvested by ISPs with few options to restrict their use. https://www.ftc.gov/news-events/news/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect-troves-personal-data-users-have-few > On Mar 24, 2022, at 9:26 AM, Josh Luthman wrote: > > I'm surprised we're having this discussion about an internet device that the > customer is using to publicize all of their information on Facebook and > Twitter. Consumers do not care enough about their privacy to the point where > they are providing the information willingly. > > >Consumers should have legal say in how or wether their data are harvested > >and also sold. > > They do. https://www.fcc.gov/general/customer-privacy > > > On Thu, Mar 24, 2022 at 9:12 AM Lady Benjamin Cannon of Glencoe, ASCE > wrote: > This is an enormous problem, see: > https://www.ftc.gov/news-events/news/press-releases/2021/10/ftc-staff-report-finds-many-internet-service-providers-collect-troves-personal-data-users-have-few > > Consumers should have legal say in how or wether their data are harvested and > also sold. > > Ms. Lady Benjamin PD Cannon of Glencoe, ASCE > 6x7 Networks & 6x7 Telecom, LLC > CEO > l...@6by7.net > "The only fully end-to-end encrypted global telecommunications company in the > world.” > > FCC License KJ6FJJ > > Sent from my iPhone via RFC1149. > >> On Mar 24, 2022, at 3:44 AM, Giovane C. M. Moura via NANOG >> wrote: >> >> Hello there, >> >> Several years ago, a friend of mine was working for a large telco and his >> job was to detect which clients had the worst networking experience. >> >> To do that, the telco had this hadoop cluster, where it collected _tons_ of >> data from home users routers, and his job was to use ML to tell the signal >> from the noise. >> >> I remember seeing a sample csv from this data, which contained _thousands_ >> of data fields (features) from each client. >> >> I was _shocked_ by the amount of (meta)data they are able to pull from home >> routers. These even included your wifi network name _and_ password! >> (it's been several years since then). >> >> And home users are _completely_ unaware of this. >> >> So my question to you folks is: >> >> - What's the policy regulations on this? I don't remember the features >> (thousands) but I'm pretty sure you could some profiling with it. >> >> - Is anyone aware of any public discussion on this? I have never seen it. >> >> Thanks, >> >> Giovane Moura
Re: Anyone else seeing DNSSEC failures from EU Commission ? (european-union.europa.eu)
I’m not sure what you’re talking about. DNSSEC is alive and well and protects DNS in-flight from modification. Any client with proper DNSSEC implemented will drop any forged DNS response from an attackers dns server and prevent them from loading whatever resource they were trying to access. Personally, I see DNSSEC as the perfect solution to the problem of the limited selection of third party resolvers outside the major players (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, Quad 9, and other major providers). Anybody can set up a recursive DNS server and start redirecting traffic whenever they please but if that the server has DNSSEC enabled then I’m going to have more trust that this server is not going to return bad records to me. The reason you see people have issues with it is because a lot of people aren’t reading through the entire implementation guidelines and making mistakes in their management of it. I have been running DNSSEC across a majority of my domains and while I can’t make claim to any “attacks” that may or may not have been stopped, I have never suffered an outage because of DNSSEC. I have a script that runs every night at midnight on my DNS servers that sign my zones every night at midnight and updates my serials to the current date+00 (eg today would be 2021120900) to prevent my signatures from aging out. If ICANN can automate the signing of the Internet roots every night at midnight, you can too. If your “auditing” is based solely on when your serial numbers have changed then I’m sorry but that is not proper DNS change auditing, don’t fool yourself. Ideally the server you use to sign your DNS zones should NOT be the same servers you expose publicly onto the Internet to prevent your keys from getting stolen and attackers changing your records without your knowledge. In response to what happened to NetNod, if hackers are able to get into your domain registrar you have much bigger problems and you need to move away from that registrar as fast as possible. Anybody who is not implementing 2FA and is running a domain registrar is not taking your domain security seriously and do not deserve your business. Best, Francis Booth > On Dec 9, 2021, at 9:36 AM, Ca By wrote: > > > > On Thu, Dec 9, 2021 at 1:07 AM Arne Jensen wrote: > Den 08-12-2021 kl. 15:32 skrev Niels Bakker: > > * 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. > I find it hard to believe that CloudFlare would do such though, however, > while such kind of things could indeed be the cause, I'm personally > going towards "Rather safe, than sorry". > > > > It's been quite common for DNSSEC-enabled recursors to add overrides > > for outaged domains in situations like this. > > Unfortunately, yes, overrides are too common for many different things. > Time for them (the overrides) to die completely. > > Or accept that dnssec has always been dead since it never solved a problem, > but created a lot of problems. > > Just saying, facts are on my side. Check the number of times dnssec caused an > outage. Then check the number of hacks prevented by dnssec. Literally 0. > > Be sure to note the time Netnod got hacked because the perps… turned off > dnssec… > > https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread-dns-hijacking-attacks/ > > Look, i dont have anything personal against dnssec. Just as much as any > droid, i love > > 1. 3rd rate crypto > > 2. Many enabled RCEs > > 3. Complex architectures , doubly complex operational procedure > > 4. Government managed CAs and then related procurement requirements > > But, the thing i dont like is the massive ddos it creates. Those huge records > are really not acceptable into today’s dns environment. > > Please stop enabling dnssec on your domain folks, you are going to have > outage, your security is worse off, and you feeding the vendor / hacker ddos > death spiral > > > > > > > It looks like the error has been mitigated, by the way, so this manual > > override may not even have happened. > > +1. > > -- > Med venlig hilsen / Kind regards, > Arne Jensen
Re: Redploying most of 127/8 as unicast public
> On Nov 20, 2021, at 6:35 PM, Matthew Walster wrote: > > I genuinely believe we're reaching a stalling point for IPv6 service > enabling, and it's time to focus energy on running IPv6 only clients -- and > to do that, we need to make the IPv6 only experience for residential / soho > be as pain-free as possible, no extra knowledge required. If I may play devils advocate, Google’s WiFi pucks did something I thought was interesting that I have not seen replicated by others that may or may not be of use to us in this regard. By using a local DNS resolver running on the main WiFi puck in the network, they handed it out via DHCP for clients to use which helped resolve a local webpage that showed devices that were connected to the local network by navigating to “on.here” inside a web browser. That got me thinking, So we know RFC 2606 defined reserved TLDs like .lan and .home so there is already a known list of .TLDs that we know would be safe to use in local scope, and besides the people who are already doing their own thing eg: people running PiHole or similar service inside their networks, or those who insist on setting their DNS servers static, everybody else should be defaulting to whatever is being handed out by their routers' DHCP server so keeping that in mind what if we did something like this: In order to solve the chicken/egg problem of having to know your IPv6 prefix and the address assigned to your router dynamically for nontechnical users to reach their router configuration pages, the router can run a local DNS resolver for the “.lan” TLD by default that it hands out through RDNSS in it’s RAs. Since the router is the “first” device in the network, it should always take the “router.lan” entry for itself and populate it with its IPv6 address. (Obviously proper inbound filtering should prevent external hosts out on the Internet from reaching the router configuration page.) Local devices will then be able to resolve and reach stuff from within the internal network by hostname. Since the router would also be the first device to become aware of any IPv6 prefix change from the ISP, it lends itself to loop this prefix update into the same processes it would use to update the router’s RA configuration back to the clients and to update it’s local DNS entry for “router.lan”. Best case scenario the prefix update will happen fast enough that it goes unnoticed and clients see minimal disruption. I feel users may find this method preferable in comparison to the old method of “type in 192.168.1.1 in your browser” where those instructions were not always 100% accurate due to some vendors deciding to use a different variation of private range addresses (I’m looking at you 192.168.0.1, and 192.168.100.1). Everybody would be able to quickly find their routers regardless of vendor, model, firmware version, or ISP. So (in theory) we have a reliable method of discovering our router configuration page without any prior knowledge of our IPv6 prefix, the IPv6 address assigned to ourselves, or that of the router. We could possibly even support dynamic DNS entries for connected devices that used DHCPv6 (Android obviously not able to take advantage of due to lack of support) to request addresses from the pool. As long as vendors set unique hostnames that don't overlap at the factory or attempt to re-use simple hostnames like chromecast.lan (sorry, I’m picking on Google a lot here.) where the potential for multiple devices to be named the same could occur, I can’t imagine that occurring in Residential / SoHo networks all that often but the potential for it is cetainly there. But this solution is by no means perfect, there are various situations I can think of where this kind of automation may break down and not work entirely as anticipated, eg: devices joining the network with device MAC address randomization turned on which I know is a default on certain devices and OSes (Android 11 comes to mind), or networks where the administrators do not want to allow joined devices to create their own dynamic DNS entries into the zone, but I digress, those environments are outside the scope of who this is designed for. I hope others may take inspiration from this idea and maybe expand upon it or even get inspiration to design something that better fits the bill for what you’re looking for. Feedback is always welcome. (Sorry to Matt and Owen who got this message twice. I originally sent this reply from my secondary address that is not subscribed on the list and the original reply got rejected) - Francis Booth boo...@boothlabs.me
