DNS servers Odido uit de lucht

Dank voor deze tip ​@Eniac, dit werkt inderdaad mooi!

Hopelijk komt dit in de toekomst niet nog een keer voor, gelukkig is het inmiddels opgelost en kunnen klanten met onze DNS ook weer online komen! 

​@Tommie van Odido Ben ik nou gek?

LeoS@Applepap ~ % nslookup www.google.com 84.241.227.81

;; connection timed out; no servers could be reached

De DNS geeft nog steeds geen antwoord.

kun je bevestigen dat 84.241.227.81 en 84.241.227.82 de default DNS adressen zijn?

Dank,

Leo

Voor mij 

Primaire DNS-server 37.143.84.228

Secundaire DNS-server 62.58.48.20

Zo staat het in de systeem-informtie in de router bij ETH_Internet. Maar ik maak verder ook gebruik van mijn eigen interne DNS (unbound).

Die twee nummers bij jou in hetzelfde subnet lijkt me wel raar want dat is geen goede fall-back. Als een faalt, faalt de ander ook. Normaal zijn die nummers veel verder uit elkaar.

Yikes. Je hebt inderdaad gelijk.

https://www.odido.nl/service/veelgestelde-vragen/wat-is-het-ip-adres-van-de-odido-dns-servers/000454242

Maar die zijn dus niet goed. Zou ook absoluut niet mogen dat die twee zo bij elkaar staan. Dat is echt geen goed DNS beheer.

​@Eniac Dat schijnen DNS servers voor mobiel te zijn. Niet voor het vaste netwerk.

Maar dan nog zijn het maffe nummers zo bij elkaar.

• DNS issues?

rvk01 schreef:

​@Eniac Dat schijnen DNS servers voor mobiel te zijn. Niet voor het vaste netwerk.

Maar dan nog zijn het maffe nummers zo bij elkaar.

• DNS issues?

 

De vraag is dus of die twee adressen die in de URL staan ook zo worden geprovisioned op de routers. Tot voor kort had ik de router DNS settings op de default instelling staan, dus wordt die router gevoed met informatie uit de Odido provisioning server. Aangeizien de router ook de DHCP server is voor mijn LAN connected devices gaat alles op z’n reet en zit de klant effectief zonder internet

​@Tommie van Odido, dit moet je escaleren. we moeten de juiste dns adressen geprovisioned krijgen op onze routers. 
Wil je in deze thread de correcte DNS adressen posten?

Nee, want dat zijn dus niet de juiste DNS server. Die 84.x.x.x zijn voor mobiel.

Je kunt de DNS die geprovisioneerd wordt niet zelf wijzigen bij de Odido firmware. Je kunt wel zien welke dit zijn. Kijk op het hoofdscherm onder systeeminformatie en scroll dan naar ETH_Internet. Daar staan de DNS server die geprovisioneerd zijn. Bij mij dus de  37.143.84.228 en 62.58.48.20. En zo hoort het ook… lekker ver uit elkaar zodat als er een faalt de ander misschien nog werkt.

Je kunt de geprovisioneerde DNS van de router zelf niet wijzigen. Het enige dat je kunt doen is de DNS die weer naar de clients doorgegeven wordt aanpassen. Dan is de router zelf geen proxy meer maar geeft ie b.v. 1.1.1.1 door naar de clients. Dat doe je dus bij Netwerkinstelling > Thuisnetwerken.

Kies je DNS-proxy dan wordt 192.168.1.1 als DNS naar de client gezet (zodat de router als proxy werkt). Kies je statisch dan kun je zelf 2 adressen opgeven. Kies je “Vanaf ISP” dan worden waarschijnlijk die DNS die onder systeeminformatie staan doorgezet naar de client. 

Standaard staat ie op DNS-proxy zodat de clients dus 192.168.1.1 krijgen, en de router zelf zijn eigen geprovisioneerde DNS gebruikt. Maar die kun je dus niet aanpassen.

De juiste DNS die ik dus krijg is 37.143.84.228 en 62.58.48.20. In dat andere topic staat dat de tweede 37.143.84.229 is, maar dat is tegenwoordig niet meer zo. Dat zou ook niet goed zijn want als .228 niet te bereiken is, is .229 waarschijnlijk ook plat. Vandaar dat de tweede in een heel ander subnet ligt.

Welke DNS staat bij jou onder ETH_Internet?

Klopt, maar je kunt wel de dns handmatig instellen. (en dus de voorgekookte instelling omzeilen) De actie om te corrigeren ligt bij Odido, van daar dat ik de moderator heb gevraagd dit te escaleren. De provisioning data voor internet modems moet worden gecontroleerd op correctheid

output van een macOS terminal command scutil --dns:
 

DNS configuration (for scoped queries)

resolver #1

  search domain[0] : home

  nameserver[0] : 84.241.227.82

  nameserver[1] : 8.8.4.4

  if_index : 6 (en1)

  flags    : Scoped, Request A records

  reach    : 0x00000002 (Reachable)

….dus dit is wat de DHCP server aan mijn iMac vertelt bij DHCP query en refresh

Wat moeten ze dan corrigeren? Als het goed is, is de storing over en werkt het met hun eigen DNS servers weer (tenminste de nslookup werkt bij mij gewoon met die servers onder ETH_Internet).

Ja, je kunt willen dat ze 8.8.8.8 daar gebruiken, maar dat wil Odido niet. Die hebben hun eigen DNS servers. Alleen is het hopen dat die niet te vaak in storing schieten.

Maar de storing is over en de DNS onder ETH_Internet werkt weer, dus ik weet niet wat ze dan moeten escaleren.

Ze moeten ervoor zorgen dat de correcte DNS adressen worden ge-pushed naar de routers. Zoals ik aangaf zaten de verkeerde adressen er in (84.241.227.81 en 84.241.227.82).

In ieder geval wil ik dat Odido zelf met de correcte informatie komt in deze thread

… en die 84.241.227.81/84.241.227.82 adressen doen het nog steeds niet.

De 84.241.227.81/84.241.227.82 zijn sowieso niet de juiste en zullen het dus nooit doen. Die zijn voor mobiel netwerk en zouden ook niet gepusht mogen zijn naar het vaste netwerk.

Waar zie jij ze staan? Onder de ETH_Internet of bij DNS onder Netwerkinstelling > Thuisnetwerken?

Als ze onder ETH_Internet staan dan is er inderdaad iets misgegaan met pushen (en dan moet Odido daar inderdaad naar kijken).

Maar onder Netwerkinstelling > Thuisnetwerken staat nooit standaard iets ingegeven maar staat standaard op Proxy (zodat ie uiteindelijk die van ETH_Internet pakt).

Tijd voor een wash-up.

Ik heb de dns settings “thuisnetwerken” naar default gezet. Mijn LAN devices gebruiken weer de 192.168.1.1 als proxy dns.
De provisioning server voorziet de Router van de volgende adressen

Het 37.x.y.z adres kan ik ook vanuit een interne machine gebruiken, en werkt verder prima.

Het 62.x.y.z adres kan ik NIET vanuit mijn LAN aanroepen, het resultaat van een query is:
 

LeoS@Applepap ~ % nslookup -debug www.google.com 62.58.48.20

Server: 62.58.48.20

Address: 62.58.48.20#53

------------

    QUESTIONS:

    ANSWERS:

    AUTHORITY RECORDS:

    ADDITIONAL RECORDS:

------------

** server can't find www.google.com: REFUSED

Met andere woorden, de query wordt geweigerd. Niet hoopgevend.

Dus heb ik toch weer mijn eigen instellingen opgevoerd want ik vertrouw dit voor geen meter:
 

Dan ben ik niet afhankelijk van geklooi bij de Oepsdido’s

Dank voor het meedenken ​@rvk01 !

Toch nog een nabrander..
Als je toch in de pagina “thuiswerken” zit te figulieren, overweeg dan ook om de DHCP refresh tijd op 1 uur te zetten. DHCP refreshed dan elk half uur. 
In de tijd dat we nog 10Mbit (Half Duplex) coax Lan hadden wilde je dit niet zo vaak doen, tegenwoordig voelt je netwerk het niet eens.

Bij een korte refresh tijd convergeert je netwerk sneller.

Just saying..

Eniac schreef:

De provisioning server voorziet de Router van de volgende adressen

Het 37.x.y.z adres kan ik ook vanuit een interne machine gebruiken, en werkt verder prima.

Het 62.x.y.z adres kan ik NIET vanuit mijn LAN aanroepen, het resultaat van een query is:
 

LeoS@Applepap ~ % nslookup -debug www.google.com 62.58.48.20

Server: 62.58.48.20

Address: 62.58.48.20#53

** server can't find www.google.com: REFUSED

Yikes. Dat is inderdaad maf en lijkt mij niet goed. (Die had ik nog niet getest, de 34.x wel)

De hostname voor 62.58.48.20 is public-dns-secondary.glasoperator.nl dus je zou zeggen dat dat gewoon zou moeten werken. Wellicht hebben ze die nog niet in de lucht geslingerd. Kan dus nog wel voor wat problemen zorgen in de router.

Maar inderdaad niet echt iets om op te vertrouwen. Ik heb na dat gedoe van afgelopen week ook niet zoveel vertrouwen in die 37.143.84.228.

Ik werk zelf met een pi-hole met unbound backend dus hoef gelukkig niets met de DNS servers te doen. Maar anders zou ik vrolijk de 1.1.1.1, 8.8.8.8 of een van de publieke dns die ook reclame tegenhouden gebruiken (met zoals bij de pi-hole).

Bizar inderdaad. Betekent dus dat iedereen denkt dat ‘ie dubbel gezekerd is, gewoon met de billen bloot gaat als de primary onderuit gaat.

Het instellen van primary en secondary in “thuiswerken” propageert netjes naar de Lan-devices, dus met 8.8.4.4 als backup server ben ik gerust op een werkende redundancy.

ik blijf benieuwd naar een duidelijke reactie van ​@Tommie van Odido 

Groet,

Leo