Network DNS

• Network DNS
  • 简介
  • DNS 解析步骤
  • DNS 缓存
  • Bind与实践
    • 安装
    • 实践
  • DNS Proxy/Relay
    • DNS Proxy与DNS Relay的功能实现差异
    • DNS Proxy的工作过程
    • 简单示例

简介

DNS的全称是Domain Name System，DNS负责主机名称之间和互联网络地址之间的映射，在我们上网或者发送电子邮件的时候，一般都会使用主机名而部署IP地址，因为前者更容易记忆，但是对于计算机，使用数字（IP地址）则更为方便。DNS能够帮助我们将主机名转换成计算机更容易识别的IP地址。从而完成主机之间通信。DNS是一个层级的分布式的数据库，以C/S架构工作，它将互联网名称（域名）和IP地址的对应关系记录下来，可以为客户端提供名称解析的功能。它允许对整个数据库各个部分进行本地控制，借助备份和缓存机制，DNS将有足够的强壮性。DNS 数据库一层级的树状结构组织，最顶级的服务器被称为【根】（root），以表示，它是所有子树的根。root将自己划分为多个子域（subdomain）,这些子域包括 com，net，org，gov，net 等等，这些子域被称为顶级域（Top Level Domain，TDL）。再进一步，各顶级域名再将自己划分成多个子域，子域还可以再划分子域，最后树的叶子节点就是某个域的主机。

每个域的名称服务器仅负责本域内的主机的名称解析，如果需要解析子域的主机，就需要再向其子域的名称服务器查询。这样一来，无论主机在哪个域内，都可以从根开始一级一级的找到负责解析此主机名称的域，然后完成域名解析。

DNS 解析步骤

客户端向某个DNS服务器发出请求，解析 www.kernel.org 的地址。

• 服务器先向根名称服务器发出查询请求，根名称服务器的地址是内置在服务器端的，根名称服务器仅返回其下负责的.org域的名称服务器的地址
• DNS 服务器向 .org 域的名称服务器发出查询请求，得到 kernel.org 域的名称服务器的地址
• DNS 服务器向 kernel.org 域的名称服务器发出查询请求，该服务器发现请求的主机 www 就是本域下的主机名，于是返回 www.kernel.org 主机地址
• DNS 服务器将得到的结果返回给客户端。

DNS 缓存

在网络通信中，域名的使用频率非常高，一个域名在某段时间内可能被反复的使用，如果每次使用都向 DNS 服务器查询，DNS服务器也向其他服务器发出查询请求的话，将会消耗大量的网络带宽，并且速度也会非常慢。因此，一般在DNS客户端的服务器端都会有缓存，负责某个域的DNS服务器可以定义客户端缓存的时间。DNS TTL 间接控制缓存，从而避免用户体验。

在网络通信中，更长的缓存对于权威DNS服务器上的DDos攻击更健壮，DNS服务提供商上的DDoS攻击已损害了几个著名的网站。研究表明，DNS缓存可以大大降低DDoS对DNS的影响，前提是缓存的持续时间比攻击时间长。

Bind与实践

bind是linux系统下的一个DNS服务程序.bind-utils是bind软件提供的一组DNS工具包,
里面有一些DNS相关的工具.主要有:dig,host,nslookup,nsupdate.使用这些工具可以
进行域名解析和DNS调试工作.

安装

环境：Centos，我们可以通过如下命令进行安装。

yum -y install bind
yum -y install bind-utils

关于相关的文件如下：
/etc/named.conf————主要配置文件
/etc/named.rfc1912.zones————zone解析库
/var/named————zone解析库对应文件。

主配置文件/etc/named.conf包括：
监听端口(listen-on port)和ip地址
服务作用范围（本机还是指定网段还是全网）（allow-query）
递归还是迭代查询(recursion)
根区域解析文件（zone），其他区域文件可以看到有个include "/etc/named.rfc1912.zones";，这下面保存了localhost的区域文件，如果新添加的，卸载这个zones文件里，里面指向了zone文件地址。然后每一个zone文件，是在/var/named下面。

#cat /etc/named.conf
options {
   listen-on port 53 { 127.0.0.1; };//ipv4监听端口和ip地址，默认只有本地的
   listen-on-v6 port 53 { ::1; };//ipv6的监听端口和ip地址
   directory    "/var/named";//指定DNS区域文件的路径
   dump-file    "/var/named/data/cache_dump.db";//DNS数据存放数据库的路径
   statistics-file "/var/named/data/named_stats.txt";//指定服务器统计信息的文件路径
   memstatistics-file "/var/named/data/named_mem_stats.txt";//记录内存使用的情况
   allow-query     { localhost; };//指定可以发送DNS请求的客户机地址段，也可以用any接受所有。
   recursion yes; // 递归还是迭代查询
   dnssec-enable yes; // dns安全扩展,可以改为no关闭
   dnssec-validation yes; //可以改为no关闭
   /* Path to ISC DLV key */
   bindkeys-file "/etc/named.iscdlv.key";//ISC DLV KEY路径
   managed-keys-directory "/var/named/dynamic";//管理密钥路径
   pid-file "/run/named/named.pid";//服务器进程id记录文件
   session-keyfile "/run/named/session.key";//会话密钥路径
};
//bind服务的日志参数
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
//根区域的配置信息
zone "." IN { // 定义zone文件，这里是定义的根域的文件位置
   type hint; //区域类型
   file "named.ca"; //区域文件名，需要手动创建。范例文件为named.localhost
};
include "/etc/named.rfc1912.zones"; // 把named.rfc1912.zones文件包含进来
include "/etc/named.root.key"; // 把/etc/named.root.key文件包含进来

type字段指定区域的类型，对于区域的管理至关重要，一共分为5种：

接着我们来看解析库里面的内容：

cat /etc/named.rfc1912.zones

# 截取了其中一个
zone "localhost.localdomain" IN {
    type master;
    file "named.localhost";
    allow-update { none; };
};

意义如下：
localhost : 在实际的生产服务器上，这里填写的是你的完整域，也就是你从云计算服务商购买申请的域名是什么就填写什么。
type master; : 前面我们见过type hint ，表明是根dns。这里的master，表明是主dns，还有一个值是slave，表明是从dns。当然还有转发，后面会接受。
file "named.localhost"; : 解析的记录文件。这个named.localhost可以自己定义，定义完成后需要在 /var/named/ 目录下有一个名称相同的文件与之匹配。
allow-update { none; }; : 是否允许客户端动态更新，none表明不允许。

接下来我们来看看/var/named/目录下有哪些文件。

我们可以看到这些就是解析的文件，在文件里面的内容中我们可以看到。我们在NAPTR记录中将scfcfpool05映射成了_sip._udp.scscf01，在SRV记录条目中将_sip._udp.scscf01映射成了A记录条目中的scscf01，在A记录中就有我们对应的IP（10.107.171.33）了。

我们可以通过nslookup来进行解析。

# NAPTR 记录查询
nslookup -type=NAPTR scfcfpool05.ims.mnc001.mcc460.3gppnetwork.org
# SRV 记录查询
nslookup -type=SRV scfcfpool05.ims.mnc001.mcc460.3gppnetwork.org
# NAPTR 记录查询
nslookup -type=A scfcfpool05.ims.mnc001.mcc460.3gppnetwork.org

实践

首先我们将本机设置为DNS服务器，首先我们修改/etc/named.conf文件，然后重启我们的named服务。
并且解析我们的scfcfpool05.ims.mnc001.mcc460.3gppnetwork.org来看一下解析的服务器地址，当然这是解析不了的因为我们还没有添加到解析库中。

# 需要删除ipv6
listen-on port 53 { 10.0.0.46; };//改成我们的主机
allow-query { any; };

systemctl restart named
systemctl status named

紧接着我们在/etc/named.rfc1912.zones中添加我们的解析项（区域），并且添加我们的文件vi /var/named/ims.mnc001.mcc460.3gppnetwork.org，里面的内容就从其他文件里面抄一下改改。

zone "ims.mnc001.mcc460.3gppnetwork.org" IN {
    type master;
    file "ims.mnc001.mcc460.3gppnetwork.org";
};

添加相关NAPTR、SVR和A记录。我们只需要知道

$TTL 3H
@       IN SOA  @ rname.invalid. (
                                        0       ; serial
                                        1D      ; refresh
                                        1H      ; retry
                                        1W      ; expire
                                        3H )    ; minimum
        NS      @
        A       127.0.0.1
        AAAA    ::1
;NAPTR Query:
scfcfpool05  NAPTR  50 50 "s" "SIP+D2U" "" _sip._udp.scscf01
scfcfpool05  NAPTR  50 50 "s" "SIP+D2U" "" _sip._udp.scscf02
scfcfpool05  NAPTR  50 50 "s" "SIP+D2U" "" _sip._tcp.scscf01
scfcfpool05  NAPTR  50 50 "s" "SIP+D2U" "" _sip._tcp.scscf02
;SRV Query:
_sip._udp.scscf01   SRV    0 0 5070 scscf01
_sip._tcp.scscf01   SRV    0 0 5070 scscf01
_sip._udp.scscf02   SRV    0 0 5070 scscf02
_sip._tcp.scscf02   SRV    0 0 5070 scscf02
;A Query:
scscf01  A 10.0.0.46
scscf02  A 10.0.0.46
scscf02  A 10.0.0.46
scscf02  A 10.0.0.46
scscf02  A 10.0.0.46

将该文件添加到我们的named组下

chown named ims.mnc001.mcc460.3gppnetwork.org

然后我们修改我们DNS的解析。

vim /etc/resolv.conf
nameserver 10.0.0.46

最后重启我们的服务并进行测试。

systemctl restart named
nslookup -type=NAPTR scfcfpool05.ims.mnc001.mcc460.3gppnetwork.org
nslookup -type=SRV  _sip._udp.scscf01.ims.mnc001.mcc460.3gppnetwork.org.
nslookup -type=A  scscf01.ims.mnc001.mcc460.3gppnetwork.org.

通过层层的解析，最后我们通过A记录解析出我们的IP。

DNS Proxy/Relay

在使用了DNS代理/中继（DNS Proxy/Relay）功能的组网中，DNS Client将DNS 请求报文直接发送给DNS Proxy/Relay。DNS Proxy/Relay将收到的DNS请求报文转发至DNS Server，并在收到DNS Server的应答报文后将其返回给DNS Client，从而实现域名解析。由此，当DNS Server的地址发生变化时，只需改变DNS
Proxy/Relay上的配置，无需逐一改变局域网内每个DNS Client的配置，从而简化了网络管理。

DNS Proxy与DNS Relay的功能实现差异

—— DNS Relay和DNS Proxy功能相同，二者的实现差异在于转发DNS请求报文前是否会先查询本地域名解析表（包
括静态域名解析表以及本地域名缓存表）。
—— DNS Proxy接收到DNS Client的DNS请求报文后会先查找本地域名解析表，如果未查询到对应的解析表项，才将
DNS请求报文转发给DNS Server。
—— DNS Relay接收到DNS Client的DNS请求报文后不会查询本地域名解析表，而是直接将其转发给DNS Server进行
解析。一方面节省了DNS Relay上的DNS缓存开销，另一方面，保证了DNS Client获取解析结果的实时性（如果
DNS Server上域名与IP地址发生变化而DNS Proxy的缓存表未及时更新，会导致DNS Client获取的解析结果错
误）。

设备使能DNS Proxy功能后，可用于转发内部的DNS客户端和外部DNS服务器之间的DNS请求和应答报文，当DNS
服务器地址发生变化时，只需要在DNS Proxy进行配置，不需要在DNS客户端上进行逐一配置，便于网络的集中管
理。
DNS Relay和DNS Proxy功能相同，区别在于DNS Proxy接收到DNS客户端的DNS查询报文后会查找本地缓存，而
DNS Relay不会查询本地缓存，而是直接转发给DNS服务器进行解析，从而节省了DNS Relay上的DNS缓存开销。

DNS Proxy的工作过程

1.DNS Client将DNS请求报文发送给DNS Proxy，即请求报文的目的地址为DNS Proxy的IP地址。
2.DNS Proxy收到请求报文后，先查找本地静态域名解析表，再根据查询结果判断是否继续查找本地域名缓存表。
——如果查询到对应的解析表项，则DNS Proxy直接通过DNS应答报文将域名解析结果返回给DNS Client。
——如果查询不到对应的解析表项，则DNS Proxy将报文转发给DNS Server，通过DNS Server进行域名解析。
3.DNS Proxy收到DNS Server的应答报文后，记录域名解析的结果，并将报文转发给DNS Client。

只有当DNS Proxy上存在DNS Server地址，且存在到达DNS Server的路由时，DNS Proxy才会向DNS
Server发送域名解析请求。否则，DNS Proxy不会向DNS Server发送域名解析请求，也不应答DNS Client的请求

简单示例

配置Server1为DNS服务器，并在AR1中开启DNS Proxy，命令如下：

dns resolve
dns server 10.1.1.2
dns proxy enable
interface GigabitEthernet0/0/0
ip address 192.168.1.1 255.255.255.0
interface GigabitEthernet0/0/1
ip address 10.1.1.1 255.255.0.0
ip route-static 0.0.0.0 0.0.0.0 10.1.1.2