Die Dokumentation ist da etwas dürftig.
Das sehe ich auch so, daher die Frage nach der Möglichkeit der Angabe einer simplen gTLD. Aber der Eintrag "anna" wäre nach meinem Verständnis ohnehin nicht zielführend als "domain", dann schon eher die Angabe "intranet". Ich würde ggf. noch die Form "*.intranet" probieren oder auch "*.xxx.intranet". Allerdings sollte "anna.xxx.intranet" auch funktionieren (ist dann eben keine Wildcard) ... ich würde zum Packetdump greifen und prüfen, ob die Box tatsächlich den "Hugo" befragt, wenn seitens eines Clients eine Anfrage eingeht. Das sollte sich bei der 7390 dann auch alles auf dem "LAN"-Interface abspielen und somit in einem einzelnen Packetdump landen.
Das mit der Abfrage eines einzelnen Servers (der auch im GUI entsprechend gekennzeichnet ist unter "Internet" mit "aktuell genutzt für Standardanfragen") basiert auf Beobachtungen älterer Versionen. Es wäre auch denkbar, daß die Box bei NXDOMAIN (inzwischen?) doch beide Server abfragt, das Verhalten ist/war ansonsten ja auch merkwürdig. Aber auch das findet man in einem Packetdump ja sehr schnell heraus ... die Frage, was "Standardanfragen" im DNS sind, "quälte" mich schon solange dieser Text da stand.
Wenn ich Deine Beschreibung richtig verstehe, löst die Box bei Dir ja Internet-Adressen auf ... das dürfte dann der externe DNS-Server sein, der da antwortet. Wenn der dnsmasq seinerseits keinen Forwarder kennt, wie soll er dann eine Anfrage nach "google.de" überhaupt beantworten können? Die Tests bzw. die beschriebenen Ergebnisse sind für mein Empfinden etwas "vermischt" - kann der dnsmasq bei direkter Abfrage (ich gehe davon aus, daß sein Forwarder eben nicht die FRITZ!Box ist, sonst hast Du ohnehin ein Loop, wenn nur er selbst in der FRITZ!Box konfiguriert ist als Forwarder) denn Internet-Domains auflösen?
Mir gehen die Ideen aus...
Ich würde nichts weiter probieren, sondern das "Übel" beginnend an der Wurzel analysieren ... als erstes den dnsmasq so konfigurieren (mit einem festen DNS-Forwarder - entweder vom Provider oder meinetwegen Google, die wissen ohnehin noch zuwenig von uns - und dem Zulassen rekursiver Abfragen, was ja auch nicht ganz unwichtig ist in diesem Zusammenhang), daß er bei direkter Abfrage sowohl intern als auch extern auflösen kann. Erst wenn das gesichert ist, dann die FRITZ!Box wieder ins Spiel bringen und entweder sie fragt für eine von einem Client eintreffende Abfrage ihrerseits den (bei ihr) eingetragenen DNS-Server (oder auch mehrere) oder nicht. Das ist ja dann eindeutig zu sehen in so einem Dump ... und man muß nicht mehr probieren und aus den Symptomen seine Rückschlüsse ziehen.
BTW: Die "resolv.conf" auf dem Server mit dem dnsmasq sollte eigentlich keine Rolle spielen (müßte ich aber ggf. auch erst noch einmal in der - ja eher länglichen - man-Page des dnsmasq nachlesen), die ist nur für die lokale Auflösung irgendwelcher Programme (und nicht des DNS-Servers) zuständig. Daher steht bei einer Maschine mit einem lokalen DNS-Server in so einer resolv.conf in der Regel auch "localhost" (bzw. eher die Adresse 127.0.0.1) als Nameserver. Wenn ein DNS-Server einen Forwarder verwenden soll (und ob er überhaupt rekursive Abfragen bearbeiten soll - also Abfragen, bei denen es um Domains geht, für die er selbst nicht "start of authority" ist), wird das in aller Regel für diesen DNS-Server gesondert konfiguriert (das mag in der dnsmasq.conf passieren).
Ich kann jedenfalls in der Beschreibung des Verhaltens Deiner FRITZ!Box (immer unter der Annahme, daß nicht die FRITZ!Box ihrerseits beim dnsmasq-Server als Forwarder konfiguriert ist) keinen Widerspruch zu meinen früher getroffenen Aussagen finden. Deine Tests (bzw. deren Ergebnisse) sind für mich weitgehend erklärlich ... bis auf die Tatsache, daß die "lokalen Spezialdomains" beim Zugriff über die FRITZ!Box auch dann nicht aufgelöst werden können, wenn nur der Hugo als DNS-Server eingetragen ist. Da das aber problemlos der Rebind-Schutz sein kann, hilft auch hier eben wieder der Packetdump - wenn der dnsmasq antwortet (mit einer internen Adresse) und die FRITZ!Box das ihrerseits nicht ausliefert, ist es der Rebind-Schutz.
Bei allen diesen Tests mußt Du aber auch noch aufpassen ... der multid berücksichtigt seinerseits die TTL-Angaben in einer erfolgreichen Abfrage (ob und wie der das auch bei NXDOMAIN macht, weiß ich gerade nicht, aber auch das kriegt man ja raus) und liefert für die dort angegebene Zeit dann direkt aus seinem Cache aus. Der wäre also jeweils neu zu starten, wenn das irgendetwas in Cache steht.
EDIT: Teile des oben stehenden haben sich mit #9 überschnitten ...
