Some Fritz!Box modems might have been hijacked | Hacker News Reader

Some Fritz!Box modems might have been hijacked

crapts.org

236 pointsmmcnl130 comments

This is a good reason to use domain names with a trailing dot, right? Such as https://news.ycombinator.com./ to specify a FQDN, instead of https://news.ycombinator.com/ which is not fully qualified. The trailing dot keeps the DNS resolver from trying system domain suffixes.

In this case, that won't help, because `.box` is already a TLD and `fritz.box` has been registered by someone. Compare these two, the first is from my laptop connected to a Fritz!Box, the 2nd. one is from a server that's not connected to any sort of Fritz!Box:

Expected result, resolved by the box itself:

    $ host fritz.box.
    fritz.box has address 192.168.178.1
    fritz.box has IPv6 address fd00::e72:74ff:fece:6656
    fritz.box has IPv6 address 2a02:908:616:a8c0:e72:74ff:fece:6656

Result if for some reason, DNS resolution fails on the box (e.g. you're not connected to your own network, someone disabled the resolver on the box, someone configured a non-box DNS on your machine):

    $ host fritz.box.
    fritz.box has address 45.76.93.104
    fritz.box has IPv6 address 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828

Your query results make sense, since the Fritz!Box is authoritative for the (local) .box tld. Try again with google.com and google.com. If you're using Windows, it should append .fritz.box to the former, which is the issue here.

I'll note that many websites do NOT support this:

https://duckduckgo.com./ - blank page

https://www.google.com./ - 301 redirect to non-trailing-dot

https://www.amazon.com./ - works

But even "works" means that the page makes lots of requests to other subdomains etc which do not have the trailing dot, so are still vulnerable for DNS hijack if you have search domains set on your system. So while using domains with a trailing dot is a strongly good idea for calling APIs, etc. it is not a practical solution for the end user with a web browser.

Hm, curious behavior on my Windows box: nslookup is indeed always applying all the search suffixes whenever I do a lookup, but if I just use the normal resolution process (for example running `ping www.google.com` etc), then the value of `HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName` is respected, which defaults to 0 since Vista.

So this shouldn't really be an issue for most people, but highlights once again that you should never ever use a domain in your infrastructure that you do not own or at the very least use one of the suffixes from https://www.rfc-editor.org/rfc/rfc6762#appendix-G

Can we be absolutely sure the "normal resolution mode" is always used? I'm happy to accept that impact might be not as severe as stated, but to me it's very scary that a simple nslookup for google.com returns the IP address of fritz.box.

I replaced a Fritz.Box many years ago and a Windows-based laptop I have here still tries a lookup to frit.box every few seconds.

It's Monday morning here and I just started the laptop. It's still doing lookups on fritz.box.

Does anyone know where and why Windows is requesting this?

That matches my observation on Windows 11. Looking at wireshark while doing the resolution I see the following: Normal queries never use the the suffix. nslookup does, which the resolver answers with NXDOMAIN

Fritz box allows you to capture traffic towards the ISP too and there I never see such a suffix query in either case. So I assume the fritz resolver directly responds to those.

That does not really match the behavior described in the OP but I would be very surprised if the behavior described there wouldn't have lead to a big outcry much earlier.

I am just not interested in a router that isn't running open source firmware ever again. Not only do they have all the features you might need but the updates keep coming alongside all the nice security patches. I wish more WiFi devices for access points got their code into the kernel quicker so the support was more extensive.

Fritzbox was one of the first open source modem/router combo boxes though. They closed the source a few years back, but in terms of openness there really is nothing else in the modem/router combo space that is actually open source.

Most people who want a router with open source firmware get one that's compatible with OpenWrt and use that, is there a reason you don't consider that to be using open source firmware?

Router. I'm asking about a modem, or a modem/router combo that every company makes, but doesn't exist in the open hardware world.

I love my wrt54gl as much as the next guy, but I hate having two devices to connect to the internet instead of just one.

Search forums local to your country and write documentation on how to use Linux or BSD as a modem.

For OpenBSD on Orange France FTTH: https://lafibre.info/remplacer-livebox/remplacer-sa-livebox-... or https://try.popho.be/securing-home2.html

That link forever hangs for me :-(

The last time I searched for open hardware, even the implementations running Linux on a desktop PC with a caux adapter were not DOCSIS 3.X compatible.

The companies that multiplex the signal down the cables keep updating their standards, both a blessing (for speed) and a curse for maintained code

wrt54gl in 2024 hahahahahahahahahahahahaha

Helpful. It's still a champion of customizability and supports most major network modes, meaning you don't need to chuck your old wifi devices away. I still have most of my hardware from a decade ago running, and the WRT54GL serves them all quite well as a repeater.

https://openwrt.org/toh/avm/fritz.box.wlan.3370

VDSL2 Modem with Kernel support. With OpenWRT and mainline Kernel its able to push roughly 100Mbit/s over WAN.

That's incredible! Looks like an oversight by AVM if they patched it in a later firmware.

I wonder if I can find a device not fully upgraded

Not even the Omnia from Turris? I still one to buy one of these but they are not cheap.

This particular hijack has little to do with being open/closed source (Fritz!Box was open source for many years though). They have been around forever, I don't think custom TLDs such as .box were a thing when they chose fritz.box as the default name.

But they were a thing for the past 12+ years when they manufactured most of the routers that are currently in service.

It has everything to do with being open/closed source. If it were open, you could trivially fix this behavior. Instead, and I quote:

"the DHCP server on these modems hands out leases with the DNS suffix fritz.box, which means that domains in DNS requests are appended with the suffix. Unfortunately, this setting cannot be modified...

...The only proper way to resolve this matter in my opinion is to disable the DNS suffix by default. So far there is no indication that AVM is planning to enable this option in the near future."

Well yeah, quick mitigation is easier with open source. But the cause is still entirely on the gTLD mechanism itself. The ability to register gTLDs such as .zip is ridiculous and opens up this sort of phishing and hijacking in absolutely unforeseen places.

I miss guest WiFi from FOSS solutions. I can't even find a guide quickly for VyOS, and this is the one for OpenWRT: https://openwrt.org/docs/guide-user/network/wifi/guestwifi/g.... I fear that if I go down in this rabbithole, it's going to be like my homeserver, but on steroids. The $40 Tenda I use have it out of the box though, and if they stop updating it some years later, I just might buy another $40 something.

Wait a second. Does that mean every DNS request on a Fritz Box network is send to fritz.box first?

I query google.com and get google.com.fritz.box every fucking time? Shit.

Yes, on Windows at least. As far as I know, Linux and macOS only use the DNS suffix for domains without a dot in the domain.

If your upstream recursive resolver does QNAME minimization, then the only query that will leak beyond them is for "com.fritz.box", and because that's a NXDOMAIN, no further query for "google.com.fritz.box" is made.

If your upstream recursive resolver doesn't do QNAME minimization, then yes.

Edit: I stand corrected, see downthread

that’s no saving grace. the fritz resolver would return a result for com.fritz.box so that it can see the full (or next successive) part of the query. qname minimization is useful to defend against on path interception, or data collecting resolvers, not against actively hostile resolvers

Completely agree that it creates an unacceptable risk if the fritz.box owner is malicious. I'm just pointing out that currently, com.fritz.box doesn't appear to resolve.

Edit: actually, I'm wrong, "NS? com.fritz.box" returns a NOERROR + fritz.box SOA instead of a NXDOMAIN, which causes QNAME minimization to make the full query, which returns an A. QNAME minimization indeed doesn't actually help.

It resolves for me:

com.fritz.box. 3514 IN AAAA 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828

com.fritz.box. 3600 IN A 45.76.93.104

no, not every request. only those that don’t exceed `ndots` number of dots, typically 1 for unix like OSes. so google.com will not have fritz.box appended

This is not true for Windows unfortunately. Even a lookup for google.com will have fritz.box appended. I added a screenshot to the article for clarity.

I don't get that on Windows 11, with a FRITZ!Box that's mostly using the default settings.

Server: fritz.box Address: fd00::[etc]

Non-authoritative answer: Name: google.com Addresses: 2a00:1450:4001:80b::200e 172.217.19.78

That's interesting.

Can confirm, fritz.box only gets suffixed for names on the local network, which my Fritzbox 7490 is the authoritative name server for.

Just checked, systemd-resolved doesn't even support that behavior anymore[1], so any multi-label FQDN will get resolved without appending the search domain.

So that's still a mess, but no mess of "rip apart the entire home network right now".

1: https://www.freedesktop.org/software/systemd/man/latest/syst...

Yeah just sounds like a series of horrible decisions. Hardcode appending a suffix to every DNS request and then not securing the tld? What the shit?

I'd guess it was a decision made a long time before gTLDs came into vogue, maybe a very long time before.

If there's a list of falsehoods programmers believe(d) about DNS, "that TLD will never ever resolve, not ever" should be somewhere near the top.

> that TLD will never ever resolve, not ever

There are domains that will never be sold, but none of them are very sexy. RFC2606+RFC6761 list .example, .invalid, .localhost, and .test, but none of those are practical and some come with certain behavioural expectations. There's .home.arpa as well (RFC8375), which may be the most technically correct TLD to use for these domains, but also is one of the least marketable ones.

Then there are the IDN test TLDs (إختبار, آزمایشی, 测试, 測試, испытание, परीक्षा, δοκιμή, 테스트, טעסט, テスト, பரிட்சை, let's hope my browser+HN did the RTL mixing right) that also probably won't resolve, but most users probably won't be able to enter any of those websites.

AVM could've offered mDNS (if they don't already) and just use .local.

Hmm. My parents have one of these. Any advice on how to fix it? "Stop using it" obviously isn't an option.

- Does configuring a custom DNS server (like Cloudflare one) on your local computers solve it?

- On the reddit linked at the bottom of the article, someone mentions you can easily use this tool https://www.mengelke.de/Projekte/FritzBox-JSTool to edit the configuration file and change the domain. If that's true, why is the article claiming it's impossible to change?

> Does configuring a custom DNS server (like Cloudflare one) on your local computers solve it?

No. If anything, that'd make it worse. The issue reported in TFA is that Fritz!Boxes by default resolve the domain `fritz.box` to themselves for their admin interface, even if that domain has been registered on the public internet by someone else. If you configure cloudflare, you'll prevent that, which will _always_ get you the potentially attacker controlled DNS results.

There is a 2nd issue.

If you have a local machine called "myshare" and you mistype "myhsare", it may resolve to the attacker's machine.

As far as I know, this changes the hostname of the modem, but it doesn't change the DNS suffix in the DHCP server.

(PS. I am the author. The article is my understanding of the situation but if I'm wrong on some parts please correct me.)

>"Stop using it" obviously isn't an option.

we're only talking about the cost of a commodity modem, so buy a new modem, disconnect old is a potential solution

Not exactly, for some ISP's, internet only works with Fitzbox. For other modems, you need to go through months worth of to and fro with ISP to even get them working

A lot of ISPs will not give out their configuration options and handshake credentials to force you to use their provided equipment only.

This is not true in germany where FritzBoxes are most prevalent.

FritzBoxes are used as voip server/bpx, printer server, nas, and home automation. And probably more. (German) telcos provide specific FritzBox configuation instructions (select correct sub-branch of provider and contract kind), adding the quest to get real connection data to the attempt to migrate to anything standardized.

Switching to something else is not as easy as buying a new modem for most normal people.

Block 45.76.93.104 and 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828 at the firewall if possible.

Setup a local DHCP server, and don't set the fritz.box search domain.

Ensure that DNS-over-HTTP (DoH) is enabled where it can be.

Set upstream DNS servers that block malware, such as 1.1.1.2 or NextDNS

Delete "fritz.box" from the domain search list in DNS settings.

Educate your parents to be cautious about directly typing domain names or searching from the OmniBox.

https://nextdns.io/

https://blog.cloudflare.com/introducing-1-1-1-1-for-families...

Caution about directly typing domain names is exactly the opposite of what we've told people for twenty years.

"Direct dial" was never a good idea.

There is a class of internet users that doesn't use a search engine, and instead types things like "usedcarsdetroit.com" in the URL bar until they find something they want.

And there is the class that starts with a single word search like "cars", which can't go straight to Google. It instead has to see if "cars.fritz.box" exists, because perhaps there's a server called "cars" on your network.

And god forbid that your parent types "bankofmerica.com" instead of using a bookmark or their smart phone app.

Also the class that types “Google” into the browser’s search field (back when it was separate from the URL bar).

>Educate your parents to be cautious about directly typing domain names

First it was not clicking links. Now it's not typing addresses?

Jesus Bloody Christ my dude, maybe it really was a mistake to make sand think.

flash it with OpenWrt

Too bad, I tried to buy that domain some years ago as soon as I got my first fritzbox. Back then, I did not find a registrar and did not invest much time in finding one.

I am running my own DNS server and configured the fritz.box zone.

Very unprofessional of the vendor to assign a public domain. Good reminder to always use https://www.iana.org/domains/reserved and maybe https://www.theregister.com/2018/02/12/icann_corp_home_mail_...

They should just release a firmware update that replaces the domain suffix and ultimately to make it configurable.

it wasn't a public TLD until this year when it was registered to be a web3 thing

It doesn't matter, it's never been a good idea to use a domain that isn't your own or a special-use domain. At some point this might have been a theoretical worry, but it was 13 years ago that ICANN started creating new TLDs by the dozen. There's very little excuse for not correcting this mistake for new hardware at some point in the past 13 years.

I have to admit that I got stung when google released .dev as HSTS only, although that was only for local testing.

I'm surprised that this company didn't realise that this was problematic before this happened. Also, if the response in the article is actually their only one so far, that's a "I'll never touch this company again" response. If they deal with it properly then it's just a bug.

Time to make the suffix configurable and default it to something standard like home.arpa (or .internal once it’s official) or a sub-domain thereof, AVM.

To me the root problem still seems to be that we use FQDNs virtually nowhere even though that is the intention. Linux and macOS not applying the suffix for multiple labels is just an implementation detail. Maybe we should standardise the behaviour and maybe it’s better to turn it around: consider everything an FQDN and provide an escape mechanism (e.g. an xx-- prefix or an escape TLD)?

Does not seem to be the case anymore: https://www.heise.de/news/Fritz-box-Domain-aus-dem-Verkehr-g...

The domain is still not owned by AVM so it's still hijacked.

As far as I can see, Heise assumes that just because there's a link to the URS, the domain is no longer under someone else's control. I can't find any confirmation that the URS has actually been invoked.

If I were someone trying to spy on specific users, or collecting data maliciously, I would host this HTML on my own server to confuse journalists.

Currently, every subdomain (up to any level, as far as I can tell) resolves to an IPv4 and an IPv6 address. I doubt ICANN would do this for seized domains.

Here in germany you often get a Fritz Box from your internet provider (preconfigured with access data). So for 99% of users, switching to another router is not an option because thats simply the device that came with their internet access. But apart from this issue those are really nice and capable devices.

You can use your own router in Germany, this is enforced by the regulation agency BNetzA. Your ISP must provide you with sufficient information to set it up.

I think it's fair to say the vast majority of users won't be able to pull that off. I doubt even half of them know what a router is, let alone that there are differences between models.

For those who know they can use their own modems, sufficient information must be available, but only a sliver of the people with AVM modems will have that kind of knowledge.

There is the class that fails at reading and adhering to IKEA instructions, yeah.

But this is something that ask the non-obvious things will get explained to you if you walk into a MediaMarkt to where modern routers are and queue in line for the area's sales person to get to you and tell you what to buy, and how to get your hands on the relevant access credentials/how to get the new one to connect to the ISP. You're forgetting that most installs of non-ISP-provided moderns for residential Internet are set up by the tech person of the household who quite possibly never heard of what a NAS is and why they may want one. Often the only paper manual thing in the box is literally the quick start guide that a motivated person who has what could be called "common sense" on treatment of/interaction with computing equipment. You know, the person who knows to check the plugs because they don't consider themselves above it but do know that it's one of if not the first thing they are asked if they can support.

Since 2016, ISPs in Germany are required by law to give you the access data to use third-party modems / routers. Apart from that, I like Fritzboxes, too - I don't use a PC as a router anymore since I first got one.

https://de.wikipedia.org/wiki/Routerzwang#Rechtslage_in_Deut...

Sure, but legally allowed and capable and motivated to do so are very different things. Most people I know don’t even change the preset wifi password of their router.

I've noticed my Synology NAS doing lots of DNS lookups for [synology service].synology.com.fritz.box.

Because I had *.fritz.box DNS blocked on my Cloudflare Zero Trust Gateway, these were returning NXDOMAIN, causing the NAS to fail during some operations (checking for software and packages updates, backups).

I've disabled the option "Apply the domain name provided by DHCP server" (Network | DNS | Advanced) and the NAS stopped these.

Now, this is a worry because that option is checked by default so how many Synology NAS could be trying to connect to these sub-domains? What if the block is removed and the new owner can actually create some of these?

More details: https://www.geekzone.co.nz/forums.asp?forumid=66&topicid=312...

I have a Pi-Hole w/ unbound upstream, and the pi-hole is set to conditionally forward requests to *.fritz.box to 192.168.178.1, but should not forward it outside (i.e. to unbound). Quote:

"You can also specify a local domain name (like fritz.box) to ensure queries to devices ending in your local domain name will not leave your network, however, this is optional."

This is in the Conditional Forwarding section to the Pi-Hole, so I assume it's OK.

Yeah, similarly I use Adguard Home and have this in my upstream config, so I'm hoping I'm safe from this: [/fritz.box/]192.168.178.1

https://www.mengelke.de/Projekte/FritzBox-JSTool allow changing the domain of the fritz box routers.

It should be enough to fix that issue

I was wondering when that .box TLD would become a liability for them.

Yeah. Now imagine the liability behind the .zip tld

I own a domain along the lines of 'invoice.zip', I thought it’d be fun. But so far, it’s just been useless and expensive.

Should I keep it? What are uses cases for such a 'misguided' domain? I thought about putting a blog on it but fear it’d get flagged as malicious left and right. It’d look odd to say the least.

If I don’t renew, scammers might get their hands on the domain.

> What are uses cases for such a 'misguided' domain?

Anyone who has invoice.zip on an email should see that as a clickable link if the url detection is right

Then for example you put a file on / of your domain that downloads a malicious .zip file

See where this is going?

I meant: legitimate use cases.

And I don’t buy into .zip being made part of automatic URL detection in tools, for all the illegitimate reasons it’ll be used for. Vendors of email clients, messengers and chat applications tend to stick to a core of well-known TLDs.

*shakes cane from porch* If I had my 'druthers, there would be zero new TLDs except for country-codes which indicate the a top-level legal jurisdiction over who gets to decide the rest of what happens under 'em.

'Course, that could still backfire this way if someone establishes the Republic of Boxsylvania and won't accept "bx". (Also not great if we enter into an era of unprecedented national mergers, splits, and renames.)

What is worse is that you cannot change your DNS domain from fritz.box. I looked in the settings many times and was unable to find how to do that.

I can't reproduce the "worst case" i.e. that if I ping "google.com" it gets first sent to "google.com.fritz.box". I'm on windows 10 and have a FRITZ!Box 7590.

If I ping "google.com" It just queries google.com If I ping a domain I have never visited it just does a query for that domain.

It only appends .fritz.box if I, e.g. only ping "google".

So maybe they fixed it? I also changed quite a lot of settings throughout the years.

Cache perhaps?

No, I think windows by default only applies suffixes to Domains with 0 dots maybe?

Yes, by default DNS suffixes are appended to short unqualified names only.

There's a registry key

  HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\DNSClient\AppendToMultiLabelName
  [default value - 0 (Do not Append Suffix)]

which resolver built into Windows (DNS Client) respects.

nslookup contains its own DNS resolver and does not rely on the resolver built into the operating system. The DNS (multi-label) query packets sent by the nslookup tool will append the domains listed in the suffix search order (or primary DNS suffix if the list is empty) irrespective of that registry key.

In summary, don't use nslookup to try to get insight into what actually happens when apps/services try to resolve names. ping is probably a better bet, at least it uses Windows resolver which honours the above registry key.

It seems the domain fritz.box has been suspended. March 5 was the first time this message got captured on archive.org[1]:

The Domain Name you have entered is not available. It has been taken down as a result of dispute resolution proceedings pursuant to the Uniform Rapid Suspension System (URS).

The fritz.box name servers also point to URS[2] name servers:

  Name Server: ursns1.viagenie.ca
  Name Server: ursns2.viagenie.ca

[1] https://web.archive.org/web/20240305162200/https://fritz.box...

[2] https://www.icann.org/urs-en

I cannot confirm this behavior. With a router running FRITZ!OS:7.57 configured to use Google's DNS (in the router only) I get the following on Windows 10

  > nslookup google.com
  Server:  fritz.box
  Address:  fd00::[redacted]

  Non-authoritative answer:
  Name:    google.com
  Addresses:  2a00:1450:4001:828::200e
            142.250.181.238

Update: the connection does have the DNS suffix, so according to the superuser answer linked in OP (which is the first result when looking up what a DNS suffix is), it should get appended to lookups on windows, but it looks like it isn't in my case.

  > ipconfig
  [...]
  Connection-specific DNS Suffix  . : fritz.box

I noticed a lot of comments explaining the same thing, but also some confirming my observations. So far it appears the issue is mostly present if you have configured a separate DNS server in the DHCP settings, e.g. DNS is resolved somewhere outside the Fritz!Box. I will investigate further and update the article.

Adding the following to your local systemd.network configuration file should resolve the issue:

  [DHCPv4]
  UseDNS=false
  
  [DHCPv6]
  UseDNS=false

But you will have to type the IP of the fritz box when you want to access the admin interface.

Is there a way to get a monthly/weekly/whatever announcement of just the new gTLDs coming out? I have never been able to find a method other than manually checking on ICANN.

I mean, what I found interesting that nobody in the company heard that they were registering .box domains.

I am no expert in this subject

https://newgtlds.icann.org/en/program-status/sunrise-claims-...

But it seems that they had

Trademark Claims Period: 13 September 2023 to 17 January 2024

To be fair, .box domains didn't have that much noise attached to them and 4 months is a relatively short period, but if this possible vulnerability had known then it's a little more negligent.

Best case scenario for them seem to be that they pay an undisclosed amount to a "random" that got lucky and bought that domain.

I find it interesting how a decision that may have looked totally innoxious something like 15 years before, was not future proof enough, I for one back then would not have imagined that ICANN would start registering every single TLD under the sun.

I can't find any specifics, but to my understanding it had been known for years that .box was a candidate TLD.

I would assume so, I find it crazy that they didn't file for this.

This is stupid clickbait title, and the article isn't even very precise. Yes, that whole fritz.box situation is known and bad. But the problem discussed here doesn't nearly apply to every situation. Specifically, the box's builtin resolver (which is still used by default by a lot of things) knows not to forward fritz.box requests to the outside. That is, `dig google.com.fritz.box` and everything else say NXDOMAIN when you're using the builtin DNS.

Out of curiosity, what happens with a custom DNS server but still using DHCP? Will the suffix still be used?

Ah, it was looking like that to me, thanks for confirming. Like, if I force dig to use some public DNS, I get the newly registered IPs but if I use my fritzbox as the DNS server, it gives me itself / NXDomains, except for hostnames configured on the local fritzbox.

That on top of the fact that my linuxes won't use the search domain unless explicitly asked for with a single-label DNS makes this a lot less scary.

I am the author and happy to make any corrections. In Windows performing a lookup for google.com returns the address of the fritz.box domain name.

PS C:\Users\Marco> nslookup google.com

Server: UnKnown

Address: 192.168.0.200

Non-authoritative answer:

Name: google.com.fritz.box

Addresses: 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828

45.76.93.104

How is this not bad?

Yeah but so many things bypass internal resolvers lately. VPNs, “private relay,” individual apps. DNS over HTTP. Local control over DNS is steadily being chipped away. The result is some apps will go out to public or vendor-controlled DNS in ways typical admin tools like ping and dig might not reveal

Skipping over the bad idea that this fritz.box-domain is for a bit, this seems like a pretty major failure on the part of ICANN to prevent name collisions. IIRC they had a whole bunch of plans and policies to prevent name collisions 10 years ago, but somehow a popular brand of modems failed to come up?

Having never played with one; if the firmware supports bridge mode that will treat the box as basically just a hop. Of course you'd have to have your own network gear behind it.

Other option, run your own DNS + DHCP stack, a pihole is pretty turn-key if you have a straight forward network.

AVM the Company behind the fritzbox is aware of this issue and are currently already in talks with the domain provider.

https://x.com/AVM_DE/status/1779155999204552897

This is mentioned in the article, and the article also states why only purchasing the domain is not an adequate solution.

My home router is an old PC running Linux with some extra 10G ixgbe cards. If you know how to configure it, I'm convinced there isn't a better way: the only real downside is the power use, and it's not that bad.

Most of Germany (and Czechia, maybe even Europe?) is still rocking xDSL lines, so at the very least you still need a modem.

Where did you find a modem card?

I tried to do that a few months ago too, as I'm already running a homelab server 24/7, but couldn't find any cards supporting vdsl nor cable

Or do you mean just as a wan connection/router? In that case... Sure, you can do that. I just don't see the value in that, personally.

I don't care about the L2 interface. I imagine I could twist my ISPs arm and spend a bunch of money to end up with the fiber line directly connected to a card in my Linux box... but why? The ISP's upstream equipment is just as vulnerable as a modem, and there's a lot more of it. That's not the point for me.

When I had DSL (and later DOCSIS), I just bought my own modems that weren't routers, and used ethernet to connect the Linux router (a raspberry pi 3 originally, yes the DSL was so slow it wasn't a bottleneck!). It was economical because Time Warner charged me something like $5/month to use their modem.

There's a lot of reasons I like having a Linux router, a short list:

* I have 10G internet from Sonic, in 2020 building a small Linux machine with ixgbe cards was cheaper than any commercially available 10G router with as many ports as I needed (4+). I get line rate through it, no problem.

* It runs an open source NAT implementation that is actually correct (although this is less of a problem with commercial routers now than it was back in the day...). Sadly, I don't have IPv6, but the same argument would apply there.

* I can run whatever DHCP server implementation I want.

* No web GUIs: I SSH to the thing and write config files.

* If it blows up, it's just Linux, and all the config files are in git: any machine will do, I don't have to worry about some commercial product disappearing and forcing me to waste an afternoon reinventing the wheel.

* I can build and run recent vanilla kernels with all the hardening options enabled. A Linux router spends 99% of its time in the kernel.

* The machine is actually fast enough to scan 10G traffic at line rate in software when I want to do that (it's doing all the routing in software, after all).

It's really easy, I'd estimate I spend 1-2 hours a year maintaining it.

Given the way mine (not FritzBox) chokes due to NAT being a little stupid when burdened with enough outbound IPv4 dialing, I'd like a PCIe DOCSIS 3.1 (and enough EuroDOCSIS 3.0 to get through bootstrapping, as the ISP doesn't yet support pure 3.1 moderns) modem... I may settle for a 2.5GBASE-T "classic" modern, though, despite the lost control over the TX queue. It's sadly not possible to just presume a TX speed and forgo backpressure from DOCSIS to the packet scheduler that has the knobs to never turn Internet usage off again just to stop other more sensitive Internet usage from lagging.

Even if you had a modem card, there are too many more potential queueing points upstream of it: what you're proposing here would never make any measurable difference in real life. The congestion that makes cable uplinks suck isn't happening at your modem.

If you want to run BitTorrent and game at the same time, the router can e.g. limit the BitTorrent flows to something below the minimum guaranteed TX rate, so you know there's no queueing on the modem.

A random anecdote:

Last time I had cable was on Time Warner in the US. It was interesting because they didn't do the token bucket style ratelimiting I've seen from every ISP I've had since: they'd play games with TCP to try and slow down big flows instead. It was weird.

So I wrote a little program that transferred files by sending the data over UDP at a constant rate disregarding loss, then reconciling lost bits later over TCP. That allowed me to get almost double the upload bandwidth I was theoretically paying for at the time!

But on Verizon FIOS, it didn't work at all, because they really limit bandwidth at the packet level instead of trying to trick TCP into slowing down.

My Fritz Box does not reply in that way. How come you indicate that _all_ Fritz Box Modems have been hacked and how do I know if I am affected? Apparently I'm not.

It's how the mechanism of DNS suffices works. Especially on Windows, because Windows rewrites all DNS requests with the suffix (even simple requests like google.com). To me it's surprising that somehow not everyone is affected. I only learned that in the comments here.

Can anyone explain the design decisions behind this product? Or can the design process be summarized as "let's light these matches and see what happens"?

.box domains can only registered since 2024.

Guess they didn't expect a .box-tld

Is there a place where one can sign up for announcements on new TLDs? I don’t want to sign up for every registrant under the sun.

ICANN newsletter may be a good starting point.

I have one of these but it's 10k miles away from me.... Gonna have to remind me this summer to look into it

Isn't a simple solution to simply blacklist fritz.box when using adguard or nextdns?

Another reason to point your Fritzbox to a Pihole/Unbounded combo device.

FWIW is it not easy for Fritz to remotely change the default DNS of their devices, similar to what Virgin/Sky/Vodafone modems have been doing for the past decade?

Fritz used to be open source, but they're not since also around a decade, so I would think it would be easy to for them to have a backdoor to all their modems like every other company does.

what happens in chrome, where afaik google's dns is the default?

I flagged this post because it's just spreading FUD (in the traditional meaning) at this point. The fritz.box domain had been registered in January, but someone (likely AVM) quickly contested the registration and it was disconnected in March. It is currently in the settlement and resale phase, so very likely AVM, the makers of Fritz! Box, will just buy the domain and ensure it responds NXDOMAIN to any query or something. While I still believe that using a non-reserved domain like 'fritz.box' as their internal domain and suffix is just dumb, they are aware of the issue and working on a resolution that appears sensible.

(I am the author)

The fact is that currently DNS requests are forwarded to an unknown entity. The matter is not resolved yet and there is no guarantuee it will be resolved. Imo there's no FUD here. I will happily correct any factual errors ofcourse.

huh, glad i swapped my fritzbox out about 6 months ago for a fanless opnsense.

Does this not just break all DNS-resolved internet traffic for these devices at this point? Seems like the resolvers for fritz.box. are resolving *.fritz.box. to 45.76.93.104. I would assume the affected (Windows?) clients aren't working at all when they get this kind of response for something like google.com.fritz.box.

I guess if the resolution fails Windows will fallback to a resolution without the DNS suffix, but I'm not entirely sure how it works, and what other operating systems do.

But the resolution doesn't fail, it just returns an incorrect A record. Have you tried it on a Windows PC?

OpenWrt For the win!

This is FUD, the domain was taken down by URS in March. https://www.heise.de/news/Fritz-box-Domain-aus-dem-Verkehr-g...

Nonsense. The domain is registered. https://who.is/whois/fritz.box

Also, this should be worth an email to abuse@namesilo.com, no?

Another reminder that if it's not a reserved (top level) domain it's not safe:\

Shouldn't the title say "can be" not "have been". Apparently this has been known for years.

Imo if DNS requests resolve to an unknown entity and you cannot change that behavior, your DNS resolution has effectively been hijacked, even if no harm is being done yet.

(PS. I am the author.)

Reply on news.ycombinator.com