Ja, dat schreef ik toch al?
Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit...
:fill(white):strip_exif()/f/image/1J2UEujMW8D9gx4W8ZSD5E6a.png?f=user_large)
[ Voor 4% gewijzigd door stijnos1991 op 01-12-2020 09:52 ]
Geen idee, maar als dns rewrite het niet meer zou doen, denk ik dat veel mensen hier last van hebben. Zelf zit ik nog op 0.105. 0.106 nog niet getest.
[ Voor 7% gewijzigd door Mars Warrior op 16-05-2021 15:20 ]
Material 3 Thema's voor HA | Swiss Army Knife custom card voor HA | AmoebeLabs
:fill(white):strip_exif()/f/image/LZYRKCnxrLwvJ3xFOxXbtW06.png?f=user_large){kind=small}
Ook allemaal geprobeerd al, maar geen soelaas. Bedankt voor het meedenken, ik zal het maar gewoon zonder moeten doen
This too shall pass
Ik heb er geen verstand van en het zal mij niet verbazen als ik het toch bij het verkeerde eind heb.:
[...]
Ik heb hier ongeveer hetzelfde.
Heb nu sinds kort Adguard draaien op een container in Proxmox. Niet heel erg nodig want ik merk dat ik eigenlijk voldoende heb aan de android app en de browser extensie. En dat ik deze nog steeds "moet" gebruiken om de lege advertentievelden weg te laten in de browser. Maar goed, wel leuk voor het overzicht.
In het begin zag ik alleen maar de Unifi USG als apparaat in de lijst (het ip adres), niet handig.
Na de volgende aanpassing komt er meer beeld bij en worden de apparaten ook (deels) getoond:
(de unifi software draait in proxmox op xxx.50 en de USG op 192.168.178.1.1)
[Afbeelding]
[Afbeelding]
[Afbeelding]
Zoals je ziet werkt het nog niet helemaal goed, soms geen naam, soms de verkeerde(ik draai geen porteus, dat is mijn windows pc
1
| [/local/168.192.in-addr-arpa/]192.168.178.25:53 |
1
| [/local/168.192.in-addr-arpa/]192.168.178.1 |
[ Voor 4% gewijzigd door ariekanari op 16-06-2023 12:48 . Reden: EverLast2002 ]
Xbox Live: BicycleTiger34 TrueAchievements
Ik doe genoeg, maar niet het juiste blijkbaar
Ik heb dus ook overal gezocht en diverse varianten geprobeerd om in te stellen.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/7hSyCc5zUlpYTQx6tM7vnccB.jpg?f=user_large)
1
2
3
| 127.0.0.1:5335 [/local/]192.168.0.1:53 [/168.192.in-addr.arpa/]192.168.0.1:53 |
1
| 192.168.0.1 |
Als je dit kunt lezen, dan werkt mij Signature!
Heb je je router de naam local gegeven? Anders werkt die regel niet. Je kan checken of die regel dan werkt door in het zoekvenster van query log local te typen. Je moet dan verzoeken zien met .local aan het einde.:
[...]
Ik doe genoeg, maar niet het juiste blijkbaar
[...]
Ik heb dus ook overal gezocht en diverse varianten geprobeerd om in te stellen.
Ik heb het nu als volgt. Ik Unifi heb ik een firewall regel aanstaan, waarbij het RFC1918 netwerk Adguard mag bereiken op 192.168.0.95 op de poorten 53 en 5335
Als ik ook verbind met met één van die netwerken, en een ipconfig /all doe, dan zie ik de DNS server van Adguard staan.
In de Unifi heb ik voor alle netwerken verwezen naar de Adguard server
[Afbeelding]
in Upstream DNS servers heb ik dit staan:
code:
en onder Private reverse DNS servers heb ik dit staan (mijn router)
code:
Volgens mij doe ik niks anders dan anderen, maar ik krijg geen namen die in mijn Unifi staan. Sterker nog, ik zie heel veel clients niet.
:fill(white):strip_exif()/f/image/Q5uVv0IH0q6tHUWF2ea6mQCW.png?f=user_large)
Oke goed om te weten.
1
2
| 127.0.0.1:5335 [/168.192.in-addr.arpa/]192.168.0.1 |
1
2
3
4
| 127.0.0.1:5335 [/168.192.in-addr.arpa/]192.168.0.1 [/168.192.in-addr.arpa/]192.168.10.1 [/168.192.in-addr.arpa/]192.168.20.1 |
Hebben we allemaal last van denk ik:
[...]
Je bent te ongeduldig, waar ken ik dat toch van.
Ja maar ik wil dus niet allerlei dubbel werk gaan doen. Ik weet inderdaad dat ik namen kan invoeren in Adguard, maar ik houd alles netjes bij in Unifi, en die gegevens zou ik graag terug willen zien in Adguard.
Als je dit kunt lezen, dan werkt mij Signature!
Als ik in de query log kijk van Adguard, dan zie ik bij sommige inderdaad namen staan. Maar ook bij heel veel niet.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/G5AR7L1q9BybulBBR1O6Wspe.jpg?f=user_large)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/s6NP4YI3t1UaJ0ihtv3ReDpJ.jpg?f=user_large)
[ Voor 18% gewijzigd door Wachten... op 12-03-2024 10:08 ]
Als je dit kunt lezen, dan werkt mij Signature!
Dan moet je niet zomaar aanpassingen gaan maken in de voorbeelden van ander. Of klakkeloos de ene na de andere configuratie gaan copy-pasten. Dat is hetzelfde als stront naar de muur gooien, ooit blijft daar wel iets plakken
.# Unbound 192.168.1.1:53535 # Internal routing [//]192.168.1.1 [/lan/]192.168.1.1
En de /lan/ gaat uiteraard over interne .lan domeinen, bijvoorbeeld router.lan of adguard.lan:
❯ dig +short tweakers.net @adguard.lan 213.239.154.31
192.168.1.1 [/168.192.in-addr.arpa/]192.168.1.1
heb je de documentatie niet goed gelezen. Alleen als je specifieke PTR servers wilt gebruiken voor publieke adressen moet je de entries uit het eerste blokje hierboven invoeren. Maar ik neem aan dat je dat niet wilt. Die zijn dus niet nodig.
In mijn configuratie staat dan ook:
192.168.1.1 [/168.192.in-addr.arpa/]192.168.1.1
❯ nslookup 192.168.1.1 1.1.168.192.in-addr.arpa name = router.lan.
:fill(white):strip_exif()/f/image/aMH6Sj6G3qh6Xalq8ExtcSZ0.png?f=user_large)
Je zal echt gelijk hebben, echter had ik dat ook al geprobeerd, en als je hier op het forum zoekt naar [/168.192.in-addr.arpa/], dan voert iedereen dat in bij Upstream DNS servers. Dus is het gek dat ik de weg kwijt raak?:
[...]
Dan moet je niet zomaar aanpassingen gaan maken in de voorbeelden van ander. Of klakkeloos de ene na de andere configuratie gaan copy-pasten. Dat is hetzelfde als stront naar de muur gooien, ooit blijft daar wel iets plakken
Mijn Upstream DNS servers ziet er zo uit:
# Unbound 192.168.1.1:53535 # Internal routing [//]192.168.1.1 [/lan/]192.168.1.1
De eerste is dus voor Unbound. Mijn Unbound server draait, zoals ik eerder zei, op mijn router. In jouw geval zal hier dan 127.0.0.1:5335 staan. Aangezien daar jouw Unbound server zou draaien.
De tweede en derde entries - comments tellen we niet mee - zijn voor interne routing. De twee forward slashes // is om hosts te resolven zonder domeinnaam, conform documentatie:
[...]
En de /lan/ gaat uiteraard over interne .lan domeinen, bijvoorbeeld router.lan of adguard.lan:
❯ dig +short tweakers.net @adguard.lan 213.239.154.31
In mijn Private reverse DNS servers heb ik het volgende staan:
192.168.1.1 [/168.192.in-addr.arpa/]192.168.1.1
Wederom volgens documentatie, want met
[...]
heb je de documentatie niet goed gelezen. Alleen als je specifieke PTR servers wilt gebruiken voor publieke adressen moet je de entries uit het eerste blokje hierboven invoeren. Maar ik neem aan dat je dat niet wilt. Die zijn dus niet nodig.
Voor lokale PTR adressen (reverse DNS) staat er letterlijk dit in de documentatie:
Zoals gezegd probeer ik dus ook van alles, aangezien niks werkt. Ook al voer ik alles in zoals jij aangeeft (en dan wel met eigen IP adressen, dan krijg ik alsnog bijna niks bij de client list te zien. Ik zie nog steeds maar een stuk of 10 clients
1
2
| # Unbound 192.168.0.1:5335 |
1
2
| 192.168.0.1 [/168.192.in-addr.arpa/]192.168.0.1 |
[ Voor 4% gewijzigd door Wachten... op 12-03-2024 13:02 ]
Als je dit kunt lezen, dan werkt mij Signature!
Ja. Want dit staat echt heel duidelijk in de documentatie::
[...]
Je zal echt gelijk hebben, echter had ik dat ook al geprobeerd, en als je hier op het forum zoekt naar [/168.192.in-addr.arpa/], dan voert iedereen dat in bij Upstream DNS servers. Dus is het gek dat ik de weg kwijt raak?
En nogmaals, je hebt reverse DNS helemaal niet nodig. Dat is echt optioneel.
Dat je geen clients in de client list ziet is een ander probleem dan dat je upstreams niet goed staan
. Dan gebruiken de clients Adguard Home niet. Het kan ook zijn dat hier een vertraging in zit voor sommige clients. Omdat de DNS servers via DHCP worden geüpdatet naar de clients toe.Draait Unbound dan op 192.168.0.1? Want ik dacht dat jij die op dezelfde host als Adguard Home had staan.
. Want je kunt op die manier nog steeds geen lokale hostnames resolven .
Maar dan voert iedereen dat hier dus verkeerd in?
Dat weet ik, echter wil ik het wel graag, want ik heb 50+ apparaten standaard (met af en toe andere losse tijdelijke apparaten) en ik wil dit graag beter in kaart krijgen. Ik moet nu iedere keer aan de hand van het ip adres kijken welk apparaat het is.
En daar komt wederom het gekke, als ik met het IoT netwerk verbind en een ipconfig /all doe, dan zie ik toch echt mijn Adguard DNS staat. Het enige probleem is dat niet alle apparaten erin staan.[...]
Dat je geen clients in de client list ziet is een ander probleem dan dat je upstreams niet goed staan
Nee ik had een foutje gemaakt met het kopiëren vanuit mijn post. In de Upstream DNS servers heb ik nu enkel staanDe vertraging kan het wel verklaren misschien. Ik heb veel apparaten die ik een Vast IP heb gegeven in Unifi en die zelden rebooten. Wellicht duurt het dan een tijdje voordat alles zichtbaar is?
[...]
Draait Unbound dan op 192.168.0.1? Want ik dacht dat jij die op dezelfde host als Adguard Home had staan.
Maar niet helemaal mijn configuratie overgenomen
1
| 172.0.0.1:5335 |
1
2
3
| [/168.192.in-addr.arpa/]192.168.0.1 [/168.192.in-addr.arpa/]192.168.10.1 [/168.192.in-addr.arpa/]192.168.20.1 |
Als je dit kunt lezen, dan werkt mij Signature!
Ja.
Dat is toch precies wat ik zeg? Als jij verbind met jouw IoT netwerk dan krijg je sowieso een nieuwe DHCP configuratie toegezonden mét daarin de 'juiste' DNS servers. De apparaten die al verbonden zijn gebruiken echter nog steeds de voor hun bekende informatie. Met name IoT apparaten zullen pas bij het verstrijken van de lease nieuwe informatie opvragen.
.Dat klopt nog steeds niet
. Je zou hier ook aanvullend 8.8.8.8 (Google) in kunnen voeren om in ieder geval zeker te zijn dat jouw apparaten online blijven.Nee. Dan zeg je in feite dat Adguard Home voor reverse DNS op drie hosts moet gaan kijken:
[/0.168.192.in-addr.arpa/]192.168.0.1 [/10.168.192.in-addr.arpa/]192.168.0.1 [/20.168.192.in-addr.arpa/]192.168.0.1
Net even een paar devices gereconnect vanuit Unifi, maar zie ze nog niet verschijnen in Adguard client lijst. Dan nog maar even meer geduld hebben.:
[...]
Ja.
[...]
Dat is toch precies wat ik zeg? Als jij verbind met jouw IoT netwerk dan krijg je sowieso een nieuwe DHCP configuratie toegezonden mét daarin de 'juiste' DNS servers. De apparaten die al verbonden zijn gebruiken echter nog steeds de voor hun bekende informatie. Met name IoT apparaten zullen pas bij het verstrijken van de lease nieuwe informatie opvragen.
Je kunt die apparaten ook handmatig herverbinden, bijvoorbeeld door ze te herstarten. Dan zullen ze, zeer waarschijnlijk, wel de nieuwe informatie ontvangen en gebruiken.
Ik test meestal één device en de rest volgt als de lease (of TTL) verloopt vanzelf. Bij netwerkconfiguratie dien je over het algemeen dus wat geduld te hebben
Maar je bedoelt hiermee niet perse dat het fout is, maar dat ik beter een alternatieve erbij kan zetten (zoals het oorspronkelijk stond met 1.1.1.1 erbij?[...]
Dat klopt nog steeds niet
Oke duidelijk verhaal. Dat stuk snap ik nu dan eindelijk.
Als je dit kunt lezen, dan werkt mij Signature!
Ik heb geforceerd dat de apparaten een nieuw IP adres krijgen, en heb de apparaten herstart en van sommige (in hoeverre het kon) de cache van de netwerk settings geleegd.
Ik zal een aanvraag doen om mijn naar te veranderen naar "ongeduldig"
Zoals gezegd heb ik de dus geforceerd een nieuw ip adres gegeven aan de apparaten, zoveel mogelijk gewist qua cache etc. en zelfs de router en Adguard opnieuw opgestart. Mij lijkt dat er ik ergens wel iets met gaan zien dan toch?
Zie eerdere opmerking[...]
Dat heeft vaak geen zin. Want de client had al een geldige lease
Ja die staan beide aan. Ik heb daar dus dit staat bij Private reverse DNS, met daaronder die 2 vinkjes aan "use private reverse DNS resolvers" en "Enable reverse resolving of client IP addresses"
1
2
| 192.168.0.1 [/168.192.in-addr.arpa/]192.168.0.1 |
Als je dit kunt lezen, dan werkt mij Signature!
Aha, dat verklaart een hoop:
[...]
Ik gok dat je zelf recursing doet en dnssec gebruikt.
zie de discussie bij de collega's met pihole, met de uitleg van stormfly in "[Pi-Hole] Ervaringen & discussie"
Komt er op neer dat odido een fout heeft gemaakt, sommige dnssec implementaties zijn wat vergevingsgezinder dan andere
1
2
3
4
5
6
7
| # Unbound 127.0.0.1:5335 # Extra [///0.168.192.in-addr.arpa/]192.168.0.1 https://dns.quad9.net/dns-query tls://dns.quad9.net 9.9.9.9 |
Als je dit kunt lezen, dan werkt mij Signature!
. Het was nogal... voor de hand liggend 
. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| services: adguard-home: container_name: adguard-home image: adguard/adguardhome:v0.107.64 restart: on-failure:10 hostname: leetower.adguard.docker.internal environment: TZ: Europe/Amsterdam networks: ingress: priority: 1 internal: priority: 2 ipvlan: ipv4_address: 192.168.40.4 priority: 3 volumes: - /mnt/applications/appdata/adguard-home/conf:/opt/adguardhome/conf - /mnt/applications/appdata/adguard-home/work:/opt/adguardhome/work unbound: container_name: adguard-home-unbound image: klutchell/unbound:1.23.1 restart: on-failure:3 hostname: leetower.unbound.docker.internal networks: internal: networks: ingress: name: swarm-overlay external: true internal: name: adguard-home-internal driver: overlay attachable: true ipvlan: name: br0.40 external: true |
1
2
3
4
5
6
7
8
9
10
11
12
13
| services: adguard-home: - hostname: leetower.adguard.docker.internal + hostname: brickhouse.adguard.docker.internal adguard-home-unbound: - hostname: leetower.unbound.docker.internal + hostname: brickhouse.unbound.docker.internal networks: ipvlan: - name: br0.40 + name: br0.41 |
1
2
3
4
| leetower.unbound.docker.internal brickhouse.unbound.docker.internal [/168.192.in-addr.arpa/]192.168.1.1 [/ip6.arpa/]192.168.1.1 |
1
2
| 127.0.0.11 192.168.1.1 |
1
2
3
| 192.168.1.1 [/168.192.in-addr.arpa/]192.168.1.1 [/ip6.arpa/]192.168.1.1 |
. Daarnaast gebruiken beide AdGuard Home instanties dus nu ook allebei beide Unbound instanties waardoor ik direct failover heb ..Tikje gekunstelde setup IMHO, voor een zeer specifieke setup.:
Overigens heb ik het werkend gekregen
TL;DR, om Docker containers op hostname te gebruiken in de AdGuard Home configuratie moet je eveneens Docker's interne DNS als bootstrap DNS server opgeven.
Ik heb nu onderstaande Docker Compose configuratie:
YAML:
Een aantal puntjes van aandacht:Ik heb nog een andere machine met wat kleine verschillen:
- De hostname wordt (automatisch) gegenereerd door Ansible, maar is dus een combinatie van de machiennaam inclusief de dienst en het domein docker.internal.
- Het ingress netwerk gebruik ik voor Caddy reverse proxy door middel van Docker labels. Dat is buiten scope hier en heb ik weggelaten.
- Het internal netwerk is een Swarm overlay netwerk die ik op twee machines heb
- Het ipvlan netwerk is een ipvlan (duh) bridge netwerk die getagd is.
- Mijn secundaire machine houdt ik synchroon met AdGuard Sync. Vergelijkbaar met mijn eerdere post.
Diff:
Mijn Upstream DNS Servers configuratie heb ik nu als volgt:
code:
En mijn Bootstrap DNS Servers zijn:
code:
En als laatste de Private Reverse DNS configuratie:
code:
Het geheel lijkt nu, inclusief hostname lookup door middel van PTR records te werken
Nu nog even aankijken, maar dit ziet er uit als een mooi resultaat
Het enige wat ik nog niet werkend heb gekregen is een andere user / group voor de AdGuard Home container, maar dat vind ik geen bijster groot probleem.
:strip_exif()/i/2003594310.png?f=thumbmini)
/u/152414/crop5ebc0f840c9f8_cropped.png?f=community)
/u/176086/crop5f0823fa5e8d6_cropped.png?f=community)
/u/1393188/crop66bb41740e862_cropped.png?f=community)
:strip_icc():strip_exif()/u/157390/crop5decc9d996782_cropped.jpeg?f=community)
/u/326779/apple%2520avantar.tif.png?f=community)
:strip_exif()/u/476997/ceetava60x60.gif?f=community)
:strip_icc():strip_exif()/u/94045/crop66c1b4250e8a2_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/154963/crop659be07d13f5a_cropped.jpg?f=community)
/u/366655/IMG_4061%2520-%2520kopie.JPG?f=community)
:strip_icc():strip_exif()/u/506130/keitjes.jpg?f=community)
:strip_exif()/u/634/crop56eab269d97ab.gif?f=community)
:strip_icc():strip_exif()/u/101588/crop69cbc8124478f_cropped.jpg?f=community)
:strip_icc():strip_exif()/u/249279/crop6992cdd633db0_cropped.jpg?f=community)
