OMG DNS, #hoedan

[2koe4u]

Hoi,

Ik heb inmiddels een redelijk acceptabel netwerk thuis, compleet met Parent AD server en 2 childs, omdat het kan vooral.
Nu ben ik me eens gaan verdiepen in de Pi-hole, deze draait inmiddels op een VM van mijn XEN server waar ook mijn PFsense router op draait.
Opzich nog redelijk overzichttelijk. Maar ik heb advies nodig in de volgorde van DNS servers.
Mijn AD child is mijn DHCP server, de 65 noemen we die. Die doet zijn dns verkeer forwardden naar mijn parent AD, de 62. De 62 zet vervolgens zijn DNS door naar de Pi-hole 63. en dan via de 1 naar buiten toe. Dat werkt allemaal prima, alleen zie ik in de pihole nu niet waar mijn verkeer door opgevraagd wordt. ja, ik zie het wel maar alles komt van de 62 nu.

Kort,

PC`s -> 65 -> 62 -> 63 -> 1 -> buitenwereld

Wat ik bedacht had was
PC`s -> 63 -> 65 -> 62 -> 1 -> buitenwereld maar dan werkt bijvoorbeeld Router.fat.nerd.lan niet meer om naar mijn router te gaan via de browser. Enig idee hoe ik dit kan oplossen zonder terug te gaan naar de originele setting waardoor ik in de pihole settings niet kan zien wie de aanvraag gedaan heeft??

Mijn dank is groot!

[The Eagle]

Volgens mij moet je in de DHCP server van de 65 gewoon aangeven voor je clients dat je pri dns je Pihole is. Dan gaan ze rechtstreeks requesten.

[ Voor 13% gewijzigd door The Eagle op 07-07-2017 20:40 ]

[MRE-Inc]

Hehe, ik had deze week het zelfde probleem. Een Edge router lite die DHCP en DNS is voor het interne lan. Clients hadden de ERL als primaire DNS en de ELR zond alles weer door naar de DNS servers van mijn provider. Lokale host namen werden netjes door de ERL geresolved omdat daar een lijstje static mappings op ingegeven is.

Vorige week een RPi gekocht en daar Pi Hole op gezet. Volgens diverse websites moest ik mijn DHCP instellingen aanpassen zodat de clients op het lan netwerk niet meer de ERL als primaire DNS hadden, maar de Pi Hole. Toen mijn clients eenmaal de Pi Hole als DNS hadden konden ze geen andere lokale hosts (dus desktop01.intern.lan) resolven. Na enige zoektocht op de Pi Hole bij Settings > Advanced DNS settings alle vinkjes uitgezet en vooral de bovenste twee:

never forward non-FQDNs
never forward reverse lookups for private IP ranges

Verder heeft de ERL een dns host list waarin alle lokale clients staan met ip adres en eventuele 2e naam. Ook de Pi Hole heeft een host bestand waarin de zelfde clients met ip adres staan vermeld.

Als ik nu op een client een ping naar desktop01 doe, dan krijg ik netjes een:

C:\Users\mre>ping desktop01

Pinging desktop.intern.lan [192.168.1.109] with 32 bytes of data:
Reply from 192.168.1.109: bytes=32 time=90ms TTL=64
Reply from 192.168.1.109: bytes=32 time=2ms TTL=64
Reply from 192.168.1.109: bytes=32 time=2ms TTL=64
Reply from 192.168.1.109: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.1.109:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 90ms, Average = 24ms

Het vreemde is als ik een nslookup doe, dan krijg ik netjes te zien dat de dns server de pi-hole is, maar sommige host namen worden niet door de pi hole geresolved. Helemaal lekker werkt het nog niet dus.

EDIT: Heb als test de de host list op de RPi ook maar leeg gehaald. Alleen de ERL heeft nu nog een host list met de interne clients en ip adressen. Echter de ERL staat op alle clients ingesteld als 2e DNS. Alle opties op de RPi bij Settings > Advanced DNS staan nog steeds uit.

EDIT 2: Het leeg halen van de Host list op de RPi zorgt er dus voor dat ik niks meer intern kan pingen. Als test het ip adres en hostnaam van de router weer in de host list gezet op de RPi, de RPi een reboot gegeven en ik kon die specifieke hostnaam weer pingen. Het lijkt er dus op dat je echt de host list moet vullen met alle ip adressen en hostnamen die je in het interne lan hebt.

Overigens vul ik de host lijst via webmin (http://www.webmin.com/) via Networking > Network Configuration > Host Addresses

[ Voor 20% gewijzigd door MRE-Inc op 07-07-2017 22:03 ]

[Brahiewahiewa]

Voor AD-clients moet je eigenlijk wel een microsoft DNS server hebben, anders kunnen AD-clients geen DC, geen GC en geen Kerberos vinden. 't Is wel handmatig te doen, maar je moet iets van twee dozijn conditional forwarders configureren.