Dobrý den,
tak chybu jsme odhalili. Bohužel bug není v Suricatě (kde bychom to dokázali opravit snadněji), ale v kernelu, resp. tom mechanismu kterým Suricata získává data. DNS resolving se dneska chová tak, že se pošlou paralelně dva dotazy na A i na AAAA - což je přesně co ta volba “options single-request” může zakázat). Suricata získává data pomocí NFQUEUE (používá ho i spousta dalšího síťového softwaru) - ten má bug, že pokud přijdou 2 pakety hned po sobě na začátku spojení, tak ten druhý neprojde.
Je to “známý” problém - no, po spoustě hledání, moc dobře známé to není. Viz třeba:
https://www.spinics.net/lists/netfilter-devel/msg27248.html
Přesně proto se zasekne ten resolving, protože nepřijde odpověď na jeden z těch dotazů - ten druhý dotaz neprojde. Glibc na odpověď počká 5 vteřin a pak zkusí 2 sekvenční dotazy, které už projdou. Proto se to chová tak jak popisujete.
Nějak jsme to opravili (no, oprava je taky spíš z kategorie “narovnávák na ohýbák” 
, ono to asi dobré řešení nemá, obcházíme bug v kernelu). Oprava by měla vyjít s 3.10. Je to problém jen pro UDP nebo ICMP (TCP to nevadí), takže je řešíme nějak jinak… není to ideální, ale asi lepší než nic. Dlouhodobější řešení zkusíme probrat s vývojáři Suricaty.
Díky za ten bug report, takhle detailní popis problému fakt usnadnil hledání příčiny 
.