Nicht wirklich. Ja, man kann natuerlich den AAAA-Record austragen - aber das ist irgendwie ja doch eher ein ziemlich kaputter Workaround.
Also, erstmal haben DNS-Records keine "Reihenfolge", folglich steht der AAAA-Record auch nicht als "erstes". Wenn man nach ANY fragt oder einen Zonentransfer macht, ist die Reihenfolge undefiniert. Ein normaler Client macht aber sowieso weder das eine noch das andere (zum einen, weil das unnoetigen Overhead verursachen wuerde, zum anderen, weil das beides nicht durch Caches, also ibs. nicht durch den DNS-Server des eigenen Providers hindurch geht) - der fragt gezielt einmal nach AAAA und einmal nach A-Records, in welcher Reihenfolge auch immer es ihm beliebt, und in der Reihenfolge kriegt er dann logischerweise auch die Antworten.
In irgendeiner Form IPv6 DNS-seitig eine niedrigere Prioritaet zu geben oder sowas scheidet also schonmal aus. Bliebe, den AAAA-Record auszutragen. Das wuerde das Problem aber offensichtlich nicht "loesen", sondern nur umgehen, was mir in der Situation nicht sonderlich sinnvoll erscheint.
Wir haben es hier mit einem System zu tun, das mit IPv6-Faehigkeit ausgeruestet werden soll. Zunaechst einmal gibt es also eine Testversion, damit man sehen kann, ob das alles rund laeuft, bevor man es auf die breite Masse loslaesst. Nun stellt man beim Testen fest, dass da in Problem existiert - und statt das entdeckte Problem zu fixen, schaltet man bei der betroffenen Komponente IPv6 ab, damit man weiter testen kann. Warum genau testet man aber jetzt, wenn man die entdeckten Probleme nicht loest - dann kann man das mit dem Testen und dem IPv6 doch einfach gleich sein lassen?!
Mir ist nun nach wie vor nicht klar, wo genau das Problem eigentlich steckt, aber ich habe stark den Verdacht, dass das ein Problem in der von AVM gelieferten Firmware ist - also genau das, was man mit so einem Test wohl entdecken wollte, um es fixen zu koennen. Wenn ein System technisch v6-faehig ist, aber keine v6-Anbindung hat, sollte etwaige Software, die versucht, Verbindungen ueber v6 aufzubauen oder Pakete ueber v6 zu verschicken, unmittelbar eine Fehlermeldung kriegen und ggf. die naechste moegliche (v4-)Adresse ausprobieren. Das ist elementar, damit der Uebergang von v4 zu v6 reibungslos funktionieren kann. Das scheint in irgendeiner Weise in diesem Fall nicht zu passieren - und sollte folglich gefixt
werden.
Mal davon ab, dass die ganze Testerei fuer nichts gut ist, wenn man die entdeckten Probleme nicht fixt: Das ganze v6-Zeug waere ja fuer nichts gut, wenn auf Dauer alle Rechner am Internet per v4 zu erreichen waeren. Folglich kann man also davon ausgehen, dass es frueher oder spaeter Rechner gibt, die nur noch v6 haben. Moeglicherweise auch eine Fritzbox mit dem LCR-Updater. Wenn es dafuer dann keinen AAAA-Record mehr gibt, wird das natuerlich nicht funktionieren. Aber wenn dann noch Fritzboxen im Einsatz sind, die nur v4 haben und die das gerade beobeachtete Problem noch haben, koennte man zu dem Zeitpunkt den Record auch nicht wieder hinzufuegen, weil man damit produktive, funktionierende Systeme kaputtmachen wuerde.
In meinen Augen ist folglich dieser Test genau die Gelegenheit, das zugrundeliegende Problem zu loesen, anstatt irgendeinen Workaround drueberzukleistern - das kann man immernoch, wenn AVM eine Firmware mit dem Bug produktiv released (vorausgesetzt, es ist denn tatsaechlich ein Bug in der Firmware).
Hat jemand diese Laborfirmware im Einsatz und kann ein traceroute mit IPv4 und IPv6 durchfuehren? Das auf der Box vorhandene traceroute kann leider kein IPv6 (-6 Option). Man koennte es aber vom PC aus durchfuehren (tracert oder traceroute) - gibt es auch unter Windowssystemen.
