Gar nicht ... jedenfalls nicht so.
Entweder die FRITZ!Box erhält ihre Informationen für externe DNS-Adressen von einem anderen DNS-Server (der kann auch im LAN stehen und für "bimbam.de" "falsche" Angaben liefern) oder der fragliche Client verwendet nicht den per DHCP o.ä. "gelernten" DNS-Server in der FRITZ!Box, sondern gleich einen solchen dritten Server, der die falschen Adressen liefert.
Ansonsten braucht es auf der Box einen anderen DNS-Server (z.B. den "dnsmasq" aus dem entsprechenden Freetz-Paket) ... der eingebaute "multid" verwaltet jedenfalls seine eigene Zone und nichts weiter - abgesehen vom Caching der Abfrageergebnisse für externe Auflösungen.
Schon diese Möglichkeit mit dem dynamischen Update (ohne Authentifizierung) ist (immer noch - nach meiner Ansicht zumindest, AVM sieht das wohl anders) eine Sicherheitslücke ... ebenso wie das Vermischen der Namensräume von DNS und mDNS. Es ist eben in bestimmten Szenarien durchaus problematisch, wenn jeder Depp im LAN (fast) jeden beliebigen DNS-Namen (zusätzlich) erzeugen und zuweisen kann - was beim mDNS noch "by design" ist und entsprechend berücksichtigt werden kann (das wird dann eben der Namen "irgendwas.local"), ist bei DNS schon deutlich seltener "üblich".
Allerdings geht das auch bei einigen Kombinationen aus DHCP- und DNS-Server (z.B. ISC-dhcpd und bind) ... aber wenigstens läßt sich auch im FRITZ!OS solchem "name hijacking" vorbeugen, was notwendig wird, weil der Name auch zusätzlich eingetragen wird, selbst wenn man im GUI bereits einen für das Gerät festgelegt hat.
Auch beim "multid" kann man allerdings über so ein Update - zumindest als ich das zuletzt getestet habe - keinen existierenden (lokalen) Namen überschreiben und so kann man selbst entsprechende "kritische" Namen im GUI einem "dummy client" mit fester IP-Adresse zuweisen (nach meinem Dafürhalten sollte man das sogar machen), denn dann kann kein LAN-Client sich selbst so einen Namen geben - z.B. das allseits beliebte "wpad", was dann in der Kombination mit der (Standard-)Suchdomain "fritz.box" bei WPAD (Web Proxy Autodiscovery) eine potentielle Lücke (für nicht TLS-gesicherten HTTP-Verkehr) aufreißt (oder zumindest aufreißen kann).
Das oben gezeigte Update würde aber ohnehin den FQDN "www.bimbam.de.fritz.box." kreieren und ob der auf die Abfrage "www.bimbam.de" als Antwort "geliefert" würde, hängt von zusätzlichen Einstellungen und von der verwendeten Resolver-Library ab - das "Anhängen" der lokalen Suchdomains läßt sich steuern und auch komplett abschalten. Spätestens bei einem dreistufigen Namen würden wohl die meisten Implementierungen aber ohnehin in der Standardkonfiguration von einem FQDN in der Abfrage ausgehen und ihrerseits die Suchdomains nicht mehr verwenden.
