本文联合作者：@予栖 @遐宇
问题的背景
时间回溯到两个月之前，我突然被前线同学拉到一个会议上，时间差不多是深夜，一个核心客户突然在会议上反馈：
“我们切了流量到alinux3上之后，ingress突然多了很多404报错，你们兼容性是不是有问题？”
看到404这个响应，我第一反应就是，这是个纯粹的业务问题，404响应作为HTTP领域最出圈的一个响应码，表征的含义就是“404 Not Found”，得到这个响应，标志着TCP层面是正常工作的，HTTP层面也可以正常处理，况且用户并非所有的流量都出现了异常，因此我让客户对业务进行排查，但是客户坚持认定，是我们的兼容性问题，于是，我们开始了针对这个问题的排查。
问题的排查过程
查找报错原因
客户在回退发布后，已经没有了现场，好在ingress默认开启了sls记录日志，我们可以很快找到当时出现的404异常的日志分布 ：
可以看到，确实存在客户所说的现象，即进行了流量的切换之后，在某个时间点，404的频率有了较大的升高，而在客户进行止血措施之后，频率又迅速回落，随后我们按照多个维度查看404的特征，在进行404现象与upstream addr关系的排查是发现了一个很特别的现象，绝大多数的404响应，其实是local-project这个upstream发出的：
这个upstream指向的是127.0.0.1，是default backend，按照经验，不该有很多流量转发到这个backend，于是我们联系客户开启调试日志后进行一次复现，果然发现了问题所在：
nginx: [emerg] host not found in upstream "************.******.cn"AI 代码解读
这条核心的日志解释了404的成因: ingress存在部分配置没有正常加载的情况，原因是由于某一些域名在进行域名解析时出现了失败。
随即我们向客户反馈了这个现象，然而客户表示，这个域名是他们一直在使用的域名，不是新增的，其他业务也没有遇到类似的问题，甚至之前的ingress也没有遇到过这个问题。。。
于是我们在客户的环境中，指定coredns作为server进行了测试和验证，验证的结果如下：
-
在节点上使用dig测试，可以正常解析。
-
切换到ingress容器中进行测试，无论是新增的还是存量的，均无法解析。
也就是说，相同的域名和server，在节点上和在容器中，竟然有表现上的差异！！！
追查差异根因
遇到这样的问题，首先进行了抓包分析，在客户的环境中我们发现了一个现象，当我们发起DNS查询的时候，会出现类似以下的现象：
-
同时发起A和AAAA记录的查询。
-
A记录返回了正常的响应。
-
AAAA记录返回了NXDOMAIN。
而在没有进行任何配置，直接从控制台创建出来的ACK集群中，他的表现是这样的：
-
同时发起A和AAAA记录的查询。
-
A记录返回了正常的响应。
-
AAAA没有返回有效的解析结果，但是响应码不是NXDOMAIN。
我们怀疑是这个差异，即AAAA记录返回NXDOMAIN与否，影响了进行dns查询时得到的结果，如果能够让dns的AAAA记录查询返回空的结果而不是NXDOMAIN，这个问题应该就可以解决了。我们排查了客户的CoreDNS配置文件，对比默认的配置，发现客户环境下的配置文件多了以下一段配置：
查询文档（https://coredns.io/plugins/template/）后得知，这一段配置生效的作用是：
-
对于53端口的服务生效。
-
对于所有查询了AAAA记录的请求生效。
-
将符合条件的请求的rcode，也就是返回码设置为NXDOMAIN。
于是这个问题也就能解释通了，客户添加的这一段配置，导致了CoreDNS在表现上的差异，我们建议客户参照官网文档对配置进行修改后验证（https://help.aliyun.com/document_detail/380963.html#section-6jf-fgj-j2f），果然，修改了针对AAAA记录的默认行为后，在node和ingress的pod内进行dns查询就都可以正常响应了！！
到这里，问题就转变成了，为什么相同的DNS响应，即A记录正常回复，AAAA记录返回NXDOMAIN，在节点上就没问题，在容器内就无法解析了呢？
差异背后的标准实现
在复现了客户的问题之后，我们收敛了问题的范围：
-
对于节点和pod中的dns查询请求，都发出了A和AAAA两条查询的报文。
-
CoreDNS针对节点和pod发出的dns查询，回复时一样的，即A记录正常返回，AAAA记录返回NXDOMAIN。
在这个基础上，我们讲目光转移到了dns客户端本身，对于节点和pod来说，他们进行dns查询的客户端确实存在着差异：
-
对于节点来说，curl等工具是依赖于getaddrinfo()进行域名的解析，节点上默认提供getaddrinfo()的静态库时glibc提供的
-
对于以alpine为基础镜像的ingress容器来说，getaddrinfo()则是由musl实现的，musl提供了更加简洁和高效的POSIX标准库实现（ https://www.musl-libc.org/intro.html），在嵌入式场景中广泛使用。
随后我们分析了musl和glibc的代码，发现他们在针对相同的域名，两种不同类型的记录的查询结果有差异，尤其是其中一条的返回码是NXDOMAIN时，的确采取了不同的处理方式：
-
glibc的处理中，会将所有正常返回的记录结果都提供给调用方。
-
musl的处理中，针对出现AAAA有NXDOMAIN时，整个域名都会被认为是无法正常解析的，处理逻辑如下：
static int name_from_dns(struct address buf[static MAXADDRS], char canon[static 256], const char *name, int family, const struct resolvconf *conf)
{
struct dpc_ctx ctx = { .addrs = buf, .canon = canon };
static const struct { int af; int rr; } afrr[2] = {
{ .af = AF_INET6, .rr = RR_A },
{ .af = AF_INET, .rr = RR_AAAA },
};
// 分别获取ipv4和ipv6，也就是A与AAAA的解析记录
for (i=0; i<2; i++) {
if (family != afrr[i].af) {
qlens[nq] = __res_mkquery(0, name, 1, afrr[i].rr,
0, 0, 0, qbuf[nq], sizeof *qbuf);
if (qlens[nq] == -1)
return 0;
qtypes[nq] = afrr[i].rr;
qbuf[nq][3] = 0; /* don't need AD flag */
/* Ensure query IDs are distinct. */
if (nq && qbuf[nq][0] == qbuf[0][0])
qbuf[nq][0]++;
nq++;
}
}
// 对于每一个记录，如果出现了retcode=3即NXDOMAIN，则会返回没有任何解析结果
for (i=0; i<nq; i++) {
if (alens[i] < 4 || (abuf[i][3] & 15) == 2) return EAI_AGAIN;
if ((abuf[i][3] & 15) == 3) return 0;
if ((abuf[i][3] & 15) != 0) return EAI_FAIL;
}
for (i=nq-1; i>=0; i--) {
ctx.rrtype = qtypes[i];
__dns_parse(abuf[i], alens[i], dns_parse_callback, &ctx);
}
if (ctx.cnt) return ctx.cnt;
return EAI_NODATA;
}
AI 代码解读
问题到了这里也就真相大白了：
-
由于业务原因，客户主动将一部分域名的AAAA记录设置为NXDOMAIN（尤其是在IPv6双栈的演进过程中）。
-
由于musl所采用的处理逻辑，当客户进行设置后，所有基于alpine镜像的C程序针对配置了双栈，即会请求AAAA记录的域名，都会产生无法解析的报错。
-
客户进行了变更，然而由于ingress无法验证域名，导致新配置无法加载。
-
客户变更结束后进行流量切换，新域名的流量由于配置没有正常加载，被转发到了default的upstream，产生404报错。
问题的背后
在云原生场景下，alpine的使用极为广泛，不仅仅是ingress-nginx，大量的开源镜像都是基于alpine来实现轻量的体积，与此同时，由于IPv6和双栈的不断推进，在双栈的演化过程中，不可避免得会遇到因为兼容性（避免dns反复重试）而进行DNS的层面配置的情况，因此，由于musl的实现与glibc有差异而产生的坑也很有可能在其他客户身上再次出现，不得不防。
在这个问题发现以后，我们特地查询了RFC文档中对AAAA和NXDOMAIN的规范：
-
AAAA记录设计之初就是为了能够将iPv6地址作为域名解析的结果进行返回 https://www.rfc-editor.org/rfc/rfc3596。
-
NXDOMAIN则在多个rfc中不断完善其描述，在rfc8020中的较新版本对他的补充定义是:
The DNS protocol [RFC1035] defines response code 3 as "Name Error", or "NXDOMAIN" [RFC2308], which means that the queried domain name does not exist in the DNS. Since domain names are represented as a tree of labels ([RFC1034], Section 3.1), nonexistence of a node implies nonexistence of the entire subtree rooted at this node. The DNS iterative resolution algorithm precisely interprets the NXDOMAIN signal in this manner. If it encounters an NXDOMAIN response code from an authoritative server, it immediately stops iteration and returns the NXDOMAIN response to the querier. This document clarifies possible ambiguities in [RFC1034] that did not clearly distinguish Empty Non-Terminal (ENT) names ([RFC7719]) from nonexistent names, and it refers to subsequent documents that do. ENTs are nodes in the DNS that do not have resource record sets associated with them but have descendant nodes that do. The correct response to ENTs is NODATA (i.e., a response code of NOERROR and an empty answer section).AI 代码解读
rfc中对NXDOMAIN的定义是针对整个域名的，即NXDOMAIN出现应该是这个域名所有的记录都无法被解析的情况下，同时对这种一部分记录没有的场景增加了建议，推荐返回NODATA，也就是最上方官网文档中建议的配置。
显然，musl的实现是完全遵照rfc的规范实现的，而glibc作为默认的实现，其实并没有严格按照rfc标准进行，但是实际在切换到云原生容器化的过程中，alpine的“符合标准”的行为却实打实的产生了差异，并造成了业务上的风险，这也是我们在容器化过程中不得不防的坑。
