Sinds ik vandaag overgestapt ben naar een nieuwe Mac en gelijk ook van Ventura naar Sonoma heb ik een probleem met lokale domeinnamen.

Mijn zoekdomein is "fritz.box", dat werkt prima als ik verbinding maak met "nas.fritz.box", "web.fritz.box" etc. voor de diverse servers die ik hier in huis heb, maar wat NIET meer werkt is rechtstreeks naar de host verbinding zonder de "fritz.box"-toevoeging. Of het nou ssh, http, of ping is, ik krijg overal een timeout.

Gek genoeg:
Commando's als "dig" en "ping" vinden niet de juiste ip-adressen.
"nslookup" vindt wél de juiste ip-adressen

Iemand een idee hoe ik de apparaten in mijn thuisnetwerk weer kan benaderen zonder dat overal ".fritz.box" achter moet typen? Dat wordt vrij snel vervelend....

Werkt bijvoorbeeld diskstation.local of nas.local nog wel?

edit: sorry, dat was niet de vraag

Ik ben al wel iets verder. Het werkt nu "half".

DNS loopt standaard via mijn pihole, nadat ik die er tussenuit gehaald had en rechtstreeks naar de Fritz!box ging werkte het ineens weer. Toen ik de configuratie terugzette via de pihole bleef het af en toe werken. Normaal gesproken wordt het zoekdomein vanuit DHCP gecommuniceerd ("grijs" in Netwerk-instellingen), nu heb ik hetzelfde handmatig ingesteld ("wit") en ook dat lijkt te helpen.

Maar helemaal ben ik er nog niet. Soms werkt het even niet, probeer je het een paar seconden later weer dan werkt het wel. Regelmatig zit er ook een vertraging van een seconde of 2-3 in, alsof hij eerst iets anders probeert en op een timeout moet wachten. Ik heb er nog geen patroon in kunnen ontdekken.

Als iemand debug-tips voor DNS heeft dan houd ik me aanbevolen. Ik zal nog eens even in Wireshark duiken om te kijken wat er allemaal gebeurt...

Ik heb nog niet heel veel documentatie gevonden hoe DNS precies werkt onder Sonoma en al helemaal niet hoe je problemen goed kunt debuggen. De output van "scutil --dns" heeft in ieder geval bij resolver #1 de juiste gegevens staan.

Maak zelf geen gebruik van local domains op mijn piholes (heb er 2 draaien) omdat ik gewoon de IP adressen intik.

Maar vermoed dat het probleem zich dan eerder op de pihole zelf afspeelt want je zegt als ik die er tussenuit haal werkt het wel.

Wat staat er ingesteld onder Local DNS Records in de Pihole admin interface?

Inmiddels ben ik wel van overtuigd dat het niets met mijn nieuwe Mac te maken heeft, maar dat het al wat dagen langer speelt. Stom toeval dus dat het me pas opvalt nadat ik de nieuwe Mac ingericht had.
De pihole blokkeert zowel als er 150 queries tegelijk uitstaan als wanneer een apparaat meer dan 1000 queries per minuut doet.
Dat lijkt het geval (en deed hij dus ook al een dag voordat ik mijn nieuwe Mac inrichtte). Ik zie af en toe wat DNS-stormpjes waarbij de pihole en de fritzbox dezelfde query tussen elkaar heen en weer pingpongen totdat de pihole blokkeert. Er lijkt dus iets niet helemaal lekker te zitten in de conditional forwarding.

Ik ga met mijn vraag verder op een pihole-forum, dus voor hier is het opgelost. Dank voor het meedenken.

(alhoewel ik me nog steeds aanbevolen houd voor manieren om onder macOS DNS te debuggen, mijn bevindingen richten zich nu vooral op de pihole-logs en netwerk-captures van de machine waar pihole op draait...)

Helaas, ik ben intussen een dagje aan het puzzelen geweest en er gaat toch echt iets mis in Sonoma....

De Fritz-box heeft een lokaal zoekdomein "fritz.box", dat wordt netjes via DHCP overgedragen.
Ook in scutil --dns zie ik deze keurig staan:
DNS configuration (for scoped queries)

resolver #1
  search domain[0] : fritz.box
  nameserver[0] : fe80::5c5f:dcff:fe5b:b1dd%20d
  nameserver[1] : 192.168.178.2

Maar..... macOS Sonoma gebruikt het simpelweg niet?
Als ik "ping nas" intyp, dan doet Sonoma onder water een dns-request naar "query[A] nas.0.178.168.192.in-addr.arpa", terwijl Ventura (ik heb gelukkig ook nog een Ventura-computer in huis) netjes een query doet naar "query[A] nas.fritz.box"
Ligt dus toch niet aan de pihole, ik zie ook in Wireshark dat dat de query is die de Mac naar de pihole stuurt.

Iemand nog goede ideetjes? Ik kan er weinig over vinden, ik ben er dus nog niet van overtuigd of het ligt aan mijn installatie of aan Sonoma in het algemeen (maar heb geen eenvoudige manier om dat te onderzoeken).

Ik lees hier en daar dat de DNS-algoritmen van de klassieke netwerk tools (ping, dig, ...) niet noodzakelijk overeenstemmen met de interne API's die veel toepassingen gebruiken (niet alleen in Sonoma).

I had a very similar problem. First of all: dig et.al are not the whole truth on macOS. Many applications (like your browser, for example) use macOS' internal APIs. You can look at your actual DNS configuration by running scutil --dns and resolve a hostname using dns-sd -G v4v6 my-hostname.example.com.

En dan nog kunnen er blijkbaar vreemde dingen gebeuren, bijv. in het kader van een VPN setup:

That being said, although scutil showed the seemingly correct DNS configuration (i.e. the VPN's DNS servers), DNS resolution still did not work correctly. Apparently, "iCloud Private Relay" was enabled automatically and inserted another DNS resolver that was invisible to scutil. As soon as I disabled iCloud Private Relay, DNS resolution worked as expected.

Dank je mcmt voor de weg naar "dns-sd", die had ik nog niet gevonden.
Tijdens de Kerst-dagen wat druk met andere dingen geweest (en om de belasting van mijn pihole wat te verlagen, mijn halve thuisnetwerk maar even tijdelijk in /etc/hosts gezet, dat helpt een beetje), maar inmiddels ook een stuk verder gekomen:

De problemen die ik zie worden voor een groot deel veroorzaakt door Safari 17. Ik heb daar standaard een pagina openstaan met url's (zonder zoekdomein, dus simpelweg web/pagina.html en niet web.fritz.box/pagina.html) naar lokale pagina's op mijn eigen server. Voor al die links doet Safari vreemde reverse-lookups voor AAAA-records in de vorm web.0.178.168.192.in-addr.arpa. Ik snap het niet helemaal meer, de omgekeerde notatie is gebruikelijk bij reverse lookups, maar ik ken hem niet door er ook nog eens een lokale naam voor te zetten en dan  het hele subdomein qua nummering te hanteren?

Overigens ook wel bijzonder dat zelfs als je IPV6 helemaal uitzet, hij toch deze AAAA-records blijft opvragen.

Ook gevonden dat in Safari de optie "Gebruik geavanceerde bescherming tegen tracking en fingerprinting" roet in het eten kan gooien en eigen DNS-routines gebruikt en zo lokale dns bypassed. Dat klonk goed en had ik voor het hele surfgedrag aangezet, maar heb ik nu dus weer uitgezet...

Wordt vervolgd....