Vor einigen Tagen hatten wir auf unseren Oracle RAC Servern ein seltsames Phänomen mit TNSListener Timeouts.

EM Event: Critical:LISTENER_SCAN3_rac-scan - Listener response to a TNS ping is 5,010 msecs

Nach einiger Recherche und viel Analyse fiel auf, dass die betroffenen Server bei DNS-Anfragen den A-Record und den AAAA-Record (quadA-Record) als Ergebnis erwarteten. Dies konnte man im TCPDUMP sehr schön sehen.

2016-10-13 15:22:54.247889 IP (tos 0x0, ttl 64, id 11169, offset 0, flags [DF], proto UDP (17), length 75)
    11.20.22.101.23397 > 11.20.41.10.domain: [bad udp cksum 5c97!] 7836+ A? rac-scan.domain.local. (47)
2016-10-13 15:22:54.247895 IP (tos 0x0, ttl 64, id 11170, offset 0, flags [DF], proto UDP (17), length 75)
    11.20.22.101.23397 > 11.20.41.10.domain: [bad udp cksum 6ac8!] 53901+ AAAA? rac-scan.domain.local. (47)
2016-10-13 15:22:54.248504 IP (tos 0x0, ttl 127, id 30819, offset 0, flags [none], proto UDP (17), length 123)
    11.20.41.10.domain > 11.20.22.101.23397: [udp sum ok] 7836* q: A? rac-scan.domain.local. 3/0/0 rac-scan.domain.local. [1h] A 11.20.22.104, rac-scan.domain.local. [1h] A 10.60.22.105, rac-scan.domain.local. [1h] A 11.20.22.103 (95)
2016-10-13 15:22:59.251573 IP (tos 0x0, ttl 64, id 11171, offset 0, flags [DF], proto UDP (17), length 75)
    11.20.22.101.23397 > 11.20.41.10.domain: [bad udp cksum 5c97!] 7836+ A? rac-scan.domain.local. (47)

Nun dieses Verhalten, das beide Einträge abgefragt werden, ist in DUALSTACK Umgebungen völlig normal und gewollt. Das Problem ist nur, dass einige Betriebssystemversionen und manche Hardware die Anfragen über den selben Socket rausschicken, aber nach der ersten Antwort den Socket bereits wieder schließen. Dadurch wartet die zweite Anfrage bis auf den Sankt Nimmerleinstag und rennt vor die Wand (den Timeout).

Nun kann man IPv6 Ausschalten, wenn man es nicht dringend benötigt, oder man kann den DNS-Resolver eine von zwei Optionen mitgeben.

man resolv.conf
[... gekürzte Ausgabe ...]
...
single-request (since glibc 2.10)
     sets RES_SNGLKUP in _res.options.  By default, glibc performs IPv4 and IPv6 lookups in parallel since version 2.9.  Some appliance DNS servers cannot handle these queries properly and make the
    requests time out.  This option disables the behavior and makes glibc perform the IPv6 and IPv4 requests sequentially (at the cost of some slowdown of the resolving process).
single-request-reopen (since glibc 2.9)
    The  resolver uses the same socket for the A and AAAA requests.  Some hardware mistakenly only sends back one reply.  When that happens the client sytem will sit and wait for the second reply.
    Turning this option on changes this behavior so that if two requests from the same port are not handled correctly it will close the  socket and  open  a  new  one  before  sending  the  second
    request.
...

single-request sorgt dafür, dass IPv6 Lookups und IPv4 Lookups parallel laufen. Hier können allerdings einige DNS-Server nicht mit umgehen. single-request-reopen sorgt für, dass neue Sockets geöffnet werden.

Wir haben nun die Option single-request-reopen in der resolv.conf hinzugefügt. Bisher rennt nun alles wie gewünscht.

[root@rac01 ~]# cat /etc/resolv.conf
options single-request-reopen
search domain.local
nameserver 11.20.41.10
nameserver 11.20.41.11