详解域名解析服务
目录
域名系统简介
完全限定域名
域名解析流程
dns资源记录
域名解析返回码
BIND
配置⽂件
RNDC
CoreDNS
配置⽂件
域名系统简介
DNS全称Domain Name System，即域名系统，主要作用是实现域名和IP地址之间的相互解析，提供这种解析服务的就是DNS服务器，这些服务器本质上是和IP映射关系的数据库，宏观上组成了域名解析分布式集群。
域名解析服务器集群是一种树状结构，树的顶端是根域名服务，其下是顶级域名服务，再下依次是次级域名服务，三级域名服务等。如google.com是一个次级域名，而www.google.com是一个三级域名。
全世界有13组根域名服务器（各国还会维护一些根镜像服务器），通过根域名可以找到各顶级域名服务器，依此类推。对互联⽹上某级域名直接负责(即可解析)的域名服务器称为权威DNS服务器, 而直接服务于⽹络终端设备(也即DNS客⼾端, 如个⼈计算机, 应⽤服务器等)的通常是LocalDNS LocalDNS即本地DNS服务器。本地DNS服务器可以缓存域名和IP的映射关系, 也可以⾃ 定义私有域名, 而对于互联⽹域名则会请求上层的域名服务器。
完全限定域名
完全限定域名(Fully Qualified Domain Name, FQDN) ⼜称完全资格域名, 绝对域名, 完整域名 等, 它是包含从主机域到顶级域到根域的完整域名结。通常情况下我们习惯使⽤⾮完全限定域名，非完全限定域名形如 google.com , www.google.com 等, 域名均是以顶级域(如com)作为结尾。但完全限定域名是以根域结尾的。根域以 . 表⽰, 因此 www.google.com. 才是完全限定域名。完全限定域名的意义在于它没有模糊空间, 只能⽤⼀种⽅式解析。
⼀般而⾔, DNS客⼾端(通常操作系统内置)都会默认为应⽤请求的域名追加根域以构成完全限定域名供DNS服务器进⾏解析, 所以我们通常将根域省略。但有时候情况却不⼀样。
如 /etc/resolv.conf 是Linux系统上DNS客⼾端默认的域名解析配置⽂件, 假设其中作如下配置:
nameserver 10.43..10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5- nameserver: 域名解析服务器地址, 表⽰默认情况下域名解析请求发往之处, 这个字段通常是必须的, 否则客⼾端只能依靠 /etc/hosts 的固定映射进⾏有限解析。
- search: ⾮完全限定域名的搜索路径，DNS客⼾端会依据该字段指定的搜索路径列表，依次将这些路径拼接到请求的域名之后，形成新的域名向DNS服务器发出请求，⼀旦解析完成就不再继续尝试。如原始域名请求为 foo.bar , 则依此配置, DNS客⼾端将依此向DNS服务器发送 foo.bar.default.svc.cluster.local. , foo.bar.svc.cluster.local. , foo.bar.cluster.local. 请求, 当上述请求均⽆法解析时再发送 foo.bar. 请求。但搜索路径不会对完全限定域名⽣效. 如果原始请求为 foo.bar. , 则DNS客⼾端只会发送原始请求。
- options ndots: 请求域名的点号阈值, 只有当原始请求的域名中的点号数量低于该值时, 才会让搜索路径⽣效, 进⾏完全限定域名的拼接。如果该值为 1 , 则对原始域名 foo.bar 就不会进⾏域名拼接, 直接发起请求了。
域名解析流程
域名解析查询主要分为递归和迭代两种⽅式:
- 递归查询: DNS客⼾端向DNS解析服务器发起域名解析请求, DNS服务器要么返回域名对应的IP地址, 要么返回找不到的错误。递归查询⼀般发⽣在⽹络终端设备与本地DNS服务器之间, 因此本地DNS服务器通常⼜称为递归DNS服务器。
- 迭代查询: DNS客⼾端向DNS解析服务器发起域名解析请求, DNS服务器会返回"距离最近"的顶级, 次级或权威域名服务器, 不会直接返回解析结果, DNS客⼾端需要再次向返回的域名服务器发出域名解析请求。迭代查询⼀般发⽣在DNS服务器与与DNS服务器之间, 发起请求的DNS服务器充当了DNS客⼾端的⻆⾊, 本地DNS服务器通常就是向各级域名服务器完成了迭代查询请求后将最终解析结果返回给终端设备(当然本地DNS服务器的上层也可能是⼀个递归DNS服务器)。
- 客⼾端通过域名发起⽹络请求, 本地解析器⾸先查询/etc/hosts本地映射和本地缓存, 查询不到后通过/etc/resolve.conf中配置的本地域名服务器发起域名解析请求。通常这是⼀次递归查询。
- 本地域名服务器会⾸先查询其缓存或本地配置的域名映射, 查询不到后再以递归的⽅式向上层DNS服务器发起域名解析请求或者以迭代的⽅式向根域名服务器, 顶级域名服务器等依次查询最终获取解析结果。
- 客⼾端得到域名对应的IP地址后通过相应应⽤发出⽹络请求。
dns资源记录
域名和IP地址映射关系是以dns资源记录(ResourceRecord: RR)的特定格式存储在DNS服务器 中的, dns资源记录中除映射关系外还包括⼀些额外字段:
- Domain: 域名
- TTL: 本条资源记录在DNS服务器Cache上保留的时⻓
- class: ⽹络协议类型, 通常是IN, 表⽰internet
- type: 资源记录类型, dns资源记录有多种类型
- rdata: 域名关联的信息数据
资源记录的类型(type字段)主要有以下⼏种:
| 类型 | 描述 | 功能 |
| A | IPv4地址解析记录 | 域名到IPv4地址映射关系 |
| AAAA | IPv6地址解析记录 | 域名到IPv6地址映射关系 |
| CNAME | 别名解析记录 | 域名到域名别名(另⼀条域名)的映射关系 |
| NS | 域名服务器记录 | 域名到解析该域名的域名服务器映射关系 |
| MX | 邮件交换记录 | 邮件域名到相应邮件服务器映射关系 |
| TXT | ⽂本记录 | 对某个域名或主机名的说明 |
| PTR | 反向DNS记录 | IP地址到域名的映射关系 |
| SRV | 服务定位记录 | 服务到域名的映射关系, 可⽤于服务发现与负载均衡 |
| SOA | 权威记录起始 | 多个权威域名服务器的主服务器 |
| CAA | 权威认证授权记录 | DNS认证机构授权 |
| URI | 统⼀资源标识符记录 | 从域名或主机名到URI的映射 |
| LOC | 位置记录 | 域名所对应的地理位置 |
域名解析返回码
与HTTP类似, DNS服务器收到域名解析请求后会在响应中返回相应的状态码, DNS客⼾端会根据返回的状态码执⾏不同的操作。常⻅的域名解析返回码如下:
BIND
BIND(即Bekerley Internat Name Domain) 是最流⾏的开源DNS解析服务器软件, 可以通过yum install bind进⾏安装, BIND由named后台服务进程和配置⽂件构成, 其中named后台服务进程默认通过systemctl管理, 配置⽂件分为named主配置⽂件和zone解析库⽂件。BIND原⽣⽀持主从同步, 主服务器解析库(zone内数据)发⽣变化时, 会⾃动通知从服务器实现解析库同步。
配置⽂件
BIND配置⽂件分为named主配置⽂件和zone解析库⽂件。其中主配置⽂件为对BIND的整体配置信息, 包含控制通道段, 全局配置段, ⽇志配置段和区域配置段等。解析库⽂件⼀般根据不同的域分为多个zone⽂件, 每个zone⽂件中包含该域的宏定义, 缓存时间, 注释和资源记录条⽬ (Resource Record, RR)等。
named.conf 配置⽂件格式如下:
key "rndc-key" { #远程控制使⽤的认证key信息
algorithm hmac-md5;
secret "eoiWMiCwCYPwNLWxl05rNw==";
};
//控制通道段
controls { #允许对named服务进⾏远程控制
inet 127.0.0.1 port 953 #远程控制开放的地址和端⼝
allow { 127.0.0.1; } #允许远程控制的主机列表
keys { "rndc-key"; }; #远程控制使⽤的认证key
};
//全局配置段
options {
listen-on port 53 { 192.168.31.113; }; #设置通信的⽹段，这⾥建议使⽤本机
IP，并⾮127.0.0.1
listen-on-v6 port 53 { ::1; }; #监听bind端⼝
directory "/var/named"; #指定区域⽂件存放路径
dump-file "/var/named/data/cache_dump.db"; #设置当执⾏rndc dumpdb
命令后导出⽂件存放路径
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt"; #服务器输出的
内存使⽤统计⽂件名
recursing-file "/var/named/data/named.recursing";
secroots-file "/var/named/data/named.secroots";
allow-query { any; }; #允许查询来源(这⾥建议修改为IP地址，localhost代
表只允许本机查询) any代表所有⽹段
allow-transfer { none; } #允许查询的⽹段
recursion yes; #是否开启递归查询
dnssec-enable yes; #是否⽀持DNSEEC开关
dnssec-validation yes; #是否开启dnsec确认开关
bindkeys-file "/etc/named.root.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
};
//⽇志配置段
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
#本段参数解释，将⽇志写⼊⼯作⽬录下的named.run⽂件。注意：如果服务器⽤-f参数启动，
则named.run会被stderr所代替，severity 按照服务器当前Debug级别记录⽇志
#bind⽇志可以写到很多地⽅，具体写⼊⽅式可以参考
https://blog.csdn.net/zhu_tianwei/article/details/45103455
};
//区域配置段
zone "." IN { #.代表根域
type hint; #代表根服务器，除hint还有master 代表主域名服务器，slave代
表辅助域名服务器，forward 代表转发服务器
file "named.ca"; #域信息源数据库信息⽂件名
};
zone "cobb.com" IN { #域cobb.com的zone⽂件
type master; #该域名服务器是主域名服务器，这个选项主要⽤在主备部
署中
file "cobb.com.zone"; #解析域名cobb.com的zone⽂件内容，其路径由options中
的directory指定
allow-update { any; }; #定义了允许向主zone⽂件发送动态更新的匹配列表
};
include "/etc/named.rfc1912.zones"; #区域管理⽂件(包含资源记录、宏定义和注释)
#通常定义在/var/named⽬录下且以.zone结尾
include "/etc/named.root.key";
zone "1.168.192.in-addr.arpa" in { #反向解析
type master;
file "cobb.com.rev"; #存放反向解析的⽂件
allow-update { none; };
};
*.zone 解析库⽂件格式如下:
$ORIGIN . #宏定义段，代表根，否则在下⾯name段需要输⼊abcdocker.com.
$TTL 600; #根缓存时间（10分钟）
abcdocker.com IN SOA ns1.abcdocker.com. dnsadmin.abbcdocker.com. { #SOA代表
域下的资源记录全局配置，⼀个zone中有且只有⼀个
20200816; #序列号
10800; #刷新时间
900; #重试时间
604800; #过期时间
86400; #⾮权威应答ttl
}
NS ns1.abcdocker.com.
$ORIGIN abcdocker.com #代表域名，下⾯的配置都相当于配置解析ns1.abcdocker.com，
这⾥如果不写，下⾯就需要写ns1.abcdocker.com
$TTL 60; #域名过期时间，时间为60秒过期
ns1 IN A 192.168.31.113 #A记录BIND⽀持DNS动态更新机制, 如果在zone的区域配置段中配置了 allow-update 相关配置(可设置基于IP或key等ACL安全控制), 则该zone可在BIND的named服务不重启的情况下进⾏动态更新, ⽆需⼿动修改zone⽂件。
在BIND运⾏过程中, 通过 nsupdate 命令添加或删除域名资源记录(RR)时, 更新将存在于与该 zone同名的 .jnl ⽂件中, ⼀段时间后(默认15分钟)才会⾃动刷新到zone⽂件。因此对于BIND的备份, 要注意如果存在频繁的动态更新, 则jnl⽂件也需要备份, 否则恢复时可能出现资源记录丢失。
named服务的重启会导致.jnl⽂件中的记录被同步到zone⽂件中, 此外rndc⼯具的freeze和sync 命令也能够实现记录的⼿动同步。
RNDC
rndc(Remote Name Domain Controller) 是⼀个远程管理bind的⼯具, 通过这个⼯具可以在本地或者远程了解当前服务器的运⾏状况, 也可以对服务器进⾏关闭、重载、刷新缓存、增加删除 zone等操作。
使⽤rndc可以在不停⽌DNS服务器⼯作的情况进⾏数据的更新, 使修改后的配置⽂件⽣效。在实际情况下, DNS服务器是⾮常繁忙的, 任何短时间的停顿都会给⽤⼾的使⽤带来影响, 因此使⽤rndc⼯具可以使DNS服务器更好地为⽤⼾提供服务。
在使⽤rndc管理bind前需要使⽤rndc⽣成⼀对密钥⽂件, ⼀半保存于rndc的配置⽂件中, 另⼀半保存于bind主配置⽂件中。rndc与DNS服务器实⾏连接时, 需要通过数字证书进⾏认证, 而不是传统的⽤⼾名/密码⽅式。
rndc常⽤命令：
# 命令格式:
rndc -c /etc/rndc.conf -s -p CoreDNS
CoreDNS是golang编写的基于插件的DNS服务器。CoreDNS本⾝对DNS相关规范进⾏了抽象, 其提供的⼏乎⼀切功能都是通过构建于抽象层的插件实现的。CoreDNS预编译版本内置了⼤量常⽤插件, 开发者也可以⾃⾏编写插件将其编译进CoreDNS中, CoreDNS功能强⼤且灵活, 内置的kubernetes插件能够⾃动发现并解析kubernetes集群内域名, 因此成为Kubernetes平台的标准DNS解析服务。
配置⽂件
默认情况下, CoreDNS会读取当前运⾏⽬录下的 Corefile ⽂件作为配置⽂件(当然也可以通过 - conf 标记⾃定义), 配置⽂件中指定了⼀个或多个 Server Block , 每个 Server Block 中包含⼀个或多个 Plugin Block , 而这些Plugin就是提供各项DNS或⾮DNS功能的插件。在Kubernetes环境中, CoreDNS的 Corefile 通常是以 configmap 资源的形式挂载到CoreDNS容器中的。
除 Corefile 外, CoreDNS还存在⼀个⾮常重要的配置⽂件plugin.cfg , 该⽂件在CoreDNS编译时⽣效, 指定了启⽤的插件列表以及各插件的调⽤顺序。插件的调⽤顺序并不取决于各插件在 Corefile 的 Plugin Block 中的顺序, 而是取决于编译时在 plugin.cfg ⽂件中指定的顺序。