LinuxDNS分析从入门到放弃（记一次有趣的dns问题排查记录，ping 源码分析，getaddrinfo源码分析）

PS：要转载请注明出处，本人版权所有。

PS: 这个只是基于《我自己》的理解，

如果和你的原则及想法相冲突，请谅解，勿喷。

环境说明

ubuntu 18.04

前言

我们这里有一块嵌入式板卡，当我们通过PING测试内网IP时，发现外网IP访问正常，但是测试域名访问一直报unknown host。一般来说，在ubuntu里面，我们遇到域名不能访问，反手就是去设置/etc/resolv.conf文件里面的nameserver为114.114.114.114。但是万万没有想到，这次我们这样改了之后，还是访问报unknown host。

当时我就人麻了，但是我仿佛灵光一闪，想到了一个问题：为何以前我们修改了/etc/resolv.conf文件就DNS就正常了，但是这里同样修改了这个文件，就不正常工作？此外，/etc/resolv.conf文件是干嘛的，为何改了DNS就有效了？

要回答以上问题，根本原因就是要了解Linux平台里面DNS的详细工作流程，于是我踏上了看源码之旅。

探索之旅

在这里，我们第一件事情就是想到，当我们ping一个域名，或者我们在浏览器里面输入了一个域名，然后访问的那一刻发生了什么？

首先，当我们进行网络编程的时候，我们不管是send udp msg还是send tcp msg，我们都是需要构建一个struct sockaddr结构，这个结构里面包含了访问的地址，端口等等信息。但是这里的地址是ip地址，并不是域名地址，因此可以猜测，在浏览器访问或者ping域名之前，肯定做了dns查询工作，然后将域名转换之后，得到ip地址才构建出struct sockaddr结构，然后才开始网络访问的操作的。

下面我去翻阅了ping的源码，在https://git.savannah.gnu.org/cgit/inetutils.git/tree/ping/libping.c?h=v2.4 中的ping_set_dest 函数中，有一个将host转换为struct sockaddr的方法引起了我的注意，他就是：getaddrinfo / gethostbyname。下面是ping的简要工作流程：

在https://git.savannah.gnu.org/cgit/inetutils.git/tree/ping/ping.c?h=v2.4中，main函数中调用了argp_parse，这里面会调用parse_opt，在这里有一个重要的ping_type函数指针在这里设置了，如果我们不配置任何参数的话，那么就是调用的ping_echo函数。
在https://git.savannah.gnu.org/cgit/inetutils.git/tree/ping/ping.c?h=v2.4中，main函数中调用了ping_init，初始化了ICMP的socket，并记录到句柄PING中。
在经历各种初始化后，就会调用ping_type，后面我们默认分析ping_echo。
在https://git.savannah.gnu.org/cgit/inetutils.git/tree/ping/ping_echo.c?h=v2.4中，ping_echo中回去调用ping_set_dest设置参数，同时调用ping_run循环通过send_to发送ping icmp报文。
在https://git.savannah.gnu.org/cgit/inetutils.git/tree/ping/libping.c?h=v2.4中，ping_set_dest 调用getaddrinfo解析域名。

getaddrinfo / gethostbyname

首先，我们在查这两个方法之前，可以猜测他们的一个功能就是：这两个函数可能拿着域名，去访问了域名服务器，然后解析出ip地址，并且构造了struct sockaddr结构并返回。

因此我们去看看这两个函数相关的man介绍和源码：

根据man手册：https://man7.org/linux/man-pages/man3/getaddrinfo.3.html ，我们可以知道，getaddrinfo已经包含了gethostbyname的工作，因此我们就只需要分析这个方法就行。

getaddrinfo 参数分析

我们先来看看这个函数的参数含义

//重要的参数结构体

struct addrinfo {

    int              ai_flags;

    int              ai_family;

    int              ai_socktype;

    int              ai_protocol;

    socklen_t        ai_addrlen;

    struct sockaddr *ai_addr;

    char            *ai_canonname;

    struct addrinfo *ai_next;

};

int getaddrinfo (const char *name, const char *service, const struct addrinfo *hints, struct addrinfo **pai);

//根据https://man7.org/linux/man-pages/man3/getaddrinfo.3.html，我们可以知道：

//name: 域名

//service: 服务，注意这里这个服务会让我们重新复习一遍计算机网络。

//hints: 就是填写struct addrinfo里面的属性，然后getaddrinfo根据这些特殊指定的属性，将对应的struct addrinfo返回回来。

//pai: 此函数返回的一个链表，其中包含了符合要求的struct addrinfo信息。

//其实我们从pai可以知道，当返回有值时，意味着我们知道了一个域名和服务对应的网络地址，然后我们就可以在connect,bind中使用pai->ai_addr了。

getaddrinfo 例子调试分析

注意：我这里是事后写本文的时候，才发现需要下面的内容。由于getaddrinfo的实现特殊性，其不是很方便查看源码，因此采取strace + gdb + simple example方式来分析此函数的实现。

首先下面是我的simple example

#include <sys/types.h>

#include <sys/socket.h>

#include <netdb.h>

#include <stdio.h>

#include <sys/socket.h>

#include <netinet/in.h>

#include <arpa/inet.h>

#include <string.h>

int main(int argc, char * argv[])

{

		struct addrinfo hints, *res;

		  memset (&hints, 0, sizeof (hints));

  hints.ai_family = AF_INET;

  hints.ai_flags = AI_CANONNAME;

	if (0 > getaddrinfo("baidu.com", NULL, &hints, &res)){

		perror("get error:");

		return -1;

	}

	struct sockaddr_in * get_addr = res->ai_addr;

	printf("ip for baidu: %s\n", inet_ntoa(get_addr->sin_addr));

	return 0;

}

然后gcc test.c -o test -g 生成此执行文件。下面是执行此函数的结果图片：

下面是一些读取源码需要的单词简写：

IDNA: Internationalizing Domain Names in Applications
NSCD: name service cache daemon
NSS: Name Services Switch
CNAME: canonical name (规范化名字)

下面是resolv.conf的文件内容：

# resolve.conf 内容

# This file is managed by man:systemd-resolved(8). Do not edit.

#

# This is a dynamic resolv.conf file for connecting local clients to the

# internal DNS stub resolver of systemd-resolved. This file lists all

# configured search domains.

#

# Run "systemd-resolve --status" to see details about the uplink DNS servers

# currently in use.

#

# Third party programs must not access this file directly, but only through the

# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,

# replace this symlink by a static file or a different symlink.

#

# See man:systemd-resolved.service(8) for details about the supported modes of

# operation for /etc/resolv.conf.

# nameserver 127.0.0.53

nameserver 8.8.8.8

options edns0

下面是strace ./test 输出的部分节选（包含了/etc/resolv.conf的内容）

//打开resolve.conf

openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3

fstat(3, {st_mode=S_IFREG|0644, st_size=736, ...}) = 0

read(3, "# This file is managed by man:sy"..., 4096) = 736

read(3, "", 4096)                       = 0

close(3)

//通过resolve.conf的dns服务器，查询dns

//这里有个小知识：dns服务器的默认端口是53，详细可以通过/etc/protocol，/etc/services查看

socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, 16) = 0

poll([{fd=3, events=POLLOUT}], 1, 0)    = 1 ([{fd=3, revents=POLLOUT}])

sendto(3, "5\244\1\0\0\1\0\0\0\0\0\1\5baidu\3com\0\0\1\0\1\0\0)\4\260"..., 38, MSG_NOSIGNAL, NULL, 0) = 38

poll([{fd=3, events=POLLIN}], 1, 5000)  = 1 ([{fd=3, revents=POLLIN}])

ioctl(3, FIONREAD, [70])                = 0

recvfrom(3, "5\244\201\200\0\1\0\2\0\0\0\1\5baidu\3com\0\0\1\0\1\300\f\0\1\0"..., 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("8.8.8.8")}, [28->16]) = 70

close(3)                                = 0

首先我们要调试glibc的话，需要安装glibc的调试符号：

sudo apt-get install libc6-dbg

cd /usr/src/glibc

tar -xf glibc-{version}.tar.xz

下面通过GDB 结合 GLIBC的debug info开始调试程序，分析出getaddrinfo中我想关注的部分。

首先我们调试得到打开/etc/resolv.conf的实现：

gdb ./test

b fopen

# 设置gdb搜索源文件目录，注意你下断点时，对应源码的相对路径

(gdb) set directories /usr/src/glibc/glibc-2.27/xxxx

在多次运行后，抓到打开/etc/resolv.conf的地方，其堆栈如下：

#0  _IO_new_fopen (filename=filename@entry=0x7ffff7b98cea "/etc/resolv.conf", mode=mode@entry=0x7ffff7b9578c "rce") at iofopen.c:88

#1  0x00007ffff7b25c0f in __resolv_conf_load (preinit=preinit@entry=0x0) at res_init.c:553

#2  0x00007ffff7b28459 in __resolv_conf_get_current () at resolv_conf.c:162

#3  0x00007ffff7b26cad in __res_vinit (statp=0x7ffff7dd1bc0 <_res>, preinit=preinit@entry=0) at res_init.c:609

#4  0x00007ffff7b27e50 in maybe_init (preinit=false, ctx=0x555555756530) at resolv_context.c:122

#5  context_get (preinit=false) at resolv_context.c:184

#6  __GI___resolv_context_get () at resolv_context.c:195

#7  0x00007ffff7ae790e in gaih_inet (name=name@entry=0x555555554924 "baidu.com", service=<optimized out>, req=req@entry=0x7fffffffdeb0, pai=pai@entry=0x7fffffffd9c8,

    naddrs=naddrs@entry=0x7fffffffd9c4, tmpbuf=tmpbuf@entry=0x7fffffffda30) at ../sysdeps/posix/getaddrinfo.c:767

#8  0x00007ffff7ae9c84 in __GI_getaddrinfo (name=<optimized out>, service=<optimized out>, hints=0x7fffffffdeb0, pai=0x7fffffffdea0) at ../sysdeps/posix/getaddrinfo.c:2300

#9  0x000055555555483b in main (argc=1, argv=0x7fffffffdfd8) at test.c:17

因此我们得到了getaddrinfo的打开resolv.conf的调用路径，其值如下：

getaddrinfo-->gaih_inet->__resolv_context_get()->context_get()->maybe_init()->__res_vinit()->__resolv_conf_get_current()->__resolv_conf_load() 这里面会打开resolv.conf

注意，当真正的打开了resolv.conf后，其还会解析此文件，这个部分就不在本文进行分析了。

用同样的方法，对connect下断点，得到了访问dns服务器的堆栈信息：

#0  __libc_connect (fd=3, addr=addr@entry=..., len=16) at ../sysdeps/unix/sysv/linux/connect.c:26

#1  0x00007ffff71b4b20 in reopen (statp=statp@entry=0x7ffff7dd1bc0 <_res>, terrno=terrno@entry=0x7fffffffc0a8, ns=ns@entry=0) at res_send.c:977

#2  0x00007ffff71b5e0b in send_dg (ansp2_malloced=0x0, resplen2=0x0, anssizp2=0x0, ansp2=0x0, anscp=0x7fffffffd168, gotsomewhere=<synthetic pointer>,

    v_circuit=<synthetic pointer>, ns=0, terrno=0x7fffffffc0a8, anssizp=0x7fffffffc1d0, ansp=0x7fffffffc098, buflen2=0, buf2=0x0, buflen=38,

    buf=0x7fffffffc200 "\254\212\001", statp=<optimized out>) at res_send.c:1078

#3  __res_context_send (ctx=ctx@entry=0x555555756530, buf=buf@entry=0x7fffffffc200 "\254\212\001", buflen=buflen@entry=38, buf2=buf2@entry=0x0, buflen2=buflen2@entry=0,

    ans=<optimized out>, ans@entry=0x7fffffffcd10 "cxaPfi", anssiz=<optimized out>, ansp=<optimized out>, ansp2=<optimized out>, nansp2=<optimized out>,

    resplen2=<optimized out>, ansp2_malloced=<optimized out>) at res_send.c:522

#4  0x00007ffff71b34d1 in __GI___res_context_query (ctx=ctx@entry=0x555555756530, name=name@entry=0x555555554924 "baidu.com", class=class@entry=1, type=type@entry=1,

    answer=answer@entry=0x7fffffffcd10 "cxaPfi", anslen=anslen@entry=1024, answerp=0x7fffffffd168, answerp2=0x0, nanswerp2=0x0, resplen2=0x0, answerp2_malloced=0x0)

    at res_query.c:216

#5  0x00007ffff71b428d in __res_context_querydomain (domain=0x0, answerp2_malloced=0x0, resplen2=0x0, nanswerp2=0x0, answerp2=0x0, answerp=0x7fffffffd168, anslen=1024,

    answer=0x7fffffffcd10 "cxaPfi", type=1, class=1, name=0x555555554924 "baidu.com", ctx=0x555555756530) at res_query.c:601

#6  __GI___res_context_search (ctx=ctx@entry=0x555555756530, name=name@entry=0x555555554924 "baidu.com", class=class@entry=1, type=type@entry=1,

    answer=answer@entry=0x7fffffffcd10 "cxaPfi", anslen=anslen@entry=1024, answerp=0x7fffffffd168, answerp2=0x0, nanswerp2=0x0, resplen2=0x0, answerp2_malloced=0x0)

    at res_query.c:370

#7  0x00007ffff73c7f0c in gethostbyname3_context (ctx=ctx@entry=0x555555756530, name=name@entry=0x555555554924 "baidu.com", af=af@entry=2,

    result=result@entry=0x7fffffffd7d0, buffer=buffer@entry=0x7fffffffda40 "\377\002", buflen=buflen@entry=1024, errnop=0x7ffff7fca440, h_errnop=0x7ffff7fca4a4, ttlp=0x0,

    canonp=0x7fffffffd7c8) at nss_dns/dns-host.c:218

#8  0x00007ffff73c8928 in _nss_dns_gethostbyname3_r (name=name@entry=0x555555554924 "baidu.com", af=af@entry=2, result=result@entry=0x7fffffffd7d0,

    buffer=0x7fffffffda40 "\377\002", buflen=1024, errnop=errnop@entry=0x7ffff7fca440, h_errnop=0x7ffff7fca4a4, ttlp=0x0, canonp=0x7fffffffd7c8) at nss_dns/dns-host.c:164

#9  0x00007ffff7ae7e6f in gaih_inet (name=name@entry=0x555555554924 "baidu.com", service=<optimized out>, req=req@entry=0x7fffffffdeb0, pai=pai@entry=0x7fffffffd9c8,

    naddrs=naddrs@entry=0x7fffffffd9c4, tmpbuf=tmpbuf@entry=0x7fffffffda30) at ../sysdeps/posix/getaddrinfo.c:885

#10 0x00007ffff7ae9c84 in __GI_getaddrinfo (name=<optimized out>, service=<optimized out>, hints=0x7fffffffdeb0, pai=0x7fffffffdea0) at ../sysdeps/posix/getaddrinfo.c:2300

#11 0x000055555555483b in main (argc=1, argv=0x7fffffffdfd8) at test.c:17

注意，这里connect的堆栈信息由于struct sockaddr的原因，无法判断是否真实访问的是8.8.8.8，因此我们可以尝试将其转换回（通过inet_ntoa转换ip，通过ntohs转换端口）struct sockaddr_in来分析，分析结果（IP地址，端口号）如下图：

因此我们得到了getaddrinfo的访问8.8.8.8 dns服务器的调用路径，其值如下：

getaddrinfo-->gaih_inet->_nss_dns_gethostbyname3_r->gethostbyname3_context->__res_context_search->__res_context_querydomain->__res_context_query->__res_context_send->send_dg->reopen->__libc_connect 连接 dns服务器，解析dns

特别注意：

这里仅仅是描述了通过dns服务器得到ip的过程，其实相对于getaddrinfo的dns解析来说，这只是其中的一部分，还有通过类似nscd（有兴趣可以去看看man systemd-resolved）等等来解析的方式，这些内容感兴趣可以去看看。

后记

最后，回到了本文的开始，经过上述的分析后，我找到了我的问题的本质原因。我遇到的问题的本质原因是：由于某些特殊原因导致了connect 114.114.114.114:53 服务器的时候报错了，导致解析域名失败，当我换一个域名服务器（8.8.8.8）就解决了。

总的来说，本文从ping baidu.com入手，然后分析了ping的源码，得到了我们要分析的重点getaddrinfo。然后我们由于构造一个小例子来分析getaddrinfo的源码，最终得到了/etc/resolv.conf是因为什么原因生效的。

通过本文的分析，相信我们对DNS的解析过程是有了一个比较清晰的了解了，以后遇到类似的问题也能够有一个好的思路来解决问题。

参考文献

打赏、订阅、收藏、丢香蕉、硬币，请关注公众号（攻城狮的搬砖之路）