DNS
一、简介
域名系统(Domain Name System,DNS)是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库,能够使人更方便地访问互联网。DNS使用TCP和UDP的53端口。当前,对于每一级域名长度的限制是63个字符,域名总长度不能超过253个字符。
DNS最早于1983年由保罗·莫卡派乔斯发明;原始的技术规范在882号因特网标准草案(RFC 882)中发布。1987年发布的1034和1035号草案修正了DNS技术规范,并废除了之前的882和883草案。
二、产生的意义
域名主要面向用户,并提供一定的负载均衡能力。域名和IP的对应关系保存在一个叫hosts文件见中,但是在早期,该文件通过互联网信息中心管理这个文件,如果有一个新的计算机接入网络,或者某个计算机IP地址发生变化需要到互联网信息中心申请变更,在主机数量较少(5-10)的情况时还是能够手动维护,当主机数量时越发庞大时就会成巨大的麻烦。此时DNS就是为了解决这个问题产生的。
Windows hosts文件:C:\Windows\System32\drivers\etc\hosts
Linux hosts文件:/etc/host
三、DNS层次结构
域名空间指表示DNS这个分布式数据库的逆向树形层次结构,完整域名由从树叶节点到根节点的所有节点以分隔符“.”,按顺序连接而成,如www.zol.com.cn.(其中,“.”代表根域,虽然有时不输入;“cn”为顶级域,“com”为二级域;“zol”为三级域;“www”为主机名)
四、DNS查询步骤
(1)客户端发出请求解析域名www.zol.com.cn的报文。
(2)本地域名服务器收到请求后,查询本地缓存。假设没有该记录,则向根域名服务器发出请求解析域名www.zol.com.cn的报文。
(3)根域名服务器收到请求后,判断该域名属于.cn域。查询到NS记录及相应的A记录。
(4)本地域名服务器收到回应后缓存上述结果,然后向.cn域的域名服务器之一,如ns.cnc.ac.cn发出请求解析域名www.zol.com.cn的报文。
(5)ns.cnc.ac.cn收到请求后,判断该域名属于.com.cn域。开始查询本地的记录,找到6条NS记录及相应的A记录,然后将该结果返回给本地域名服务器。
(6)本地域名服务器收到回应后缓存上述结果,然后向.com.cn域的域名服务器之一,如sld-ns1.cnnic.net.cn.发出请求解析域名www.zol.com.cn的报文。
(7)域名服务器sld-ns1.cnnic.net.cn.收到请求后,判断该域名属于.zol.com.cn域,开始查询本地的记录。找到NS记录及对应的A记录,然后将结果返回给本地域名服务器。
(8)本地域名服务器收到回应后缓存上述结果,然后向.zol.com.cn域的域名服务器之一如ns1.zol.com.cn.发出请求解析域名www.zol.com.cn的报文。
(9)域名服务器ns1.zol.com.cn.收到请求后开始查询本地的记录,找到CNAME记录及相应的A记录,并将结果返回给本地域名服务器。
(10)本地域名服务器将得到的结果保存到本地缓存,同时将结果返回给客户端。
五、DNS分类
(1)唯高速缓存域名服务器(Cache-only Server)
唯高速缓存域名服务器不包含域名数据库,它每次从某台远程服务器取得域名服务器查询的信息,一旦取得一个回答,就将它放入高速缓存中,下次查询相同的信息就用此回答。
(2)主域名服务器(Primary Name Server)
主域名服务器是特定域所有信息的权威来源,它从域管理员构造的本地文件中加载域信息,该文件包含服务器具有管理权限的部分域结构的最精确信息。主域名服务器需要配置一组完整的文件,即主配置文件(named.conf)、正向域的区文件(named.hosts)、反向域的区文件(named.rev)、高速缓存初始化文件(named.ca)和回送文件(named.local)。
(3)辅助域名服务器(Second Name Server)
辅助域名服务器用来从主域名服务器中转移一整套域信息,它是可选的配置项。区文件从主域名服务器转移出来,作为磁盘文件保存在辅助域名服务器中。辅助域名服务器不需要配置本地区文件,只需要配置主配置文件(named.conf)、高速缓存初始化文件(named.ca)和回送文件(named.local)。
六、协议使用区别
1、UDP DNS报文构成
DNS报文格式分为DNS查询和相应的报文格式。这个报文由12字节长度的首部和4个长度可变长的字段组成。
1)Header报文
它定义了报文是请求还是应答,也定义了其他段是否需要存在,以及标准查询还是其他。
字段含义表:
字段 | 长度 | 描述 |
---|---|---|
ID | 16 bit | 标识字段,客户通过标识字段来确定DNS响应是否与查询请求匹配。 |
QR | 1 bit | 操作类型: 0:查询报文 1:响应报文 |
OPCODE | 4 bit | 查询类型: 0:标准查询 1:反向查询 2:服务器状态查询 3~15:保留未用反向查询是客户端请求服务器根据回答生成导致此回答的问题,这个查询类型的使用并不多。 |
AA | 1 bit | 若置位,则表示该域名解析服务器是授权回答该域的。 |
TC | 1 bit | 若置位,则表示报文被截断。使用UDP传输时,应答的总长度超过512字节时,只返回报文的前512个字节内容。 |
RD | 1 bit | 客户端希望域名解析服务器采取的解析方式: 0:表示希望域名解析服务器采取迭代解析 1:表示希望域名解析服务器采取递归解析 |
RA | 1 bit | 域名解析服务器采取的解析方式: 0:表示域名解析服务器采取迭代解析 1:表示域名解析服务器采取递归解析 |
Z | 3 bit | 全部置0,保留未用。 |
RCODE | 4 bit | 响应类型: 0:无差错 1:查询格式错 2:服务器失效 3:域名不存在 4:查询没有被执行 5:查询被拒绝 6-15: 保留未用 |
QDCOUNT | 16 bit | 无符号16位整数表示报文请求段中的问题记录数。 |
ANCOUNT | 16 bit | 无符号16位整数表示报文回答段中的回答记录数。 |
NSCOUNT | 16 bit | 无符号16位整数表示报文授权段中的授权记录数。 |
ARCOUNT | 16 bit | 无符号16位整数表示报文附加段中的附加记录数。 |
2)Question(查询问题)报文
字段 | 长度 | 描述 |
---|---|---|
QNAME | 变长 | 域名被编码为一些labels序列,每个labels包含一个字节表示后续字符串长度,以及这个字符串,以0长度和空字符串来表示域名结束。注意这个字段可能为奇数字节,不需要进行边界填充对齐。 |
QTYPE | 2个字节 | 表示查询类型,.取值可以为任何可用的类型值,以及通配码来表示所有的资源记录。 |
QCLASS | 2个字节 | 表示查询的协议类,比如,IN代表Internet。 |
3)资源记录字段格式
Anser、Authority、Additianal使用相同的报文格式:
字段 | 长度 | 描述 |
---|---|---|
NAME | 不定长 | 资源记录包含的域名。 |
TYPE | 2个字节 | 表示资源记录的类型,指出RDATA数据的含义。 |
CLASS | 2个字节 | 表示RDATA的类。 |
TTL | 4字节 | 无符号整数,表示资源记录可以缓存的时间。0代表只能被传输,但是不能被缓存。 |
RDLENGTH | 2个字节 | 无符号整数,表示RDATA的长度。 |
RDATA | 不定长 | 字符串,表示记录,格式跟TYPE和CLASS有关。比如,TYPE是A,CLASS是IN,那么RDATA就是一个4个字节的ARPA网络地址。 |
2、DNS报文区别
主要关注字段为TC字段,当TC字段为1时,表示应答总长度超过512字节,只返回前512个字节,这时DNS就需要使用TCP重发原来的查询请求。因为在UDP中,其应用程序传输被限制为512字节或更小,因此DNS报文数据流只能有512字节,而TCP能将用户的数据流分为一些报文段,因此TCP就能用多个报文去传输超过512字节的数据或任意长度的数据流。
3、应用区别
区域传输用TCP,其他用UDP。
DNS的规范中,规定了2类型的DNS服务器,一个叫主域名服务器,一个叫辅助域名服务器。在一个区域中主DNS服务器从自己本机的数据文件中读取该区域的DNS数据信息,而辅助DNS服务器则从区域中主DNS服务器读取该区域的DNS数据信息。当一个辅助DNS服务器启动时,它需要与主DNS服务器进行通信,并加载这个区域的DNS数据信息,这就是就区域传送。而此时为了保证辅助DNS服务器能够读取到正确的区域DNS信息,从而使用了TCP协议53端口。
注:在禁用TCP/53端口只影响主从复制;而禁用UDP/53对主从复制和DNS查询都受到影响。
七、DNS安全扩展
DNSSEC采用基于公共密钥加密的数字,从而增强了DNS验证强度。DNSSEC并非对DNS查询和相应本身进行加密签名(无法实现数据传输机密性),而是由数据所有者对DNS数据自身进行签名。
每一个DNS区域均包含一个公私密钥对。DNS区域所有者使用该区域的私钥对区域内的DNS数据进行签名,为这些数据生成数字签名。凡在该区域内查找数据的DNS,还必须检索该区域公钥,从而使用该区域公钥验证DNS数据的真实性与完整性。DNS确认检索到的DNS数据的数字签名是否有效。如果有效,证明DNS数据合法,则将DNS数据返回给用户。如果签名未通过验证,DNS会假设该数据不可信并丢弃,同时给用户返回错误。
虽然DNSSEC增强了DNS的安全性,但是它不是一种全面的解决方案,它不能抵御分布式拒绝服务(DDoS)攻击,不能确保信息交换的机密性,不能加密网站数据以及防止IP地址欺骗和网络钓鱼(即DNSSEC不能提供可用性和机密性保护)。因此它必须与其他安全机制相结合。
八、其他安全措施
1、DNS over TLS(DNS传输层安全,DoT)
用于通过传输层安全协议加密和包装DNS之间的查询和应答。该方法的目标是防止中间人攻击和修改DNS数据来提高用户隐私和安全性。但是该方法主要是的是DNS与DNS之间的安全措施。DoT使用端口853/TCP,可以被管理员发现精确发现相关数据流量。
但是这种方法会导致用户无法监视DNS请求的相关数据,从而导致DNS数据监视设备失效或被绕过。
2、DNS over HTTPS(DoH)
这个方法与DoTl类似,但是该方法是使用HTTPS协议加密DoH客户端和基于DoH的DNS之间的数据,防止中间人攻击和修改DNS数据来提高用户隐私和安全性。DoH使用端口443/TCP,因为DNS解析数据混合在HTTPS数据中导致管理员无法及时查询。
它与DoT都存在同样的问题那就是,用户无法监视DNS请求的相关数据,从而导致DNS数据监视设备失效或被绕过。
九、DNS攻击方式
1、DNS劫持(DNS hijacking)
该方法是通过恶意软件覆盖计算机TCP/IP中DNS配置将其指向攻击者控制下的恶意DNS服务器。
2、DNS缓存中毒
攻击者利用DNS服务器中漏洞从而接管DNS服务器。攻击者将恶意数据写入缓存系统,用于用户在请求时,发生错误解析从而重定向至恶意网站。
3、DNS放大攻击
是一种流程的DNS DDoS攻击形式,攻击者假冒受害者主机地址作为源地址,向公共DNS服务器发送大量DNS解析请求,公共DNS服务器将相关数据返回给受害者主机,进而使得受害者主机资源耗尽。
4、dns tunneling attack(DNS隧道攻击)
DNS隧道攻击是一种隐蔽通信的方式,通过将其他协议封装在DNS协议中进行通信。如果在本地网络中还想这种攻击,则可能意味着该主机已被控制并安装恶意程序。
1)攻击流程
-
攻击者已经通过某种方式掌握evildomain.com权威解析服务器、evildomain.com域名、受害者主机;
-
攻击者向受害者主机发送用于请求相关数据的命令,受害者主机收到该命令后将敏感数据(亦或者其他数据)封装在DNS中向外发送;
-
因为边界安全防火墙对于DNS数据流量是全部放行的,那么这个异常的DNS数据就会经由防火墙发送到evildomain.com权威解析服务器,进而被攻击者截获获得相关数据;
2)检测措施
-
检查DNS请求和应答数据包大小:如果将其他协议的数据封装在DNS数据中,必然出现DNS数据包过大。
-
DNS域名检查:正常的域名都是有一定含义并且能够让人轻松记忆的,而恶意域名的长度通常存在字母数字相互组合的情况;
-
DNS记录检查:检查内部DNS请求数量及种类,如果发现异常DNS记录;
3)预防措施
内部建设私有DNS服务器,这样可以提前过滤潜在的恶意域名,同时该内部DNS服务器使用安全技术进行防护;
监视内部网络数据流量,提前发现恶意网络行为或可以IP地址,将攻击掐死在萌芽之中;
建立DNS防火墙,以识别和组织任何黑客入侵;
九、参考链接
DNSSEC - 它是什么?为什么说它很重要? - ICANN
DNS Tunneling attack - What is it, and how to protect ourselves? - ClouDNS Blog
DNS 隧道通信特征与检测 – 绿盟科技技术博客 (nsfocus.net)
标签:协议,cn,报文,查询,域名,DNS,服务器 From: https://www.cnblogs.com/ColoFly/p/16715447.html