nc or telnet command resolution failure

[kys1230]

CoreDNS Version: 1.5.0
My Corefile

. {
  etcd {
    path /coredns
    endpoint http://etcd-node-1-ip:2379 http://etcd-node-2-ip:2379 http://etcd-node-3-ip:2379
    fallthrough
  }
  loadbalance round_robin
  health :1053
  forward . 114.114.114.114
  cache 30
  reload
  log
  errors
}

Insert an A record into the ETCD cluster

$ ETCDCTL_API=3 /usr/local/etcd/bin/etcdctl --endpoints etcd-node-1-ip:2379,etcd-node-2-ip:2379,etcd-node-3-ip:2379 put /coredns/a/b/c '{"host":"1.1.1.1", "ttl":5}'

Parsing with dig command is successed

$ for ((i=0;i<10;i++));do dig +short c.b.a; done
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1
1.1.1.1

But parsing fails with nc or telnet commands is failed

$ for ((i=0;i<10;i++));do nc -zv c.b.a 80; done
nc: connect to c.b.a port 80 (tcp) failed: Connection refused  # Link failure is due to address non-existent, normal phenomenon
nc: getaddrinfo: No address associated with hostname  # All but the first parsing success failed
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname
nc: getaddrinfo: No address associated with hostname

[chrisohaver]

Strange. Perhaps this is a shell peculiarity? Do the CoreDNS logs show that it is receiving queries for getaddrinfo failures?

[kys1230]

There is no error message in the log. After two days of testing, it is found that this phenomenon is common in ubuntu-14.04 version, but it does not exist in 16.04/18.04. However, most of 14.04 is still running on my server.

[chrisohaver]

There is no error message in the log.

OK, but do the CoreDNS logs show that it is receiving queries for getaddrinfo failures?

[kys1230]

Here's the CoreDNS log

2019-05-05T12:01:32.785+08:00 [INFO] clientip:13484 - 50305 "A IN c.b.a. udp 23 false 512" NOERROR qr,rd 44 0.000121867s
2019-05-05T12:01:32.785+08:00 [INFO] clientip:13484 - 57239 "AAAA IN c.b.a. udp 23 false 512" NOERROR qr,rd 74 0.000193861s

Looking at the tcpdump package
Failure is to accept the results recorded by AAAA first, wait a while and then receive the results recorded by A.

Does this have anything to do with Glibc ?

The relationship between the Ubuntu version I tested and the glibc version is as follows:

ubuntu version	glibc version	problem
14.04	2.19	yes
16.04	2.23	no
18.04	2.27	no

[kys1230]

From the point of view of tcpdump grab.
No response waiting for A record
The parse is considered to have failed and the parse request is sent again.
In most cases, AAAA records respond faster than A records.

[kys1230]

The main contents of the coredns logs provided above are these two. The difference lies in the order of A records and AAAA records.

[kys1230]

I tried to switch the glibc version.
It is found that glibc-v2.19 can reproduce this problem steadily.