1
Vraag
2
Reacties
kmeinster

Level 1
  • 4Posts
  • 0Oplossingen
  • 0Likes

Publieke DNS requests die een private network IP terug geeft komt niet door.

Hi,

 

Ik kreeg een weekje of 2 geleden een nieuwe modem/router combi van Ziggo toegestuurd die ik binnen twee weken moest gaan installeren. Voorheen had ik een witte modem in bridge mode met een eigen router draaien en alles werkte gewoon goed. Echter lijkt het er op dat mijn router deze modem niet zo heel leuk vind en aangezien ik toch door moest heb ik de modem uit bridge mode laten halen.

 

Zo gezegd zo gedaan, computers, telefoon etc. omgezet naar de wifi an de nieuwe modem en alles lijkt te werken.

Tot het moment dat ik weer ging werken waarbij ik op iets aparts stuit.

Ik gebruik zelf de DNS van CF en google (1.1.1.1 en 8.8.8.8) maar ik heb het probleem bij allen DNS requests, bij deze dan:

 

Stel ik doe een DNS request naar:

 

 

 

 

karsten@rasputin:~$ dig iammetje.bestaatlekkerniet.nl

; <<>> DiG 9.16.1-Ubuntu <<>> iammetje.bestaatlekkerniet.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28918
;; flags: qr rd ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;iam.tnl-edsn.nl.               IN      A

;; ANSWER SECTION:
iammetje.bestaatlekkerniet.nl.        0       IN      A       34.239.128.2
iammetje.bestaatlekkerniet.nl.        0       IN      A       52.196.209.52
iammetje.bestaatlekkerniet.nl.        0       IN      A       52.128.34.45

 

 

 

 

Dan gaat het gewoon goed, in dit geval word de cloudflare (dus publiek) gebruikt en ik krijg netjes een antwoord.

 

Nu doe ik (let wel, zelfde domein naam, zelfde public DNS):

 

 

 

karsten@rasputin:~$ dig iammetje-intern.bestaatlekkerniet.nl

; <<>> DiG 9.16.1-Ubuntu <<>> iammetje-intern.bestaatlekkerniet.nl
;; global options: +cmd
;; connection timed out; no servers could be reached

 

 

 

Nu weet ik toevallig dat ik hier een 10.*.*.* adres op moet terug krijgen maar deze geeft dus een timeout.

Zelfs al doe ik bij het dig command een @1.1.1.1 meegeven (dus echt geforceerd) dan nog krijg ik een timeout. Dit is voor ALLE domeinen hetzelfde, het moment dat een publieke dns een intern achtig IP adres doorstuurd krijg ik een timeout.

 

Dit heb ik pas sinds de modem dus zelf ook als router fungeert, nu vraag ik mij af, word dit hard ergens geblokkeerd of is er iets anders aan de hand?

 

Het werkt wel als ik via DoH iets krijg maar dat gaat nogal lastig als je vooral veel op commandlines werkt.

 

Gr.

Karsten

 

 

 

 

Oplossing

Geaccepteerde oplossingen
tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Je kunt zou het modem weer in bridge mode moeten laten zetten en de eigen router weer in gebruik nemen. Het is namelijk gebleken dat de eRouter/firewall van de F3896 antwoorden op DNS lookups voor A-records blokkeert als het record een intern adres (RFC 1918) bevat. Ook bij gebruik van VPN is hiervan sprake. Als workaround kun je de betreffende FQDN's opnemen in de hosts file en handmatig aan de juiste IP-adressen toewijzen.

Bekijk in context

17 Reacties 17
kmeinster
Topicstarter
Level 1
  • 4Posts
  • 0Oplossingen
  • 0Likes

Oh ja als toevoeging, IP adressen zijn gehusseld en het domeinnaam is fictief 😉

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Je kunt zou het modem weer in bridge mode moeten laten zetten en de eigen router weer in gebruik nemen. Het is namelijk gebleken dat de eRouter/firewall van de F3896 antwoorden op DNS lookups voor A-records blokkeert als het record een intern adres (RFC 1918) bevat. Ook bij gebruik van VPN is hiervan sprake. Als workaround kun je de betreffende FQDN's opnemen in de hosts file en handmatig aan de juiste IP-adressen toewijzen.

kmeinster
Topicstarter
Level 1
  • 4Posts
  • 0Oplossingen
  • 0Likes

Dank je voor het antwoord, dit is wel een dingetje dan, in dit specifieke geval kan ik er nu mee weg komen om ze inderdaad in de hosts op te nemen maar er zijn ook gevallen waarin het IP zo nu en dan veranderd (cloud omgevingen waar de IP's random komen vanuit een VPC of iets).

 

Mag hopen dat Ziggo hier dan nog wel wat aan gaat doen maar nogmaals, dank je voor het antwoord!

Nu op zoek naar een router die ondersteund word 😑

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1592Likes

@kmeinster wat was het probleem met je eigen router en het modem in bridge?

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

Toch maar even reageren want ik zie iets wat niet kan.

"Nu weet ik toevallig dat ik hier een 10.*.*.* adres op moet terug krijgen maar deze geeft dus een timeout."

Je gaat nooit en te nimmer van een public DNS een intern ip adres terug krijgen bij een request.

Interne ip adressen worden namelijk niet in externe DNS servers gebruikt, opgeslagen, gecached of wat dan ook.

 

Je zou eens in je /etc/resolv.conf moeten kijken of daar 127.0.0.1 bij staat en of je geen caching DNS server zelf draait met bind. Dat ligt meer voor de hand dat je daar je antwoord van krijgt.

 

Wat wel een mogelijkheid is, dat is dat door dit nieuwe modem nat-loopback niet ondersteund wordt, dan kun je een zelfde situatie krijgen.

Of dat het komt doordat inkomende requests op poort 53 niet meer ondersteund worden.

 

Makkelijk te controleren middels dit command:

dig @127.0.0.1 iammetje.bestaatlekker.niet.nl

en als je daarop dat gewenste 10.x.x.x ip terug krijgt, dan weet je hoe het zit.

Zelfde effect is als je in je browser je domeinnaam opvraagt en je krijgt een timeout, als je de naam niet in de hosts file hebt staan.

 

Het nat-loopback issue (alhoewel de meeste witte Connectboxen dat moeten ondersteunen, behalve misschien de gigabit boxen) is misschien met bridgemode te omzeilen, durf ik niet met zekerheid te zeggen.

 

Het blokkeren van inkomende request op poort 53 is een ander verhaal. Er is een topic over geweest dat die poort dicht gezet zou worden.

 

Maar hoe dan ook is dit geen request aan CF of Google DNS v.w.b. interne ip adressen.

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Het is wel mogelijk om een RFC 1918-adres te ontvangen als antwoord van een publieke DNS-server, al is het bad practice om in eerste instantie een dergelijk record aan te maken en zou split DNS gebruikt moeten worden. Het is uiteraard mogelijk (en waarschijnlijk) dat dergelijke records worden geweigerd wanneer ze propageren naar bijvoorbeeld Google en CloudFlare. Ik vermoed zelf dat de firewall van de modemrouter een vorm van DNS rebind protection toepast.

 

NAT loopback zou alleen een probleem vormen als TS gebruik maakt van een interne DNS-server en die probeert te benaderen via een DNAT-regel (port forwarding) op de modemrouter. Daarvan is volgens mij geen sprake.

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

@tobiastheebeNee hoor. Prive adressen worden -niet- opgeslagen in een publieke DNS server.

Sorry maar hoe had je je dat gedacht?

Nslookup domein.nl en dan antwoord 192.168.2.1. Er zijn miljoenen thuis die dat ip gebruiken, dat werkt gewoonweg niet.

De publieke DNS gebruikt bijv. 84.x.x.x en jij forward dat naar een intern ip adres 192.168.2.1 bijvoorbeeld.

Je kunt nooit en te nimmer een lokaal adres opvragen bij een publieke DNS.

Het staat ook gewoon bij de uitleg van RFC 1918:

Privé-adressen zijn adressen die niet routeerbaar zijn op het internet. Niet routerbaar=niet in public DNS want dan zouden ze routeerbaar zijn.

Probeer maar eens een prive ip in een DNS van een hoster in brengen. Als het al lukt dan gebeurt er verder niets mee en is het ook niet op te vragen.

 

Als jij denkt van wel, geef mij dan maar een voorbeeld, ga ik het met dig proberen. Bestaat gewoonweg niet, zo werkt DNS niet.

 

Dat de modemrouter een DNS rebind protection toepast, dat zou wel kunnen.

 

De TS gebruikt Ubuntu en twee publieke DNS, dus mijn vermoeden is dat er sprake is van een resolv.conf zoals ik schreef en daar wordt de localhost meestal standaard in gezet.

Maar in dat geval zou hij inderdaad geen local ip terug krijgen dus lijkt een NAT loopback issue niet van toepassing.

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Ik heb het (nog) niet getest met mijn eigen domein bij TransIP en ben ook niet dagelijks met deze materie bezig, maar kan er diverse voorbeelden van vinden op fora als ik zoek op bijvoorbeeld 'public dns private ip' op Google, bijvoorbeeld in dit topic. Ik ben het natuurlijk met je eens dat het onwenselijk is en de nodige problemen kan opleveren. Dat RFC 1918-adressen niet routeerbaar zijn, staat uiteraard buiten kijf.

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

Whahahaha, ik ben er wel dagelijks mee bezig en zo zie je maar weer. Er blijkt een bug in het internet te zitten, wordt dus wel gewoon gerouteerd en overgenomen door public DNS.

Pfffff... er was een tijdje dat dit niet mogelijk was. Althans ik heb dat ooit getest en toen werkte het niet.

 

Moet je dus wel je interne ip adres in je externe DNS zetten en dan moet je router die requests niet blokkeren maar dan kan het dus wel. Zojuist opnieuw getest.

Hahahahaha wat een internet routing blunder. 😄

 

Edit: Internet DNS blunder bedoel ik natuurlijk.

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Ik denk niet dat het zozeer met routing te maken heeft. Ik zou verwachten dat A-records met een RFC 1918-adres worden geweigerd door de servers van bijvoorbeeld Google en CloudFlare zodra ze propageren vanaf de authoritative server, maar dat is dus niet het geval?

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

Nee geen routing het is een DNS issue. Ik had me gecorrigeerd, was al weer te enthousiast bezig. 🙂

Precies wat jij zegt. Je zou verwachten dat private ip's gefilterd worden door root servers. Want je kunt ze overal opvragen, het is niet alleen Cloudflare en Google. Als ik geen DNS ingeeft en gewoon een nslookup naar de domeinnaam doe (althans, ik heb getest met een subdomein) bijv. test.domein.nl dan krijg ik ook gewoon het prive ip terug.

En dat is dus een test op een subdomein van de authorative dns server voor dat domein.

 

Dat wil dus zeggen dat de root servers ze ook niet filteren en dat is eigenlijk erger lijkt me want zo zijn ze te requesten via elke DNS server.

 

Ik denk dat toen ik ooit eerder dat geprobeerd heb, het interne ip door het aldaar gebruikte hosting panel geweigerd werd als "invalid ip".

Met cPanel heb ik nu nog niet getest maar in Directadmin kun je ze gewoon ingeven. Van een kant logisch omdat je DA ook thuis kunt draaien en dan moet kunnen verwijzen. Echter dat zou dan niet verder gepropageerd moeten worden en dat gebeurt dus wel.

 

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

In m'n enthousiasme nog een foutje gemaakt... even corrigeren. De root servers reageren er niet op. Maar authoritive naamservers dus wel. 😉

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Dat valt dan nog enigszins mee. Het betreffende record wordt dus ook niet gepropageerd naar bijvoorbeeld Google en CloudFlare?

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

Niet door de rootservers zo te zien, althans ik krijg het niet opgevraagd daar met een dig of ik doe iets fout.

Maar omdat ik een authorative nameserver heb verwijzen die root servers wel naar mijn naamservers voor het domein en gaat een request (van waar dan ook) bij mijn naamservers vragen naar test.domein.com en krijgen dan als antwoord dat dit ip 192.168.10.1 heeft.

 

Jammer dat ik geen domein vrij heb om dat eens met een volledige domeinnaam te proberen, maar ik denk dat dan hetzelfde gaat gebeuren als je zelf authorative naamservers hebt.

Je kunt gewoon van overal een nslookup test.domein.com doen, dus ook vanaf Google en CF en je krijgt het interne ip als result. Grappig.

 

Edit: Ik denk dat je bij de registrar een domein misschien niet op een intern ip krijgt vermoedelijk, alleen in eigen naamservers en dus eigen DNS. Kan het helaas niet testen in elk geval.
Zou me niet verbazen als dat ook lukt.

tobiastheebe

Level 20
T.E.A.M.
  • 31053Posts
  • 2179Oplossingen
  • 15499Likes

Helder, dank voor de info.

Richard G.

Level 16
  • 1688Posts
  • 84Oplossingen
  • 856Likes

En jij bedankt voor de correctie van mijn fout!

kmeinster
Topicstarter
Level 1
  • 4Posts
  • 0Oplossingen
  • 0Likes

Sorry voor de late reactie.

Dat het niet mooi is, ben ik mee eens, echter is dit wel iets wat veel gedaan word binnen bedrijven, zo zijn ook bepaalde platformen die dit gewoon doen en waar je zelf geen invloed hebt op de DNS omgeving (looking at you Redhat) dus split horizon klinkt leuk maar is niet altijd te doen.

Daarnaast ben ik van mening dat een ISP hier niet over hoort te gaan, de gevolgen van dit zijn bijvoorbeeld niet hetzelfde als bij open SMTP servers.

 

Voor de duidelijkheid dit is natuurlijk wel getest op verschillende providers en met verschillende DNS servers, zo heeft KPN eenzelfde soort probleem (geen timeout melding maar gewoon een leeg antwoord) echter ligt dat aan bij hun eigen DNS servers, dit is dus simpel te fixen door CF of google te gebruiken (1.1.1.1 of 8.8.4.4) bij de nieuwe ziggo modem werkt dit dus niet en krijg je een timeout.

 

E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic