Fritz.box verwijst soms naar externe site; niet gehackt.

[fondacio]

Gebruikers van een FRITZ!Box weten dat je met de URL fritz.box gemakkelijk naar de adminpagina van de router kunt gaan vanuit je browser. Zojuist werd ik echter naar een website met de domeinnaam fritz.box geleid in plaats van de adminpagina (die doorgaans op 192.168.178.1 zit, tenzij je een andere IP-range gebruikt). Omdat ik even bang was voor een hack, ben ik gaan zoeken en kwam ik op de volgende blog uit van een paar dagen geleden:

https://borncity.com/win/...ects-to-an-external-page/

De auteur heeft een woordvoerder van AVM te spreken gekregen.

[T]he fritz.box domain is currently in a sales process in which AVM is also involved. As a result, users may occasionally be taken to another inappropriate, harmless page when the URL fritz.box is entered in the browser.

Calling fritz.box in the home network is possible as usual and is the responsibility of the home FRITZ! box. Until now, users who accidentally entered fritz.box outside their home network received a browser error message or were redirected to a search engine. At the moment, users who accidentally call up fritz.box outside their home network are shown an obviously inappropriate and harmless page.

Het lijkt er dus op dat het feit dat er wordt onderhandeld over de verkoop van de domeinnaam fritz.box ervoor zorgt, dat je soms op een externe pagina terechtkomt als je de url in een browser intypt. Het blijft wel een beetje verwarrend, vooral omdat wat er in het vetgedrukte stuk staat, bij mij in elk geval niet klopt. Van binnen mijn thuisnetwerk kom ik op dit moment altijd op een externe pagina terecht. Ik hoop maar dat ze de verkoop snel afronden en het weer normaal wordt voordat ik een handmatige entry in mijn DNS-lijst moet gaan aanmaken.

[Kalentum]

Vaag, dan hebben we straks dus 2 fritz.box hosts: eentje als je achter een fritz.box zit en een 'echte'.

Ik krijg lokaal vooralsnog gewoon 192.168.178.1 maar daarbuiten:

code:

$ host fritz.box
fritz.box is an alias for site.my.box.
site.my.box has address 18.215.42.147
site.my.box has address 3.221.134.22
site.my.box has address 52.20.143.163
site.my.box has address 34.232.152.68

[MsG]

Het is natuurlijk vrij raar dat ze een publiekelijk beschikbaar domein gebruiken voor hun lokale router-url. Het is volstrekt logisch dat als je niet de dns van Fritzbox gebruikt maar een eigen dns-server optie dat deze voor het fritz.box adres de echte server opzoekt en teruggeeft.

Er zijn gereserveerde dns-namen voor intern gebruik, fritz.box is daar niet 1 van.

Ik vond het ook redelijk schokkend dat ik fritz.box niet kon aanpassen in mijn router. Zelfs mijn dichtgetimmerde Experiabox staat dat toe.

[DataGhost]

fondacio schreef op maandag 29 januari 2024 @ 15:51:
[...]


Het lijkt er dus op dat het feit dat er wordt onderhandeld over de verkoop van de domeinnaam fritz.box ervoor zorgt, dat je soms op een externe pagina terechtkomt als je de url in een browser intypt. Het blijft wel een beetje verwarrend, vooral omdat wat er in het vetgedrukte stuk staat, bij mij in elk geval niet klopt. Van binnen mijn thuisnetwerk kom ik op dit moment altijd op een externe pagina terecht. Ik hoop maar dat ze de verkoop snel afronden en het weer normaal wordt voordat ik een handmatige entry in mijn DNS-lijst moet gaan aanmaken.

Dit gebeurt als het goed is alleen maar als je eigen of alternatieve DNS-servers gebruikt en niet die die door je Fritzbox via DHCP wordt uitgegeven.

[AW_Bos]

Ja, een beetje vreemd is het wel inderdaad. Ik kom op een vage crypto-site ui die volgens mij best veel 'geslashdotted' wordt, gezien de vele gateway-errors.

Hebben ze een domeintje vergeten te verlengen bij AVM?

[Sharky]

DataGhost schreef op maandag 29 januari 2024 @ 16:05:
[...]

Dit gebeurt als het goed is alleen maar als je eigen of alternatieve DNS-servers gebruikt en niet die die door je Fritzbox via DHCP wordt uitgegeven.

Misschien niet gebruikelijk, maar ook zeker niet uitzonderlijk. Ik vind het nogal een risicovolle werkwijze.

[begintmeta]

Heise had hier ook al wat over geschreven. Inderdaad nogal slordig van AVM... IMHO onbegrijpelijk dat ze dit zo hebben opgezet, en dan ook nog eens laten gebeuren. Het zal ze nu vast meer kosten...

[DataGhost]

Sharky schreef op maandag 29 januari 2024 @ 16:08:
[...]


Misschien niet gebruikelijk, maar ook zeker niet uitzonderlijk. Ik vind het nogal een risicovolle werkwijze.

Snap ik, maar dan is de boel wel fout geconfigureerd. Het DNS-serveradres uitgegeven door DHCP is niet hetzelfde als de adressen die gebruikt worden voor het resolven. Als je een alternatieve resolver op de juiste plek instelt, dus bij Internet/DNS en niet bij DHCP (uitgifte waar je geen fallback kan instellen) en al helemaal niet als handmatige override op je client, dan zal het nog gewoon werken zoals bedoeld, waarbij de fritzbox dus als DNS-server fungeert voor het lokale netwerk en de lookups doet op de door de gebruiker ingestelde servers.

Staat verder los van dat ik het inderdaad geen goed idee vind om iets anders dan .local te gebruiken, ook al bestond .box tot recent nog niet.

[ Voor 7% gewijzigd door DataGhost op 29-01-2024 16:16 ]

[MOmax]

Ja, hier moet AVM inderdaad wel wat mee. Goed om te weten echter.
Nou ja, in 9-van-de-10 gevallen ging ik toch al via het IP adres.

[begintmeta]

DataGhost schreef op maandag 29 januari 2024 @ 16:15:
...
Staat verder los van dat ik het inderdaad geen goed idee vind om iets anders dan .local te gebruiken, ook al bestond .box tot recent nog niet.

M.b.t. .local wordt vaak gezegd dat dat weer in combinatie met mDNS voor problemen kan zorgen - of dat zo is weet ik echter nie/ligt aan het netwerk. Ik meen dat men bezig is met .internal, als intern TLD.

[Anoniem: 1777010]

begintmeta schreef op maandag 29 januari 2024 @ 16:23:
[...]

M.b.t. .local wordt vaak gezegd dat dat weer in combinatie met mDNS voor problemen kan zorgen - of dat zo is weet ik echter niet. Ik meen dat men bezig is met .internal, als intern TLD.

Ik had altijd .dev, die was lekker kort. Nu moet ik naar .local, maar dat is ookal fout. Straks wordt het .internal, nog langer bezig. What's next? .localinternaldevelopment?

[fondacio]

DataGhost schreef op maandag 29 januari 2024 @ 16:05:
[...]

Dit gebeurt als het goed is alleen maar als je eigen of alternatieve DNS-servers gebruikt en niet die die door je Fritzbox via DHCP wordt uitgegeven.

Klopt, ik heb een virtuele Pi-hole draaien. Aan de andere kant heb ik die wel ingesteld als DNS-server via de instellingen van de Frtizbox. Het zou misschien netter zijn als die zich vervolgens toch als de DNS-server identificeert om interne verwijzingen naar fritz.box alsnog over te kunnen nemen.

[begintmeta]

Anoniem: 1777010 schreef op maandag 29 januari 2024 @ 16:24:
[...]

Ik had altijd .dev, die was lekker kort. Nu moet ik naar .local, maar dat is ookal fout. Straks wordt het .internal, nog langer bezig. What's next? .localinternaldevelopment?

ik heb net even een beetje gegoogled: ".home.arpa" was ook een suggestie.

[ Voor 7% gewijzigd door begintmeta op 29-01-2024 16:30 ]

[DataGhost]

Gewoon .lan, .home of .internal dan. Die zijn daar ook voor gereserveerd.

[ Voor 12% gewijzigd door DataGhost op 29-01-2024 16:34 ]

[MasterL]

Zo ingewikkeld is het allemaal niet. Gebruik RFC6762 als je wil dat jouw device bereikbaar is zonder het gebruik van een (dedicated) DNS server, mDNS dus. Er staat AVM niks in de weg om fritzbox.local te gebruiken bijvoorbeeld. Ze gaan er bij AVM gewoon vanuit dat de FritzBox het centrum van het netwerk is (DHCP,Gateway,DNS,firwall,router) en dit is gewoon een slecht design. Werkt waarschijnlijk prima voor 98% van de gebruikers maar toch.. Mocht dit het geval zijn kunnen ze gewoon een firmware update pushen met een static dns entry toch? Nee als AVM zich gewoon aan de standaarden zou houden zou dit geen enkel probleem zijn.

[DataGhost]

MasterL schreef op maandag 29 januari 2024 @ 16:34:
Zo ingewikkeld is het allemaal niet. Gebruik RFC6762 als je wil dat jouw device bereikbaar is zonder het gebruik van een (dedicated) DNS server, mDNS dus. Er staat AVM niks in de weg om fritzbox.local te gebruiken bijvoorbeeld. Ze gaan er bij AVM gewoon vanuit dat de FritzBox het centrum van het netwerk is (DHCP,Gateway,DNS,firwall,router) en dit is gewoon een slecht design. Werkt waarschijnlijk prima voor 98% van de gebruikers maar toch.. Mocht dit het geval zijn kunnen ze gewoon een firmware update pushen met een static dns entry toch? Nee als AVM zich gewoon aan de standaarden zou houden zou dit geen enkel probleem zijn.

Als je een andere DNS-server gebruikt dan de fritzbox heb je ook helemaal geen toegang tot fritz.box en moet je het IP gebruiken of zelf een entry aanmaken in je DNS-server. Dus als je van het design afwijkt is dit sowieso je eigen probleem en ben je als het goed is kundig genoeg om hiermee om te gaan.

[begintmeta]

DataGhost schreef op maandag 29 januari 2024 @ 16:33:
Gewoon .lan, .home of .internal dan. Die zijn daar ook voor gereserveerd.

Zijn die "officieel" gereserveerd, of is gebruik als "officiele" internet-brede TLD geweigerd?

@DataGhost dank je; ze zijn geweigerd dus, maar ik neem aan dat men dat gezien de suggestie in de appendix We do not recommend use of unregistered top-level domains at all, but... .lan. zal blijven doen.

[ Voor 28% gewijzigd door begintmeta op 29-01-2024 16:40 ]

[DataGhost]

begintmeta schreef op maandag 29 januari 2024 @ 16:36:
[...]

Zijn die "officieel" gereserveerd, of is gebruik als "officiele" internet-brede TLD geweigerd?

https://datatracker.ietf.org/doc/html/rfc6762#appendix-G

Als het goed is mogen deze niet geregistreerd worden als TLD. Uiteindelijk komt dat allebei op hetzelfde neer.

[ Voor 16% gewijzigd door DataGhost op 29-01-2024 16:38 ]

[laurens0619]

Als de Fritzbox de upstream dns provider is, dan zou pihole het lokale ip van frtiz.box gewoon moeten serveren lijkt mij?
Tenzij je iets als Rebind Protection in pihole aan hebt staan

[ Voor 33% gewijzigd door laurens0619 op 29-01-2024 16:40 ]

[MasterL]

DataGhost schreef op maandag 29 januari 2024 @ 16:36:
[...]

Als je een andere DNS-server gebruikt dan de fritzbox heb je ook helemaal geen toegang tot fritz.box en moet je het IP gebruiken of zelf een entry aanmaken in je DNS-server. Dus als je van het design afwijkt is dit sowieso je eigen probleem en ben je als het goed is kundig genoeg om hiermee om te gaan.

Dan is er sowieso geen enkel issue...
Als ik jouw reactie goed interpreteer zijn er twee scenarios:
1: Je gebruikt de Fritzbox waar hij voor bedoeld is (consumenten router, DHCP, DNS Gateway etc)
dan werk het prima (static A record).
2: Je gebruikt andere apparatuur en kon je dit toch al niet gebruiken.

In welke van deze opties heeft de mogelijke registratie van het TLD .box invloed hierop?
Alsnog een dramatisch design natuurlijk.

[DataGhost]

MasterL schreef op maandag 29 januari 2024 @ 16:57:
[...]


Dan is er sowieso geen enkel issue...
Als ik jouw reactie goed interpreteer zijn er twee scenarios:
1: Je gebruikt de Fritzbox waar hij voor bedoeld is (consumenten router, DHCP, DNS Gateway etc)
dan werk het prima (static A record).
2: Je gebruikt andere apparatuur en kon je dit toch al niet gebruiken.

In welke van deze opties heeft de mogelijke registratie van het TLD .box invloed hierop?
Alsnog een dramatisch design natuurlijk.

Ik gok een of andere fallback op mDNS of zelfs netbios oid bij situatie 2.

[MasterL]

DataGhost schreef op maandag 29 januari 2024 @ 17:07:
[...]

Ik gok een of andere fallback op mDNS of zelfs netbios oid bij situatie 2.

Netbios is wel erg deprecated en mDNS gaat niet werken met een .box domain (native).
De enige manier waarop dit fatsoenlijk gaat werken is als de FritxBox ook de DNS server is en dit is gewoon out of spec. Kan werken..Kan ook niet werken.
Laten we niet vergeten dat FritxBox devices echt consumenten hardware is waarbij de FritxBox ook "alles" doet.

[AW_Bos]

Het valt mij wel op dat er opeens hsts afgedwongen wordt op mijn telefoon als ik https://fritz.box benader.
Volgens mij was dit eerder niet zo? Zou dit hiermee te maken hebben?

Ik had enkele jaren geleden een aantal lokale sites draaien op een .dev tld, die opeens ook op HSTS over ging. Later bleek dat Google die tld had overgenomen, en HSTS had gepushed naar alle browsers.

[ Voor 36% gewijzigd door AW_Bos op 30-01-2024 11:04 ]

[DataGhost]

begintmeta schreef op maandag 29 januari 2024 @ 16:36:
[...]

Zijn die "officieel" gereserveerd, of is gebruik als "officiele" internet-brede TLD geweigerd?

@DataGhost dank je; ze zijn geweigerd dus, maar ik neem aan dat men dat gezien de suggestie in de appendix We do not recommend use of unregistered top-level domains at all, but... .lan. zal blijven doen.

Anders is .internal misschien een idee?

[begintmeta]

@DataGhost, ik vermoed inderdaad dat dat er wel door zal komen, maar het is altijd even afwachten wat definitief wordt besloten. Eerder had men ook .home.arpa bedacht, maar dat is natuurlijk gewoon in allerlei opzichten minder dan .internal. (maar voor fritz.internal bestaat dan weer geen goede reden, dan is fritzbox.internal misschien beter (of iets waarbij internal past als productnaam?)

[ Voor 15% gewijzigd door begintmeta op 31-01-2024 08:46 ]

[vj_slof]

Ik krijg sinds enkele dagen de volgende melding in de syslog van een debian server binnen onze organisatie:

code:

Jan 31 10:00:02 prepress1 named[1224]: NOTIMP unexpected RCODE resolving 'fritz.box/HTTPS/IN': 20.231.95.96#53
Jan 31 10:00:02 prepress1 named[1224]: NOTIMP unexpected RCODE resolving 'fritz.box/HTTPS/IN': 20.228.226.240#53
Feb  1 10:10:57 prepress1 named[1224]: NOTIMP unexpected RCODE resolving 'fritz.box/HTTPS/IN': 20.228.226.240#53
Feb  1 10:10:57 prepress1 named[1224]: NOTIMP unexpected RCODE resolving 'fritz.box/HTTPS/IN': 20.231.95.96#53

Negeren of oplossen? De ip-adressen zijn van Microsoft? Wat moet dat daar?

[DataGhost]

Dat zijn volgens mij gewoon IPs van Azure, dus "van Microsoft" maar niet van Microsoft. Dat zijn de nameservers van 3dns.box. Ondertussen is fritz.box een CNAME naar example.com, misschien dat de NOTIMP te maken heeft met het verder resolven van dat record omdat je daar recursie voor nodig zou hebben, maar dat zou je eigen nameserver eigenlijk zelf goed moeten doen, dus misschien is het wat anders. Verder lekker negeren als je geen fritzbox in je organisatie hebt.

[vj_slof]

DataGhost schreef op donderdag 1 februari 2024 @ 10:43:
Dat zijn volgens mij gewoon IPs van Azure, dus "van Microsoft" maar niet van Microsoft. Dat zijn de nameservers van 3dns.box. Ondertussen is fritz.box een CNAME naar example.com, misschien dat de NOTIMP te maken heeft met het verder resolven van dat record omdat je daar recursie voor nodig zou hebben, maar dat zou je eigen nameserver eigenlijk zelf goed moeten doen, dus misschien is het wat anders. Verder lekker negeren als je geen fritzbox in je organisatie hebt.

Dat is 't 'm. Er staat hier wel een Fritz!box. Ik heb nu maar voor de zekerheid fritz.box in de Pi-hole naar het ip-adres van de Fritz!box op 192.168.2.254 gezet. Dit werkt vooralsnog prima op andere computers maar de desbetreffende server waar de melding in het logboek voorkwam gaat niet naar 192.168.2.254 als ik daar in de browser fritz.box typ... De server gebruikt wel de DNS van de Pi-hole want als ik een adblock-check op https://d3ward.github.io/toolz/adblock.html bezoek is 95% geblokkeerd dus het verkeer loopt over de Pi-hole denk ik dan.

[laurens0619]

Wat ik al eerder zei: Zet je rebind protection uit als je frtiz.boz wil laten herschrijven naar het lokale ip en de fritzbox upstream dns provider is van de pihole

[ Voor 19% gewijzigd door laurens0619 op 01-02-2024 11:28 ]

[vj_slof]

laurens0619 schreef op donderdag 1 februari 2024 @ 11:28:
Wat ik al eerder zei: Zet je rebind protection uit als je frtiz.boz wil laten herschrijven naar het lokale ip en de fritzbox upstream dns provider is van de pihole

Bedankt! Was even zoeken.

[XeRoExEz]

In deze thread ging het over hetzelfde en ik heb een (ergelijk)reactie ontvangen van AVM:
XeRoExEz in "'fritz.box' dhcp hostname veranderen"

[ahbart]

Ik ontdek net toch ook zoiets als hier omschreven.

Ik maak normaal verbinding met mijn vps via ssh. Inloggen gaat met sleutels en dus zonder wachtwoord.
Ik heb in .ssh/config de vps geconfigureerd als vps1.

Nu typte ik: ssh vps, en vergat dus de 1 van vps1.
Kom ik op een ssh inlogprompt, waarin ik mijn wachtwoord moet tikken. Dit klopt natuurlijk niet.

Kijk ik in adguardhome, om te achterhalen waar die vps naartoe verwijst. Zie ik in de query log:

code:

vps.fritz.box
A: 45.76.93.104 (ttl=3543) 
AAAA: 2001:19f0:6c00:1b0e:5400:4ff:fecd:7828

Blijkbaar is de vps.fritz.box geregistreerd als een server.
dns cloudflare gaf deze door.
Zouden daar nog veiligheidsrisico's aan zitten?