Website laadt niet op Android, wel op andere devices

[Gaitman]

Mijn partner is fanatiek haakster.

De site https://www.creatiefmethaken.nl/ laad sinds kort niet op Android telefoons. Je krijgt hier in de diverse browsers (Chrome, Firefox, Samsung Internet) op Android de melding dat het IP adres niet gevonden kan worden.

Verander je de DNS naar Google DNS (8.8.8.8 en 8.8.4.4) dan werkt het wel. Echter de standaard DNS van de Android telefoons zijn hetzelfde als die van de notebooks waarop het wel werkt. Namelijk die van de lokale router.

Er zijn meerdere gebruikers van deze site met dit probleem.

Ik verwacht als een tweaker het hier probeert op zijn notebook en daarna op zijn Android telefoon dat diegene hetzelfde probleem heeft.

We hebben hier trouwens Xs4all. Maar als ik de WiFi op de telefoon uit zet en van 4G (KPN) gebruik maak dan werkt de site ook niet.

Iemand een idee wat het kan zijn? Ik vind het een vaag probleem aangezien de site niet werkt op Android telefoons terwijl die van dezelfde DNS gebruik maakt. Tenzij de DNS word aangepast.

[Wintervacht]

Hier kan ik m op android via de router inderdaad niet bereiken (ziggo) maar via 4g wel (tmobile/ben).
Het ligt dus niet aan een netwerkinstelling maar is waarschijnlijk alleen op tenlossen door de beheerder van de website, als het domein niet gevonden kan worden door bepaalde dns servers van sommige ISPs.

[Gaitman]

Wintervacht schreef op zondag 26 mei 2019 @ 12:50:
Hier kan ik m op android via de router inderdaad niet bereiken (ziggo) maar via 4g wel (tmobile/ben).
Het ligt dus niet aan een netwerkinstelling maar is waarschijnlijk alleen op tenlossen door de beheerder van de website, als het domein niet gevonden kan worden door bepaalde dns servers van sommige ISPs.

Ja ik dacht ook dat het kwam door de DNS. Echter als ik mijn Android telefoon die op dezelfde WiFi zit als de notebook en dus dezelfde DNS gebruikt dan werkt het op de telefoon niet en op de notebook wel. Of mis ik hier mogelijk iets?

[Zanbee]

Hier op een Oneplus 6T met Pihole en Ubound als DNS Server geen enkel probleem kan de bewuste website prima bereiken met XS4All als provider.

[Gaitman]

Zanbee schreef op zondag 26 mei 2019 @ 12:54:
Hier op een Oneplus 6T met Pihole en Ubound als DNS Server geen enkel probleem kan de bewuste website prima bereiken met XS4All als provider.

Ja maar dan gebruik je dus ook een andere DNS server. Dat werkt hier ook.

Ik kom er net achter als ik alleen Google DNS 8.8.8.8 gebruik dat de site dan niet werkt. Gebruik ik 8.8.4.4 dan werkt het wel. En als je op Android de DNS handmatig wil instellen dan zie je ook als eerste 8.8.8.8 staan. Dus mijn vermoeden is dat op Android 8.8.8.8 als eerste word gebruikt.

[ Voor 31% gewijzigd door Gaitman op 26-05-2019 13:01 ]

[Zanbee]

Ook met 8.8.8.8 als dns ingesteld op mijn 6T en browse geschiedenis volledig gewist geen enkel probleem om de website te bereiken. Ook via Vodafone geen probleem. Op een LG G5 telefoon met een XS4All data sim kan ik de website niet bereiken ook niet via wifi en Pihole server.

[DukeBox]

DNS van die site klopt niet, heeft zowel een cname als een A record voor www.creatiefmethaken.nl

[Hackus]

@Gaitman Heb je al een melding bij deze site gemaakt, of ben jij de beheerder ?
(met Apple gear geen problemen)

[ Voor 16% gewijzigd door Hackus op 26-05-2019 13:33 ]

[Gaitman]

DukeBox schreef op zondag 26 mei 2019 @ 13:21:
DNS van die site klopt niet, heeft zowel een cname als een A record voor www.creatiefmethaken.nl

Dat heb ik niet gezien. Hoe heb je dat gecheckt?

Hackus schreef op zondag 26 mei 2019 @ 13:32:
@Gaitman Heb je al een melding bij deze site gemaakt, of ben jij de beheerder ?
(met Apple gear geen problemen)

De beheerder is op de hoogte maar die geeft de schuld aan een virus op Chrome.

[DukeBox]

Gaitman schreef op zondag 26 mei 2019 @ 13:43:
Dat heb ik niet gezien. Hoe heb je dat gecheckt?

Kan met van alles maar gewoon nslookup geeft:
www.creatiefmethaken.nl internet address = 81.171.2.80
www.creatiefmethaken.nl canonical name = creatiefmethaken.nl

[Wintervacht]

Gaitman schreef op zondag 26 mei 2019 @ 13:43:
[...]

De beheerder is op de hoogte maar die geeft de schuld aan een virus op Chrome.

het moet niet gekker worden, zeg dattie gewoon ff zijn dns record fixt of laat fixen, het is toch in zijn eigen belang dat er bezoekers komen zeker?

[RobIII]

Wintervacht schreef op zondag 26 mei 2019 @ 13:58:
[...]

het moet niet gekker worden, zeg dattie gewoon ff zijn dns record fixt of laat fixen, het is toch in zijn eigen belang dat er bezoekers komen zeker?

Dit zijn van die figuren die het eerst op een virus gooien en totdat ze overladen zijn met bewijs stug dat blijven volhouden. En als ze dan eindelijk "om" zijn gaat er een mail naar hun hoster dat ze waarschijnlijk gehacked zijn ipv "Help, er is iets niet goed met m'n DNS records, wat doe ik verkeerd?". Verwacht dan ook vooral niet dat het snel opgelost zal zijn.

[ Voor 5% gewijzigd door RobIII op 26-05-2019 14:04 ]

[Wintervacht]

RobIII schreef op zondag 26 mei 2019 @ 14:03:
[...]

Dit zijn van die figuren die het eerst op een virus gooien en totdat ze overladen zijn met bewijs stug dat blijven volhouden. En als ze dan eindelijk "om" zijn gaat er een mail naar hun hoster dat ze waarschijnlijk gehacked zijn ipv "Help, er is iets niet goed met m'n DNS records, wat doe ik verkeerd?". Verwacht dan ook vooral niet dat het snel opgelost zal zijn.

Hee het maakt niet uit hoe het gebeurt, als er masr wat aan gebeurt

[AW_Bos]

RobIII schreef op zondag 26 mei 2019 @ 14:03:
[...]

Dit zijn van die figuren die het eerst op een virus gooien en totdat ze overladen zijn met bewijs stug dat blijven volhouden. En als ze dan eindelijk "om" zijn gaat er een mail naar hun hoster dat ze waarschijnlijk gehacked zijn ipv "Help, er is iets niet goed met m'n DNS records, wat doe ik verkeerd?". Verwacht dan ook vooral niet dat het snel opgelost zal zijn.

Beste oplossing: Zeg tegen zulke mensen dat ze maar contact moeten opnemen met hun webhostingprovider, en die mail maar naar hun moeten doorsturen.

Edit:
Rob heeft gelijk
Terwijl ik vriendelijk uitleg geef en vraag of ze mijn bevindingen kan doorgeven aan haar hosting, krijg ik ene mail met daarin: "dat ze mij niet kent" (joh, het is mail, dan kan dat), en ""dat ze op zondag niet op commentaar staat te wachten" (joh, mail maandag dan terug), "en dat de site werkt" (eh, nee? de DNS niet!)


Sommige mensen zouden beter achter geraniums moeten zitten i.p.v. een laptop...

[ Voor 45% gewijzigd door AW_Bos op 26-05-2019 18:23 ]

[Gaitman]

@AW_Bos Bedankt dat jij ook een poging hebt gedaan. Verder iedereen bedankt voor het meedenken. We zullen even afwachten wat ze ermee gaan doen.

[AW_Bos]

Gaitman schreef op zondag 26 mei 2019 @ 19:29:
@AW_Bos Bedankt dat jij ook een poging hebt gedaan. Verder iedereen bedankt voor het meedenken. We zullen even afwachten wat ze ermee gaan doen.

Ik vrees dat een kort pittig kapsel inderdaad niet echt snel zal helpen
Ik heb wel vaker in dergelijke gevallen wel een aardige mail gehad. Ook eens bij een site van iemand die in de DNS foute verwijzingen naar IPv6 had staan. Werd netjes doorgegeven aan de hosting, terugkoppeling en een 'hartelijk bedankt! '

[ Voor 26% gewijzigd door AW_Bos op 26-05-2019 20:12 ]

[Joen]

DukeBox schreef op zondag 26 mei 2019 @ 13:46:
[...]

Kan met van alles maar gewoon nslookup geeft:
www.creatiefmethaken.nl internet address = 81.171.2.80
www.creatiefmethaken.nl canonical name = creatiefmethaken.nl

Ik doe dat altijd met de CentralOps.net Domain Dossier. Linkje voor de check voor www.creatiefmethaken.nl : https://centralops.net/co..._whois=true&svc_scan=true

Dan zie ik deze DNS entry's:
www.creatiefmethaken.nl IN CNAME creatiefmethaken.nl 86398s (23:59:58)
creatiefmethaken.nl IN A 81.171.2.80 86400s (1.00:00:00)

En hier zie ik totaal geen probleem in tegenstelling tot wat @DukeBox beweerd.
Het "main" domein is creatiefmethaken.nl met netjes een A-record naar het IP-adres 81.171.2.80.
Een CNAME-record mag nooit naar zich zelf verwijzen zoals @DukeBox waarschijnlijk denkt, maar dat doet het ook niet. Het is immers een CNAME-record voor www.creatiefmethaken.nl die verwijst naar het main A-record creatiefmethaken.nl (zonder www). Dit mag gewoon. Hence, mijn eigen website heeft deze constructie ook prima werkend.
Update 2: Met de bronnen er bij wordt duidelijk dat @DukeBox iets anders bedoelde dan ik dacht. Zie DukeBox in "Haaksite laad niet op Android telefoons"

Hier het zelfde beeld overigens:
- Op PC met Firefox via XS4All ADSL met IPv6 DNS-servers van Google prima te bereiken.
- Op Android 9 met Firefox Beta via XS4All ADSL met default IPv6 en IPv4 van FRITZ!Box 7590 / XS4All niet te bereiken.
- Op Android 9 met Firefox Beta via Simyo 4G prepaid niet te bereiken.
- Op Android 9 met Chrome via Simyo 4G prepaid heel kort een melding dat het niet te bereiken is en direct daarna word de website alsnog geladen.

Ik kan er nog niet helemaal de zere vinger op leggen, maar iets zegt mij dat er in het DNS gedeelte of netwerkgedeelte van de hostingpartij niet goed gaat.
Ik vermoed dat de nameserver van de hostingpartij problemen heeft.

Update 1:
Als ik een Tracert met de app Network Analyzer doe dan geeft www.creatiefmethaken.nl de melding "Failed to resolved IP address" en creatiefmethaken.nl geeft gewoon de volledige traceroute weer.
Als je de toegang tot de DNS-records heb zou ik gewoon de CNAME record van www.creatiefmethaken.nl vervangen door een A record met het zelfde IP-adres als de A record voor creatiefmethaken.nl. Als je daar geen toegang toe hebt zou ik een ticket aanmaken bij de hostingprovider.

Update 2: Met de bronnen er bij wordt duidelijk dat @DukeBox iets anders bedoelde dan ik dacht. Zie DukeBox in "Haaksite laad niet op Android telefoons"
Er zijn 2 conflicterende DNS entry's voor www.creatiefmethaken.nl. Òf een CNAME record moet verwijderen worden òf een A record.

[ Voor 22% gewijzigd door Joen op 26-05-2019 21:38 ]

[DJMaze]

Joen schreef op zondag 26 mei 2019 @ 21:03:
Hier het zelfde beeld overigens:
- Op PC met Firefox via XS4All ADSL met IPv6 DNS-servers van Google prima te bereiken.
- ....

Er is helemaal geen AAAA ingesteld in de NS van OpenProvider.
Verder zie ik ook de "dubbele" CNAME en A.

Gaitman schreef op zondag 26 mei 2019 @ 13:43:
De beheerder is op de hoogte maar die geeft de schuld aan een virus op Chrome.

Heb je hem/haar verteld dat hij/zij daarvoor software kan aanschaffen die dat probleem probeert te blokkeren op de beheerder zijn/haar computer?

[Joen]

DJMaze schreef op zondag 26 mei 2019 @ 21:27:
[...]

Er is helemaal geen AAAA ingesteld in de NS van OpenProvider.
Verder zie ik ook niet de "dubbele" CNAME en A.
(...)

Een AAAA record hoeft er ook niet per se te zijn. Het betekent alleen wel dan de website dan niet bereikbaar is voor IPv6 only aansluitingen. En dat is inmiddels al een steeds groter wordend probleem. Veel Nederlanders hebben in ieder geval IPv4 only of IPv4 èn IPv6. Maar binnen niet al te lange tijd zullen we ook de eerste Nederlandse IPv6 only aansluitingen gaan zien en dan is een website zonder IPv6 infrastructuur en AAAA records niet te bereiken.

[DukeBox]

Joen schreef op zondag 26 mei 2019 @ 21:03:
Dan zie ik deze DNS entry's:

Veelal wordt een cname niet gecached als er ook een A is. Je moet de authoritative servers queryen.
Bijv: https://www.digwebinterfa....4.4&ns=auth&nameservers=

[ Voor 24% gewijzigd door DukeBox op 26-05-2019 21:46 ]

[Joen]

DukeBox schreef op zondag 26 mei 2019 @ 21:31:
[...]

Veelal wordt een cname niet gecached als er ook een A is. Je moet de authoritative servers queryen.
Bijv: https://www.digwebinterfa....4.4&ns=auth&nameservers=

Thanks voor deze goede tip!
Nooi beseft dat CentralOps niet de volledige info laten zien. Ik zal deze website eens bij mijn favorieten zetten.

Dan zie ik daar inderdaad het probleem:

code:

creatiefmethaken.nl.    86400   IN  A   81.171.2.80
>> www.creatiefmethaken.nl. 86400   IN  CNAME   creatiefmethaken.nl.
>> www.creatiefmethaken.nl. 86400   IN  A   81.171.2.80

Het moet òf een CNAME òf een A zijn, maar niet beide. Als je zelf toegang hebt tot de DNS-records kun je het beste de A record weg halen denk ik. Zo niet, dan moet de hostingprovider de DNS entry's fixen.

[AW_Bos]

Een CNAME mag nooit naar dezelfde domeinnaam verwijzen, het is immers niet voor niet 'cannonical'
Echter vraag ik mij af waarom Chrome op de mobiel er enkel moeite mee heeft. Doet die bepaalde checks ofzo? Het lijkt niet aan de nameservers van 8.8.8.8 en 8.8.4.4 te liggen, als ik zo lees?

Ik hoop dat de beheerder toch eens in zal zien dat ze het aan de hosting moet overlaten, en niet zelf een dwaas advies van een 'lik-me-vestje' geeft omdat ze het beter denkt te weten....

[Gaitman]

@DukeBox en @AW_Bos Het blijft ook een gek probleem. Want zet ik op mijn telefoon de netwerkinstellingen van mijn Wifi op handmatig en zet ik dan daar de Google DNS 8.8.8.8 alleen in dan werkt het niet. Zet ik de Google DNS 8.8.4.4 erin dan werkt het wel. Zet ik op mijn desktop 8.8.8.8 als DNS erin dan werkt het wel.

https://www.digwebinterfa...vers=8.8.8.8%0D%0A8.8.4.4 geeft bij 8.8.8.8 en 8.8.4.4 ook dezelfde resultaten:

www.creatiefmethaken.nl@8.8.8.8 (Google)

code:

www.creatiefmethaken.nl. 21572  IN  CNAME   creatiefmethaken.nl.
creatiefmethaken.nl.    21572   IN  A   81.171.2.80

www.creatiefmethaken.nl@8.8.4.4 (Default):

code:

www.creatiefmethaken.nl. 21599  IN  CNAME   creatiefmethaken.nl.
creatiefmethaken.nl.    21599   IN  A   81.171.2.80

Ik ben overigens niet de beheerder van de site. Maar ze hebben nu een mededeling in hun Facebook groep geplaatst dat hun hoster er nu ook na gekeken heeft maar geen problemen kan ontdekken en dat ze dit vanaf meerdere locaties hebben getest. Maar uiteraard niet met Android....

Blijkbaar doet Android toch iets anders qua DNS

[AW_Bos]

Pffff......
Heb jij een linkje aan de facebookgroep?

Ze moeten gewoon die CNAME verwijderen en even wachten. Kan niet lastig zijn voor hun. Waarom Chrome op Android er niet mee kan omgaan lijkt niet het probleem van dit topic, maar eerder een bijzaak.

[ Voor 40% gewijzigd door AW_Bos op 27-05-2019 09:56 ]

[Gaitman]

@AW_Bos is een besloten groep waar het in staat. Maar de openbare is https://www.facebook.com/creatiefmethaken/

En onder hun bericht hebben ze de reacties uit gezet. Ze hebben wel het bericht dat het een virus i.c.m. Chrome zou zijn weggehaald. Ze hebben verder ook niet meer op mijn bericht gereageerd. Dus ben er nu ook wel een beetje klaar mee. Als ze niet willen luisteren dan maar niet. Het feit dat alle leden en niet leden die gebruik maken van Android en hun site niet kunnen benaderen vinden ze blijkbaar niet erg.

[AW_Bos]

Mja, dan maar even een bericht naar hun hosting gestuurd met de bevindingen uit dit topic.
Op internet zie ik bij DNS-checkers ook al waarschuwingen over CNAME's die gelijk zijn aan de domein, als ik die site invul.

Hopelijk is de hosting wel welwillend, en hoop ik dat sitebeheerder Annie (?) voortaan lekker gaat haken i.p.v. ongeïnteresseerd gaat mailen. Hier zakt toch echt je (gehaakte) onderbroek vanaf zeg

[AW_Bos]

Ik weet niet hoe snel het opgelost zal zijn, maar om even terug te komen op de materie die CNAME's heet.
De conclusie van dit topic luidt dus: Een CNAME (alias) mag niet overeenkomen met een de bestaande domeinnaam.

Maar waarom gaat Chrome op Android nou de fout in, en op een normale PC niet?
Bug in Chrome, of is Chrome op de mobieltjes gewoon strenger? Of heeft het te maken met een Android policy?

De RFC beschrijft het ook wel aardig, dat het niet mag:
https://www.ietf.org/rfc/rfc1912.txt

Wel bijzonder dat je met zulke DNS-fouten je site half onbereikbaar kan maken, en wat browser gerelateerd is.

[ Voor 22% gewijzigd door AW_Bos op 28-05-2019 01:11 ]

[Gaitman]

Het is opgelost. En ik zie ook dat er geen CNAME record meer is

Dus de DNS van de site klopte inderdaad niet. Wel een beetje aparte dat Android er blijkbaar anders mee om gaat.

[ Voor 46% gewijzigd door Gaitman op 28-05-2019 14:23 ]

[AW_Bos]

Eindelijk hebben ze het door...
Pffff...

Maar fijn dat het werkt.

[ Voor 24% gewijzigd door AW_Bos op 28-05-2019 15:18 ]

[DukeBox]

Gaitman schreef op maandag 27 mei 2019 @ 09:57:
Het feit dat alle leden en niet leden die gebruik maken van Android en hun site niet kunnen benaderen vinden ze blijkbaar niet erg.

Ik denk eerder dat het een combinatie is met Chrome op android. Er zijn nogal wat settings welke per device verschillen zoals dns prefetch, site/page prefetch, lite-browsing (mobile optimized / data saver) etc..
In het geval van een van die settings gaat resolving altijd via google (8.8.8.8 / 8.8.4.4). Andere resolves gaan via jouw DNS instellingen, meestal die van je ISP tenzij je deze hebt aangepast. Omdat niet iedere ISP dezelfde DNS server/software gebruikt en andere cache policies volgt is het letterlijk random hoe het antwoord binnenkomt.

Best kans dat bij de helpdesk ook iemand gewoon een lookup doet tegen een andere DNS server en daar correcte informatie naar boven komt en vervolgens wordt gecommuniceerd dat alles in orde is.
Dan wordt het toch best lastig als beheerder van een haak site waar IT waarschijnlijk niet de core business is om daar tegenin te gaan.

Misschien is het makkelijkst om ze gewoon een linkje naar dit topic te sturen

[AW_Bos]

Be my guest!

Ik ben nu wel klaar met de laconieke reacties van die hosting en met nadruk ook van die sitebeheerster (Ik: meld 'dit' en 'dat' aan je hosting), dat ik mijn tijd aan andere dingen spendeer
@RobIII had al gelijk...

Via 'mxtoolbox' konden ze prima de oorzaak zien, plus een screenshot van nslookup die ze niet eens zagen.

Wel ben ik benieuwd hoe Chrome zo raar doet. Ik ga eens kijken of ik deze fuckup ook op een test domeinnaam voor elkaar kan krijgen.

[ Voor 3% gewijzigd door AW_Bos op 28-05-2019 16:14 ]

[PerfectPC]

AW_Bos schreef op dinsdag 28 mei 2019 @ 01:08:
Maar waarom gaat Chrome op Android nou de fout in, en op een normale PC niet?
Bug in Chrome, of is Chrome op de mobieltjes gewoon strenger? Of heeft het te maken met een Android policy?

chrome data saver
smeerlapperij die standaard aan staat op android chrome, heb ik ook erg lang naar gezocht bij het debuggen van rare dingen die enkel op telefoons te reproduceren waren.

[DukeBox]

AW_Bos schreef op dinsdag 28 mei 2019 @ 16:13:
Wel ben ik benieuwd hoe Chrome zo raar doet.

Zie mijn post boven je.