After re-check the test, I realization that the dns client  was  accually using glibc while the server was running in alpine container using musl library,  when retest the client within alpine container, there is no dns 5s delay detected.
musl uses clock_gettime first and my aarch64  env supports clock_gettime with clock id 0,  the accuracy is in nanoseconds, the probability of transaction id collision within same connection  is very low.

Hence the issue is about glibc on aarch64, not alpine.


Sorry about the error report.


But I  still do not understand the reasoning of choosing time to generate dns transation id,  why not use some random source?





Thanks
David














At 2021-01-05 21:44:32, "Íõ־ǿ" <00107082@163.com> wrote:

Hi guys,
    I am having lots of dns 5s delay on a arm/aarch64 platform, after tcpdump capturing dns packages, I found that the delay always happened when A/AAAA queries  happened to have same dns transaction id. 



network/res_mkquery.c
...
    /* Make a reasonably unpredictable id */
    clock_gettime(CLOCK_REALTIME, &ts);
    id = ts.tv_nsec + ts.tv_nsec/65536UL & 0xffff;
    q[0] = id/256;
    q[1] = id;
...


time/clock_gettime.c
...
    r = __syscall(SYS_clock_gettime, clk, ts);
    if (r == -ENOSYS) {
        if (clk == CLOCK_REALTIME) {
            __syscall(SYS_gettimeofday, ts, 0);
            ts->tv_nsec = (int)ts->tv_nsec * 1000;
            return 0;
        }
        r = -EINVAL;
    }
    return __syscall_ret(r);
....


On aarch64, gettimeofday yields current time with low accuracy, the smallest unit is 1e-6, (I think)
Could we add some trick to make sure that the parallel A/AAAA queries got different  id?


Thanks
David