Hallo,
bei Red Hat ist das momentan ein Kampf gegen Windmühlen, was sagt denn
Ihr dazu?
Ich wundere mich schon über ein Jahr über seltsame AAAA-Lookups, die bei
meinem DNS-Server von meinen Hosts aufschlagen.
Folgendes passiert aktuell (copy & paste)
Example:
/etc/resolv.conf contains
search intranet.domain.example domain.example
A) IPv4-only setup:
-------------------
Following queries were made:
v4-1) A www.redhat.com.
results usually in 66.187.224.150
in case of no result, next query would be made:
v4-2) A www.redhat.com.intranet.domain.example.
in case of no result, next query would be made:
v4-3) A www.redhat.com.domain.example.
no result: client gets no IPv4 address, can't connect
Usual result: client gets A 66.187.224.150 (www.redhat.com)
B) Mixed IPv4/IPv6 setup
------------------------
First, IPv6 lookups were done:
v6-1) AAAA www.redhat.com.
ususally no result, because Red Had doesn't provide a AAAA record, so
next query would be made:
v6-2) AAAA www.redhat.com.intranet.domain.example.
in case of no result, next query would be made:
v6-3) AAAA www.redhat.com.domain.example.
no result: client gets no IPv6 address for now
Now independend IPv4 lookups were done:
v4-1) A www.redhat.com.
results usually in 66.187.224.150
Usual result: client gets A 66.187.224.150 (www.redhat.com)
C) Mixed IPv4/IPv6 setup, intranet.domain.example contains a AAAA entry
for catch-all or at least for www.redhat.com.intranet.domain.example
------------------------
First, IPv6 lookups were done:
v6-1) AAAA www.redhat.com.
ususally no result, because Red Had doesn't provide a AAAA record, so
next query would be made:
v6-2) AAAA www.redhat.com.intranet.domain.example.
results (unexpected) in e.g. fec0::1
Now independend IPv4 lookups were done:
v4-1) A www.redhat.com.
results in 66.187.224.150
Usual result: client gets
AAAA fec0::1 (www.redhat.com.intranet.domain.example)
A 66.187.224.150 (www.redhat.com)
So, der Fall C) ist nun das Problem, die Applikation weiß nicht, daß die
Adressen von verschiedenen Hosts sind. Wenn sie nun IPv6 präferiert,
verbindet sie sich zum Falschen.
Das kann ideal für Spoofing in IPv6-fähigen Umgebungen verwendet werden,
ganz davon abgesehen, daß das ein Privacy-Problem gibt, da solange kein
AAAA-Record zur Verfügung steht, die Lookups "v6-2" durchgeführt werden
(und die landen z.B. im Query-Log von intranet.domain.example).
Schaut so aus, als wäre das ganze so implementiert:
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_aaaa = lookup(AAAA,$host.$suffix)
if ($#result_aaaa > 0) {
break;
};
};
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_a = lookup(A, $host.$suffix)
if ($#result_a > 0) {
break;
};
};
return (sortresults(@result_a, @result_aaaa))
Und das ist falsch meineserachtens, es müßte wie folgt implementiert sein:
for $suffix in ("", searchsuffices(/etc/resolv.conf)) {
@result_aaaa = lookup(AAAA,$host.$suffix)
@result_a = lookup(A, $host.$suffix)
if ($#result_aaaa > 0 || $#defined result_a > 0) {
break;
};
}
return (sortresults(@result_a, @result_aaaa))
Kann mal jemand andere libcs (dietlibc, ulibc, Solaris) testen, ob die
genauso oder anders arbeiten?
Zum Testen habe ich eine spezielle Zone mit "Subzonen" eingerichtet:
getaddrinfo.bieringer.de (AXFR erlaubt)
Durch Eintragen entsprechender Subdomains kann man das Verhalten einer
Applikation testen.
Beispiel dafür gibt's hier:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061#c4
RH-Bugzillaeinträge:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199680 (RHEL4)
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=181061 (FC5)
Wer auch findet, daß das ein Bug ist, bitte entsprechend CC eintragen
bzw. bei anderen Linux-Distributionen einen Bug aufmachen.
Danke,
Peter
--
Dr. Peter Bieringer http://www.bieringer.de/pb/
GPG/PGP Key 0x958F422D mailto:[EMAIL PROTECTED]
Deep Space 6 Co-Founder and Core Member http://www.deepspace6.net/
_______________________________________________
ipv6 mailing list
[email protected]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
