Stimmt ... am Ende steht das sogar in der "
resolv.conf"-Manpage, wenn man denn nur mal auch
genau liest (was ich wohl versäumt habe):
option ndots:n
Sets a threshold for the number of dots which must
appear in a name given to res_query(3) (see
resolver(3)) before an initial absolute query will be
made. The default for n is 1, meaning that if there
are any dots in a name, the name will be tried first as
an absolute name before any search list elements are
appended to it. The value for this option is silently
capped to 15.
Die Arbeitsweise der Libraries bei einer Namensauflösung ist tatsächlich nicht einmal Bestandteil des POSIX-Standards, der hört bei "getaddrinfo()" schon auf und verweist nur noch darauf, daß das
üblicherweise auf DNS zurückgreift bei der Auflösung eines Namens. Weiter ist das Vorgehen gar nicht standardisiert.
Dann kommt bei Jitsi wohl noch hinzu, daß dort ja vermutlich sogar eigene "richtige" DNS-Abfragen nach verschiedenen Typen von Einträgen gemacht werden und da wird wohl der Code dann ebenfalls eine vorhandene Suchdomain noch anhängen nach einem NXDOMAIN (ob das logisch und sinnvoll ist, will ich gar nicht beurteilen). Dann liefert die Abfrage nach "_sip._tcp.fritz.box.fritz.box." mit SRV-Typ eben seit dem 11.11. kein NXDOMAIN mehr und damit kommt an dieser Stelle die Auflösung zum Stehen, wo sie vorher dann noch bis zum Abfragen von A/AAAA-Records weitermachte.
Manchmal bin ich so was von froh, daß ich es mir irgendwann mal angewöhnt habe, bei solchen Abfragen mit "nslookup" oder "dig" schon automatisch einen Punkt an das Ende des gesuchten Namens zu setzen - das spart die zusätzliche Angabe von Optionen (zumal der Standard bei "dig" auch noch "nosearch" ist und bei "nslookup" ist es "search", bei "host" ebenfalls, da kann man "ndots" aber noch dynamisch festlegen), wenn man die konfigurierten Suchdomains nicht einbeziehen will, was ja bei derartigen gezielten Abfragen eher selten der Fall ist (es sei denn, man will eigentlich die lokale Auflösung testen).
Andererseits ist so ein Punkt schnell überlesen und auf die Idee, daß da bei @sunnyman eine Suchdomain "fritz.box" konfiguriert sein könnte, bin ich anfangs gar nicht gekommen, weil das auch nirgendwo stand. Die kommt dann ja vermutlich auch über den DHCP-Server auf die Clients, sonst hätte er es sicherlich erwähnt, wenn er es explizit einträgt.
Also ist es am Ende dann doch ein Fehler in der Implementierung von AVM - es geht ja auch bereits bei "fritz.box.fritz.box" los mit einer externen Abfrage und zwar unabhängig vom Typ der angefragten Einträge, soweit ich das feststellen konnte. Dasselbe trifft auch auf die Domain "myfritz.box" zu, die ja ebenfalls intern verwendet wird. Egal, wo man das "fritz" gegen "myfritz" austauscht, der Effekt ist immer derselbe. Das gilt sogar noch für alle in der FRITZ!Box-DNS-Konfiguration erzeugten Einträge ... wer einen Host "client" im Netz hat und den einfach mit "ping client" ansprechen kann, sollte auch auf "nslookup fritz.box.client.fritz.box." wieder die 127.0.53.53 erhalten.
OT: Wenn man das als Fehler mal "rückwärts" aufrollt und an die Zeit vor dem 11.11. denkt, würde mich mal interessieren, was man alles hätte erreichen können, wenn ein Host im LAN der FRITZ!Box von sich behauptet, er hieße "de". Das läßt sich aber nun nur noch mit einem eigenen "richtigen" DNS-Server testen, der sich selbst als SOA für "box" ansieht. Aber irgendwo habe ich noch im Hinterkopf, daß es zumindest mal einige Browser gab, die schon bei der Eingabe einer noch unvollständigen Adresse mit der Suche nach dem passenden Host loslegten und dafür eine vorkonfigurierte Liste von gTLDs benutzten. Ob sich das in Kombination mit der Suche mit und ohne "fritz.box" am Ende zu irgendetwas verwertbarem für eine falsche Auskunft zu einer "de"-Domain benutzen ließe, wäre ja mal interessant gewesen.
Das von mir bereits als vorhanden vermutete "blacklisting" für den Namen "wpad" ist aber auch in der 41986 dann doch noch nicht umgesetzt ... es dauerte nur ein wenig länger, bis der Eintrag für "wpad" nach dem Start des avahi-Daemons in der FRITZ!Box sichtbar wurde (der läuft nicht ständig und dient nur zum Test oder zum Ausnutzen dieser Lücke).
Warum ich bei mir das Problem von @sunnyman partout nicht nachstellen konnte, obwohl ich dann extra "fritz.box" doch noch als Suchdomain hinzugefügt hatte, ist mir inzwischen auch klar:
The search list is currently limited to six domains with a total of 256 characters.
Weil ich die "offizielle" Domain auch daheim in Subdomains untergliedert habe (vpn, wlan, dmz, dynamic, home), habe ich zusammen mit dem Eintrag für "keine Subdomain" (so daß auch eine Suche nach "fb7490.dmz" funktioniert, weil ich "ndots:2" gesetzt habe) bereits die erwähnten sechs Suchdomains (die aber alle der interne NS auch als SOA behandelt und vom externen (primary) NS repliziert) in Benutzung und es ist mir selbst auch nicht so richtig aufgefallen, daß da niemals das "fritz.box" als Suchdomain verwendet wurde; das wird leider auch still ignoriert und wirft keinen Fehler, wenn da mehr als sechs Einträge stehen.
