zzzzy09

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

https://zhuanlan.zhihu.com/p/120991354

https://segmentfault.com/a/1190000023696737    DNS 大事件 及影响

根域名服务器(英语:root name server)是互联网域名解析系统(DNS)中最高级别的域名服务器,负责返回顶级域的权威域名服务器地址。它们是互联网基础设施中的重要部分,因为所有域名解析操作均离不开它们。由于DNS和某些协议(未分片的用户数据报协议(UDP)数据包在IPv4内的最大有效大小为512字节)的共同限制,根域名服务器地址的数量被限制为13个。幸运的是,采用任播技术架设镜像服务器可解决该问题,并使得实际运行的根域名服务器数量大大增加。截至2019年8月,全球共有一千多台根DNS.

 

全球互联网有13台DNS根服务器

美国VeriSign公司 2台

网络管理组织IANA(Internet Assigned Number Authority) 1台

欧洲网络管理组织RIPE-NCC(Resource IP Europeens Network Coordination Centre) 1台

美国PSINet公司 1台

美国ISI(Information Sciences Institute) 1台

美国ISC(Internet Software Consortium) 1台

美国马里兰大学(University of Maryland) 1台

美国太空总署(NASA) 1台

美国国防部 1台

美国陆军研究所 1台

挪威NORDUnet 1台

日本WIDE(Widely Integrated Distributed Environments)研究计划 1台

 

中国拥有的mirror root-server  共10 台  

J K F L 四台的镜像

 

 

访问上述 10 台DNS 使用任播的方式:

任播(英语:anycast)是一种网络定址和路由的策略,使得数据可以根据路由拓扑来决定送到“最近”或“最好”的目的地。

任播是与单播(unicast)、广播(broadcast)和多播(multicast)不同的方式。

在单播中,在网络地址和网络节点之间存在一一对应的关系。
在广播和多播中,在网络地址和网络节点之间存在一对多的关系:每一个发送地址对应一群接收可以复制信息的节点。
在任播中,在网络地址和网络节点之间存在一对多的关系:每一个地址对应一群接收节点,但在任何给定时间,只有其中之一可以接收到发送端来的信息。

 

互联网中,通常使用边界网关协议(BGP)来实现任播。

为什么只有 13 个根

https://tools.ietf.org/html/rfc791    RFC 中建议UDP 报文不大于 576 .免于分片. DNS 协议建议不大于 512字节. 而且目前DNS 并不确

internet域名系统在其层次结构的根目录下使用13个DNS服务器有两个原因。数字13被选为网络可靠性和性能之间的折衷方案,而13是基于Internet协议(IP)版本4(IPv4)的约束。 虽然IPv4中只有13个指定DNS根服务器名称,但这些名称中的每一个都不是单个计算机,而是由许多计算机组成的服务器集群。这种集群的使用提高了DNS的可靠性,而不会对其性能产生任何负面影响。 由于新兴的IPv6标准对单个数据报的大小没有这么低的限制,未来的DNS将随着时间的推移,包含更多的支持IPv6的根服务器。 DNS IP数据包 由于DNS操作可能依赖于数百万其他internet服务器在任何时候查找根服务器,因此根服务器的地址必须尽可能高效地通过IP进行分发。理想情况下,所有这些IP地址都应该放在一个包(数据报)中,以避免在服务器之间发送多个消息的开销。 在目前广泛使用的IPv4中,一个数据包中的DNS数据减去支持数据包中所包含信息的另一个协议后只有512字节。每个IPv4地址需要32字节。因此,DNS的设计者选择13作为IPv4的根服务器的数目,取416字节的数据包,并为其他支持数据保留96字节,并且如果需要的话,可以灵活地在将来添加更多DNS根服务器。

 

现在使用中的通用顶级域

现在使用中的通用顶级域
下面的通用顶级域名属目前存在的 [4] (加上.arpa,有时被认为是通用顶级域之一):

通用(generic)

.com - 供商业机构使用,但无限制
.info - 供资讯性网站使用,但无限制
.net - 原供网络服务供应商使用,现无限制
.org - 原供不属于其他通用顶级域类别的组织使用,现无限制
.xyz - 无限制
通用限制(generic-restricted)

.biz - 供商业使用
.name - 供家庭及个人使用
.pro - 供部分专业使用
赞助(sponsored)

.aero - 供航空运输业使用
.asia - 供亚太地区的公司、组织及个人使用
.cat - 供加泰罗尼亚语/文化使用
.coop - 供联合会 (cooperatives)使用
.edu - 供教育机构使用
.gov - 供美国政府及其属下机构使用
.int - 供由条约而成立的国际性机构使用
.jobs - 供求职相关网站使用
.mil - 供美国军事机构使用
.mobi - 供手提电话等装置网站使用
.museum - 供博物馆使用
.post - 供邮政服务使用
.tel - 供连接电话网络与互联网的服务使用
.travel - 供旅行社、航空公司、酒店及旅游协会等机构使用
.xxx - 供色情网站使用

 

 

 

 DNS 常用攻击方式

当前针对域名系统的攻击手段多种多样,总结起来主要包括以下三类:

一是分布式拒绝服务攻击(DDOS)。由于域名系统协议存在体系开放、无认证、无连接和无状态等特点,使其更易受到分布式拒绝服务攻击。针对域名系统的分布式拒绝服务攻击主要采用基于正常域名请求、反弹式、大流量阻塞等三种途径。

二是DNS欺骗攻击,通过技术手段向缓存域名服务器注入非法域名解析记录,当用户向被攻击的缓存域名服务器提交域名请求时,将会返回攻击者预先设定的IP地址。

三是域名劫持攻击[3],攻击者控制域名管理密码和域名管理邮箱后,将该域名的NS纪录指向到攻击者可以控制的DNS服务器,然后通过在该DNS服务器上配置相应域名纪录,使用户访问该域名时,实际指向攻击者预先设定的主机。

网域服务器缓存污染(DNS cache pollution) 

DNS劫持就是通过劫持了DNS服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析结果,导致对该域名的访问由原IP地址转入到修改后的指定IP,其结果就是对特定的网址不能访问或访问的是假网址,从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。
DNS污染是一种让一般用户由于得到虚假目标主机IP而不能与其通信的方法,是一种DNS缓存投毒攻击(DNS cache poisoning)。其工作方式是:由于通常的DNS查询没有任何认证机制,而且DNS查询通常基于的UDP是无连接不可靠的协议,因此DNS的查询非常容易被篡改,通过对UDP端口53上的DNS查询进行入侵检测,一经发现与关键词相匹配的请求则立即伪装成目标域名的解析服务器(NS,Name Server)给查询者返回虚假结果。

 

 

记录类型

代码号码定义的 RFC描述功能
 
A
1 RFC 1035 IPv4地址记录 传回一个32位的IPv4地址,最常用于映射主机名称IP地址,但也用于DNSBLRFC 1101)等。
 
AAAA
28 RFC 3596 IPv6地址记录 传回一个128位的IPv6地址,最常用于映射主机名称到IP地址。
 
AFSDB
18 RFC 1183 AFS文件系统 (Andrew File System)数据库核心的位置,于域名以外的 AFS 客户端常用来联系 AFS 核心。这个记录的子类型是被过时的的 DCE/DFS(DCE Distributed File System)所使用。
 
APL
42 RFC 3123 地址前缀列表 指定地址栏表的范围,例如:CIDR 格式为各个类型的地址(试验性)。
CAA 257 RFC 6844 权威认证授权 DNS认证机构授权,限制主机/域的可接受的CA
CDNSKEY 60 RFC 7344 子关键记录 关键记录记录的子版本,用于转移到父级
CDS 59 RFC 7344 子委托签发者 委托签发者记录的子版本,用于转移到父级
 
CERT
37 RFC 4398 证书记录 存储 PKIXSPKIPGP等。
 
CNAME
5 RFC 1035 规范名称记录 一个主机名字的别名:域名系统将会继续尝试查找新的名字。
 
DHCID
49 RFC 4701 DHCP(动态主机设置协议)标识符 用于将 FQDN 选项结合至 DHCP
 
DLV
32769 RFC 4431 DNSSEC(域名系统安全扩展)来源验证记录 为不在DNS委托者内发布DNSSEC的信任锚点,与 DS 记录使用相同的格式,RFC 5074 介绍了如何使用这些记录。
 
DNAME
39 RFC 2672 代表名称 DNAME 会为名称和其子名称产生别名,与 CNAME 不同,在其标签别名不会重复。但与 CNAME 记录相同的是,DNS将会继续尝试查找新的名字。
 
DNSKEY
48 RFC 4034 DNS 关键记录 于DNSSEC内使用的关键记录,与 KEY 使用相同格式。
 
DS
43 RFC 4034 委托签发者 此记录用于鉴定DNSSEC已授权区域的签名密钥。
 
HIP
55 RFC 5205 主机鉴定协议 将端点标识符及IP 地址定位的分开的方法。
 
IPSECKEY
45 RFC 4025 IPSEC 密钥 与 IPSEC 同时使用的密钥记录。
 
KEY
25 RFC 2535[1]RFC 2930[2] 关键记录 只用于 SIG(0)(RFC 2931)及 TKEY(RFC 2930)。[3]RFC 3455 否定其作为应用程序键及限制DNSSEC的使用。[4]RFC 3755 指定了 DNSKEY 作为DNSSEC的代替。[5]
LOC记录(LOC record) 29 RFC 1876 位置记录 将一个域名指定地理位置。
MX记录(MX record) 15 RFC 1035 电邮交互记录 引导域名到该域名的邮件传输代理(MTA, Message Transfer Agents)列表。
NAPTR记录(NAPTR record) 35 RFC 3403 命名管理指针 允许基于正则表达式的域名重写使其能够作为 URI、进一步域名查找等。
 
NS
2 RFC 1035 名称服务器记录 委托DNS区域(DNS zone)使用已提供的权威域名服务器。
 
NSEC
47 RFC 4034 下一代安全记录 DNSSEC 的一部分 — 用来验证一个未存在的服务器,使用与 NXT(已过时)记录的格式。
 
NSEC3
50 RFC 5155 NSEC 记录第三版 用作允许未经允许的区域行走以证明名称不存在性的 DNSSEC 扩展。
 
NSEC3PARAM
51 RFC 5155 NSEC3 参数 与 NSEC3 同时使用的参数记录。
OPENPGPKEY 61 RFC 7929 OpenPGP公钥记录 基于DNS的域名实体认证方法,用于使用OPENPGPKEY DNS资源记录在特定电子邮件地址的DNS中发布和定位OpenPGP公钥。
 
PTR
12 RFC 1035 指针记录 引导至一个规范名称(Canonical Name)。与 CNAME 记录不同,DNS“不会”进行进程,只会传回名称。最常用来运行反向 DNS 查找,其他用途包括引作 DNS-SD
 
RRSIG
46 RFC 4034 DNSSEC 证书 DNSSEC 安全记录集证书,与 SIG 记录使用相同的格式。
 
RP
17 RFC 1183 负责人 有关域名负责人的信息,电邮地址的 @ 通常写为 a
 
SIG
24 RFC 2535 证书 SIG(0)(RFC 2931)及 TKEY(RFC 2930)使用的证书。[5]RFC 3755 designated RRSIG as the replacement for SIG for use within DNSSEC.[5]
 
SOA
6 RFC 1035 权威记录的起始 指定有关DNS区域的权威性信息,包含主要名称服务器、域名管理员的电邮地址、域名的流水式编号、和几个有关刷新区域的定时器。
SPF 99 RFC 4408 SPF 记录 作为 SPF 协议的一部分,优先作为先前在 TXT 存储 SPF 数据的临时做法,使用与先前在 TXT 存储的格式。
SRV记录(SRV record) 33 RFC 2782 服务定位器 广义为服务定位记录,被新式协议使用而避免产生特定协议的记录,例如:MX 记录。
 
SSHFP
44 RFC 4255 SSH 公共密钥指纹 DNS 系统用来发布 SSH 公共密钥指纹的资源记录,以用作辅助验证服务器的真实性。
 
TA
32768 DNSSEC 信任当局 DNSSEC 一部分无签订 DNS 根目录的部署提案,,使用与 DS 记录相同的格式[6][7]
 
TKEY记录(TKEY record)
249 RFC 2930 秘密密钥记录 TSIG提供密钥材料的其中一类方法,that is 在公共密钥下加密的 accompanying KEY RR。[8]
 
TSIG
250 RFC 2845 交易证书 用以认证动态更新(Dynamic DNS)是来自合法的客户端,或与 DNSSEC 一样是验证回应是否来自合法的递归名称服务器。[9]
 
TXT
16 RFC 1035 文本记录 最初是为任意可读的文本 DNS 记录。自1990年起,些记录更经常地带有机读数据,以 RFC 1464 指定:机会性加密(opportunistic encryption)、Sender Policy Framework(虽然这个临时使用的 TXT 记录在 SPF 记录推出后不被推荐)、DomainKeys、DNS-SD等。
URI 256 RFC 7553 统一资源标识符 可用于发布从主机名到URI的映射。

其他类型及伪资源记录

其他类型的资源记录简单地提供一些类型的消息(如:HINFO 记录提供电脑或操作系统的类型),或传回实验中之功能的数据。“type”字段也使用于其他协议作各种操作。

代码号码定义的 RFC描述功能
* 255 RFC 1035 所有缓存的记录 传回所有服务器已知类型的记录。如果服务器未有任何关于名称的记录,该请求将被转发。而传回的记录未必完全完成,例如:当一个名称有 A 及 MX 类型的记录时,但服务器已缓存了 A 记录,就只有 A 记录会被传回。
AXFR 252 RFC 1035 全局转移 由主域名服务器转移整个区域文件至二级域名服务器。
 
IXFR
251 RFC 1995 增量区域转移 请求只有与先前流水式编号不同的特定区域的区域转移。此请求有机会被拒绝,如果权威服务器由于配置或缺乏必要的数据而无法履行请求,一个完整的(AXFR)会被发送以作回应。
 
OPT
41 RFC 2671 选项 这是一个“伪 DNS记录类型”以支持 EDNS

 

DNS 区域

DNS file typeDescription
Primary (Master) Zone files for a primary zone contain, at minimum, the start of authority (SOA) and nameserver (NS) resource records for the zone. Primary zones are authoritative, that is, they respond to DNS queries for the domain or sub-domain. A zone can have only one SOA record, and must have at least one NS record.
Secondary  (Salve) Zone files for a secondary zone are copies of the principal zone files. At an interval specified in the SOA record, secondary zones query the primary zone to check for and obtain updated zone data. A secondary zone responds authoritatively for the zone provided that the zone data is valid.
Stub Stub zones are similar to secondary zones, except that stub zones contain only the NS records for the zone. Note that stub zones are a specific feature of the BIND implementation of DNS. F5 Networks recommends that you use stub zones only if you have a specific requirement for this functionality.
Forward The zone file for a forwarding zone contains only information to forward DNS queries to another nameserver on a per-zone (or per-domain) basis.
Hint The zone file for a hint zone specifies an initial set of root nameservers for the zone. Whenever the local nameserver starts, it queries a root nameserver in the hint zone file to obtain the most recent list of root nameservers. Zone file import.

DNSSEC相关术语

DNSKEY/RRSIG/DS/NSEC资源记录
为了实现资源记录的签名和验证,DNSSEC增加了四种类型的资源记录:

RRSIG(Resource Record Signature)记录:存储资源记录集合(RRSets)的数字签名

DNSKEY(DNS Public Key)记录:存储公开密钥

DS(Delegation Signer)记录:存储DNSKEY的散列值,用于验证DNSKEY的真实性,从而建立一个信任链

NSEC(Next Secure)记录:用于应答那些不存在的资源记录

就是需要证书进行签名

DNS 运作方式的简要描述
了解域名系统安全扩展 (DNSSEC),这有助于对域名系统 (DNS) 有基本的认识。

互联网的正常运转离不开 DNS。访问的每一个网页、发送的每一封电子邮件,以及从社交媒体中检索到的每一张图片:所有这些交互都要通过 DNS 将易于使用的域名(如 icann.org)转换为 IP 地址(如 192.0.43.72001:500:88:200::7),服务器、路由器和其他网络设备需要根据 IP 地址将流量路由到互联网上的适当目的地。

无论在任何设备上使用互联网,都需要首先提供 DNS。例如,设想一下,如果用户在手机浏览器中输入网站名称,浏览器使用存根解析器(作为设备操作系统的一部分)开始将网站域名转换为互联网协议 (IP) 地址。存根解析器是一种极为简单的 DNS 客户端,它会将应用的 DNS 数据请求传递到更复杂的 DNS 客户端,也就是所谓的递归解析器。很多网络运营商运行递归解析器,以便处理设备通过其网络发送的 DNS 请求或查询。(有时,小型运营商和组织会对其他网络使用递归解析器,包括作为公众服务运行的递归解析器,如 Google Public DNS、OpenDNS 和 Quad9。)

递归解析器可跟踪或解析针对存根解析器发送的 DNS 请求做出的应答。该解析流程通常要求递归解析器将其 DNS 查询发送至多个不同的权威域名服务器。每个域名的 DNS 数据均存储于互联网某处的权威域名服务器中。域 DNS 数据称为区域。有些组织自行运行域名服务器发布区域,但很多组织通常将此职能外包给第三方。一些不同类型的组织代表他方(包括注册服务机构、注册管理机构、网络托管公司、网络服务器提供商等)托管 DNS 区。

DNS 本身并非安全无虞
DNS 设计于上世纪 80 年代,当时互联网规模小得多,安全性并非首要设计考虑因素。因此,当递归解析器向权威域名服务器发送查询时,解析器无法验证响应真实性。解析器仅可检查做出响应的 IP 地址与解析器发送初始查询的 IP 地址是否相同。但是,依赖响应对应的源 IP 地址并非强验证机制,因为 DNS 响应数据包的源 IP 地址很容易仿冒或伪造。鉴于最初设计 DNS 时,解析器无法轻易识别某一项查询的仿冒响应。攻击者很容易冒充看似来自权威服务器的响应,继而伪装成解析器最初查询的权威服务器。换言之,攻击者可以悄无声息地将用户重定向至潜在恶意网站。

递归解析器可缓存从权威域名服务器接收到的 DNS 数据以加速解析流程。如果存根解析器请求提供递归解析器缓存的 DNS 数据,递归解析器可以立即做出应答,避免首次查询一个或多个权威服务器引发的延迟。然而,依靠缓存存在一个缺点:如果攻击者发送的仿冒 DNS 响应获得递归解析器的接受,则意味着递归解析器缓存投毒成功。而后,解析器将源源不断地向其他查询设备返回欺诈性 DNS 数据。

以缓存投毒攻击威胁为例,设想一下,如果用户访问银行网站,会怎么样?用户设备在其配置的递归域名服务器中查询银行网站的 IP 地址。不过,攻击者可以通过 IP 地址向解析器投毒,届时 IP 地址并非指向目标合法网站,而是指向攻击者创建的某个网站。这个欺诈网站冒充银行网站,看上去毫无差别。一如既往,用户毫无防备地输入名称和密码。很遗憾,用户在不经意间向攻击者透露了自己的银行凭证,攻击者可以堂而皇之地以用户的身份登录合法银行网站进行转账或执行其他未经授权的操作。

DNS 安全扩展 (DNSSEC)
互联网工程任务组 (IETF) 是一家负责制定 DNS 协议标准的组织,IETF 工程师们早已意识到缺乏更强的验证机制是 DNS 面临的一大问题。自上世纪 90 年代起,人们开始寻求解决方案,最终 DNS 安全扩展 (DNSSEC) 应运而生。

DNSSEC 采用基于公共密钥加密的数字签名,从而增强 DNS 验证强度。DNSSEC 并非对 DNS 查询和响应本身进行加密签名,而是由数据所有者对 DNS 数据自身进行签名。

每一个 DNS 区均包含一个公私秘钥对。DNS 区所有者使用该区域的私钥对区域内的 DNS 数据进行签名,为这些数据生成数字签名。顾名思义,"私钥"是指 DNS 区所有者会对这些密钥材料保密。但是,该区域的公钥则在区域内公开发布,供全体用户检索。凡在区域内查找数据的递归解析器,还必需检索区域公钥,从而使用公钥验证 DNS 数据的真实性。解析器确认检索到的 DNS 数据的数字签名是否有效。如果有效,证明 DNS 数据合法,则将 DNS 数据返回给用户。如果签名未通过验证,解析器会假设发生攻击,丢弃数据并向用户返回错误。

DNSSEC 在 DNS 协议中新增了两项重要功能:

数据来源验证 - 解析器可以通过加密的方式验证收到的数据是否确实来自其认定的数据传送区域。
数据完整性保护 - 解析器可以确信,自区域所有者使用区域私钥初次进行数据签名以来,数据在传输过程中并未遭到修改。
信任 DNSSEC 密钥
每个区域都会发布公钥,递归解析器可检索公钥以验证区域中的数据。那么,解析器如何确保区域公钥本身真实可靠呢?与区域中的其他数据一样,区域公钥也经过签名。但是,公钥并非由区域私钥签名,而是由父区域私钥签名。例如,icann.org zone 的公钥由 org 区域进行签名。DNS 区域的父区域负责发布子区域的权威域名服务器列表;同样,区域的父区域还需负责核实其子区域公钥的真实性。每一个区域的公钥均由其父区域签名,但根区除外:没有可供进行密钥签名的父区域。

因此,根区公钥是验证 DNS 数据的重要出发点。如果解析器信任根区公钥,则可信任经根区私钥签名的顶级区域公钥,如 org 区域公钥。由于解析器可以信任 org 区域公钥,因而可以信任经其各自私钥签名的公钥,如 icann.org 公钥。(在实际工作中,父区域不会直接对子区域密钥进行签名 - 实际机制更加复杂 - 但效果与父区域对子区域密钥进行签名一致)。

对其他加密密钥进行签名的加密密钥序列称为信任链。信任链最前端的公钥称为信任锚。解析器具有信任锚列表,其中列出了解析器隐含信任的不同区域的公钥。大部分解析器仅配置一个信任锚:根区公钥。通过信任 DNS 层次结构顶端的这个密钥,只要对路径中的每一个区域均进行签名,则解析器可以为 DNS 域名空间的任意位置构建信任链。

使用 DNSSEC 验证和签名
为确保互联网的普遍安全性,需广泛部署 DNSSEC。DNSSEC 并非自动启用:目前不仅需要网络运营商在递归解析器中专门启用,还要域名所有者在区域权威服务器中启用。解析器和权威服务器运营商为系统启用 DNSSEC 的激励措施有所不同;然而一旦决定启用 DNSSEC,将可保证越来越多的用户就其 DNS 查询获得经过验证的应答。简言之,用户可保证最终抵达理想的在线目的地。

在递归解析器中启用 DNSSEC 验证很简单。事实上,早在多年前,几乎所有常用解析器均支持 DNSSEC 验证。为启用 DNSSEC 验证验证,只需在解析器的配置文件中更改几行内容。随后,如果用户向解析器请求来自签名区域的 DNS 信息,但上述数据遭到篡改,用户将可(有意选择)拒绝获取数据。DNSSEC 可检测攻击及防止用户获取被篡改的数据,从而阻止用户从签名区域中获取恶意数据。

使用 DNSSEC 进行区域签名分几个步骤,但鉴于有数百万个区域执行 DNS 信息签名,因而可以保证验证解析器的用户获取安全数据。几乎所有常用权威域名服务器软件均支持区域签名,很多第三方 DNS 托管提供商还支持 DNSSEC。通常,为托管提供商区域启用 DNSSEC 的过程非常简单:往往只需单击复选框而已。

如果区域所有者要部署 DNSSEC,不仅需要对区域数据进行签名,还要对区域的父区域、父区域的父区域一直到根区进行签名,从而尽可能加强 DNSSEC 的有效性。自根区开始建立持续的签名区域链,解析器将可从根区起构建信任链以验证数据。例如,为在 icann.org 区域中有效部署 DNSSEC,需对 org 区域及根区进行签名。令人欣慰的是,自 2010 年起,人们已对 DNS 根区进行了签名,所有通用顶级域及很多 ccTLD 也已经过签名。

为在区域中部署 DNSSEC,还要完成另外一个步骤:需将新签名的区域公钥材料发送至该区域的父区域。如前所述,父区域对子区域的公钥进行签名,形成一条自父区域延伸至子区域的信任链。

而今,区域所有者通常需要将区域公钥材料手动发送给父区域。在大多数情况下,通过区域所有者的注册服务机构完成这一通信过程。区域所有者通过其注册服务机构对区域做出其他更改,如区域权威域名服务器列表;同样,区域所有者也可联系注册服务机构,以更新该区域的公钥材料。虽然现阶段此流程仍采用手动形式,但最近开发的协议有望在未来实现流程自动化。

DNSSEC 的后续工作
随着 DNSSEC 部署规模的扩大,人们很可能以 DNS 为基础开发其他协议并要求设法安全存储数据。新协议依托 DNSSEC 开发,因而仅可在签名区域中使用。例如,基于 DNS 的名称实体验证 (DANE) 允许在区域中面向邮件传输等应用发布安全传输层协议 (TLS) 密钥。DANE 开创了一种验证公钥真实性的方法,不再依赖认证机构。未来在开发向 DNS 查询添加隐私的新方法时也可以使用 DANE。

2018 年,ICANN 首次更改 DNS 根信任锚。在此过程中,积累了大量有关 DNSSEC 的经验教训。此外,很多解析器运营商开始加大对 DNSSEC 的关注度并启用验证,全世界对于 DNSSEC 系统整体运作方式的认识越来越清晰。在未来的几年里,ICANN 希望解析器运营商和区域所有者越来越多地采用 DNSSEC。这意味着,全球各地的更多用户可以通过 DNSSEC 的有力加密保证受益,在查询时获得真实可靠的 DNS 应答。

 

 dns server 中默认包含的hint文件

zone "." IN {
    type hint;
    file "named.ca";
};

[root@localhost etc]# cat /var/named/named.ca 

; <<>> DiG 9.11.3-RedHat-9.11.3-3.fc27 <<>> +bufsize=1200 +norec @a.root-servers.net
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46900
;; flags: qr aa; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;.                IN    NS

;; ANSWER SECTION:
.            518400    IN    NS    a.root-servers.net.
.            518400    IN    NS    b.root-servers.net.
.            518400    IN    NS    c.root-servers.net.
.            518400    IN    NS    d.root-servers.net.
.            518400    IN    NS    e.root-servers.net.
.            518400    IN    NS    f.root-servers.net.
.            518400    IN    NS    g.root-servers.net.
.            518400    IN    NS    h.root-servers.net.
.            518400    IN    NS    i.root-servers.net.
.            518400    IN    NS    j.root-servers.net.
.            518400    IN    NS    k.root-servers.net.
.            518400    IN    NS    l.root-servers.net.
.            518400    IN    NS    m.root-servers.net.

;; ADDITIONAL SECTION:
a.root-servers.net.    518400    IN    A    198.41.0.4
b.root-servers.net.    518400    IN    A    199.9.14.201
c.root-servers.net.    518400    IN    A    192.33.4.12
d.root-servers.net.    518400    IN    A    199.7.91.13
e.root-servers.net.    518400    IN    A    192.203.230.10
f.root-servers.net.    518400    IN    A    192.5.5.241
g.root-servers.net.    518400    IN    A    192.112.36.4
h.root-servers.net.    518400    IN    A    198.97.190.53
i.root-servers.net.    518400    IN    A    192.36.148.17
j.root-servers.net.    518400    IN    A    192.58.128.30
k.root-servers.net.    518400    IN    A    193.0.14.129
l.root-servers.net.    518400    IN    A    199.7.83.42
m.root-servers.net.    518400    IN    A    202.12.27.33
a.root-servers.net.    518400    IN    AAAA    2001:503:ba3e::2:30
b.root-servers.net.    518400    IN    AAAA    2001:500:200::b
c.root-servers.net.    518400    IN    AAAA    2001:500:2::c
d.root-servers.net.    518400    IN    AAAA    2001:500:2d::d
e.root-servers.net.    518400    IN    AAAA    2001:500:a8::e
f.root-servers.net.    518400    IN    AAAA    2001:500:2f::f
g.root-servers.net.    518400    IN    AAAA    2001:500:12::d0d
h.root-servers.net.    518400    IN    AAAA    2001:500:1::53
i.root-servers.net.    518400    IN    AAAA    2001:7fe::53
j.root-servers.net.    518400    IN    AAAA    2001:503:c27::2:30
k.root-servers.net.    518400    IN    AAAA    2001:7fd::1
l.root-servers.net.    518400    IN    AAAA    2001:500:9f::42
m.root-servers.net.    518400    IN    AAAA    2001:dc3::35

;; Query time: 24 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Thu Apr 05 15:57:34 CEST 2018
;; MSG SIZE  rcvd: 811

[root@localhost etc]# 

 

 

 查看一次完整的DNS 请求过程www.taobao.com.cn

[root@localhost ~]# dig www.taobao.com.cn A  +trace

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> www.taobao.com.cn A +trace
;; global options: +cmd
.            45816    IN    NS    m.root-servers.net.        //13 个 Hint  节点
.            45816    IN    NS    h.root-servers.net.
.            45816    IN    NS    e.root-servers.net.
.            45816    IN    NS    g.root-servers.net.
.            45816    IN    NS    l.root-servers.net.
.            45816    IN    NS    b.root-servers.net.
.            45816    IN    NS    c.root-servers.net.
.            45816    IN    NS    i.root-servers.net.
.            45816    IN    NS    a.root-servers.net.
.            45816    IN    NS    f.root-servers.net.
.            45816    IN    NS    j.root-servers.net.
.            45816    IN    NS    k.root-servers.net.
.            45816    IN    NS    d.root-servers.net.
;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 160 ms

cn.            172800    IN    NS    e.dns.cn.              //中国 CNNIC权威云解析(DNS.CN)全球Anycast节点
cn.            172800    IN    NS    a.dns.cn.
cn.            172800    IN    NS    ns.cernet.net.
cn.            172800    IN    NS    c.dns.cn.
cn.            172800    IN    NS    g.dns.cn.
cn.            172800    IN    NS    f.dns.cn.
cn.            172800    IN    NS    d.dns.cn.
cn.            172800    IN    NS    b.dns.cn.
cn.            86400    IN    DS    57724 8 2 5D0423633EB24A499BE78AA22D1C0C9BA36218FF49FD95A4CDF1A4AD 97C67044
cn.            86400    IN    RRSIG    DS 8 1 86400 20200104050000 20191222040000 22545 . IOCmLDtMptDRBjZKpSFfSUd9A7Zz5fLJS6fW7JwGNq+1hc5MgsCVL7Bo UvcxIYsGsQz4lMj8MWl6kfr2cD7xN2yrQva0EOqKhidLQrzFSMmM0+jZ 4hzh1AVYfYE1vzkhKYY+xbW+U/3h+SfnSnSQ0iWb29wWDcoC5rH0WGpR zZJc6iZtRSsgka15Ft5aok6o56juEkOznU0O6z3Uu6zEtvifeDMD6z8u iJkwuv7Tv6cQ47/snmqe0G/nhD7KNkKX3RJy0HSG9YFJA7W93cf2ErFq gooN9HPLTZJZvG3j3pBR6A/KRdWWfqoRnjGT1+3UgUNHoLOMH53lRluj B69m+Q==
;; Received 708 bytes from 192.5.5.241#53(f.root-servers.net) in 47 ms

taobao.com.cn.        86400    IN    NS    ns1.markmonitor.com.          //美国DNS
taobao.com.cn.        86400    IN    NS    ns3.markmonitor.com.
GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn. 21600 IN NSEC3    1 1 10 AEF123AB H497TUER80LUF57FB9UOJIRF5LLLCPLS NS SOA RRSIG DNSKEY NSEC3PARAM
GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn. 21600 IN RRSIG    NSEC3 8 3 21600 20200101101502 20191202094911 43326 com.cn. tECmtMJt2PISF1b2wdupm6WHxFoHYaPOHzVgXE9HL31gYcUeJtgnQRPW uHmo6Xyv+enVNzXiPZwJPNpCh+ckUA/y5B/oBTtq/aIlDgbMpBh7Nv3K iz4VydJWhB+pXjBXIphz9DLlOd/QFEllwfDhR/Y8+rp5AuWlPdUApRAc cMo=
2OSNN2BODO7I0KP1IJBONOBJR075QNS6.com.cn. 21600 IN NSEC3    1 1 10 AEF123AB 3LT803ACD3A3A0PG9PH1F1GU97LD2I2C NS DS RRSIG
2OSNN2BODO7I0KP1IJBONOBJR075QNS6.com.cn. 21600 IN RRSIG    NSEC3 8 3 21600 20200101110655 20191202100742 43326 com.cn. j2kd4GdfG2efbkRnmc8D8boHbiG5kVu3e3LUGSp1NM/xZJ2/JM2a3Ua2 pur92qdbQcO13+SoqueIHWxQ3/pi04MBULEKEBaYnUES5X17ur6UpK+g beZ7+VRMEqaaQiB3lMJz1nywsir8Ml0+4BSDDQdoREipULsnnL9iORPn zQs=
;; Received 596 bytes from 103.137.60.44#53(ns.cernet.net) in 126 ms

www.taobao.com.cn.    86400    IN    A    93.191.168.52   //一个欧洲的地址 ,显示这个域名已经被买了,但是没有发布相应的记录。访问地址显示已经被保护了
taobao.com.cn.        86400    IN    NS    ns3.markmonitor.com.
taobao.com.cn.        86400    IN    NS    ns1.markmonitor.com.
;; Received 113 bytes from 64.124.69.50#53(ns1.markmonitor.com) in 370 ms

[root@localhost ~]# 

 

  查看一次完整的DNS 请求过程www.sina.com.cn

[root@localhost ~]# dig www.sina.com.cn +trace

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> www.sina.com.cn +trace
;; global options: +cmd
.            44847    IN    NS    j.root-servers.net.
.            44847    IN    NS    e.root-servers.net.
.            44847    IN    NS    d.root-servers.net.
.            44847    IN    NS    b.root-servers.net.
.            44847    IN    NS    i.root-servers.net.
.            44847    IN    NS    c.root-servers.net.
.            44847    IN    NS    f.root-servers.net.
.            44847    IN    NS    h.root-servers.net.
.            44847    IN    NS    g.root-servers.net.
.            44847    IN    NS    l.root-servers.net.
.            44847    IN    NS    k.root-servers.net.
.            44847    IN    NS    a.root-servers.net.
.            44847    IN    NS    m.root-servers.net.
;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 92 ms

cn.            172800    IN    NS    a.dns.cn.
cn.            172800    IN    NS    b.dns.cn.
cn.            172800    IN    NS    c.dns.cn.
cn.            172800    IN    NS    d.dns.cn.
cn.            172800    IN    NS    e.dns.cn.
cn.            172800    IN    NS    f.dns.cn.
cn.            172800    IN    NS    g.dns.cn.
cn.            172800    IN    NS    ns.cernet.net.
cn.            86400    IN    DS    57724 8 2 5D0423633EB24A499BE78AA22D1C0C9BA36218FF49FD95A4CDF1A4AD 97C67044
cn.            86400    IN    RRSIG    DS 8 1 86400 20200104050000 20191222040000 22545 . IOCmLDtMptDRBjZKpSFfSUd9A7Zz5fLJS6fW7JwGNq+1hc5MgsCVL7Bo UvcxIYsGsQz4lMj8MWl6kfr2cD7xN2yrQva0EOqKhidLQrzFSMmM0+jZ 4hzh1AVYfYE1vzkhKYY+xbW+U/3h+SfnSnSQ0iWb29wWDcoC5rH0WGpR zZJc6iZtRSsgka15Ft5aok6o56juEkOznU0O6z3Uu6zEtvifeDMD6z8u iJkwuv7Tv6cQ47/snmqe0G/nhD7KNkKX3RJy0HSG9YFJA7W93cf2ErFq gooN9HPLTZJZvG3j3pBR6A/KRdWWfqoRnjGT1+3UgUNHoLOMH53lRluj B69m+Q==
;; Received 706 bytes from 198.97.190.53#53(h.root-servers.net) in 96 ms

sina.com.cn.        86400    IN    NS    ns3.sina.com.cn.   //北京联通
sina.com.cn.        86400    IN    NS    ns1.sina.com.cn.
sina.com.cn.        86400    IN    NS    ns4.sina.com.cn.
sina.com.cn.        86400    IN    NS    ns2.sina.com.cn.
GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn. 21600 IN NSEC3    1 1 10 AEF123AB H497TUER80LUF57FB9UOJIRF5LLLCPLS NS SOA RRSIG DNSKEY NSEC3PARAM
GICE14DNTMDN31G43AUGVRKTKALVB8QC.com.cn. 21600 IN RRSIG    NSEC3 8 3 21600 20200101101502 20191202094911 43326 com.cn. tECmtMJt2PISF1b2wdupm6WHxFoHYaPOHzVgXE9HL31gYcUeJtgnQRPW uHmo6Xyv+enVNzXiPZwJPNpCh+ckUA/y5B/oBTtq/aIlDgbMpBh7Nv3K iz4VydJWhB+pXjBXIphz9DLlOd/QFEllwfDhR/Y8+rp5AuWlPdUApRAc cMo=
TDU124P7EGELLSS91RPV7H8S4DKOE2EH.com.cn. 21600 IN NSEC3    1 1 10 AEF123AB UQROTQK62NOIM5U43DMF7AMC8JJFRM7T NS DS RRSIG
TDU124P7EGELLSS91RPV7H8S4DKOE2EH.com.cn. 21600 IN RRSIG    NSEC3 8 3 21600 20200115105713 20191216095713 43326 com.cn. SOr3A6DHb1dI0WqSpNVPY92qSU1dLb1HamZOC7vHKnmyJo7EyATC/k5N W+yQCbJvo3n8Eyyt3gRRPz15wjh9Goa2MTTzWG31jWXyOujlDtNHQCoY rNr1nEGtIn7djwZ/6N6IRqpsGA0aY9GQXP2MKCCh8AJ6bk39AOFu/GfU Z70=
;; Received 679 bytes from 195.219.8.90#53(f.dns.cn) in 342 ms

www.sina.com.cn.    60    IN    CNAME    spool.grid.sinaedge.com.   //北京朝阳鹏博士机房
;; Received 81 bytes from 36.51.252.8#53(ns1.sina.com.cn) in 9 ms

[root@localhost ~]# 

 

数据包分析

数据包分析 www.baidu.com 请求过程,在测试中使用bind 作为测试的 local DNS server 。不要指定其他类似114.114.114.114 /8.8.8.8 的local DNS,否则所有的测试都是访问指定DNS.使用bind 不设置转发默认使用 hint 文件,能够

看到完整的数据流和请求过程 ,工具使用dig . yum install bind-utils

[root@localhost etc]# dig www.baidu.com  +trace

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> www.baidu.com +trace
;; global options: +cmd
.            515113    IN    NS    d.root-servers.net.        //从hint 查 com. zone 权威DNS
.            515113    IN    NS    j.root-servers.net.
.            515113    IN    NS    h.root-servers.net.
.            515113    IN    NS    i.root-servers.net.
.            515113    IN    NS    f.root-servers.net.
.            515113    IN    NS    c.root-servers.net.
.            515113    IN    NS    b.root-servers.net.
.            515113    IN    NS    e.root-servers.net.
.            515113    IN    NS    a.root-servers.net.
.            515113    IN    NS    k.root-servers.net.
.            515113    IN    NS    l.root-servers.net.
.            515113    IN    NS    g.root-servers.net.
.            515113    IN    NS    m.root-servers.net.
.            515113    IN    RRSIG    NS 8 0 518400 20200104050000 20191222040000 22545 . sW9hkKZX0KjzHImAHYT2/oW7QaTX/txOGaXoUHt/c2Cw+v654rB0HUlT spLvpED9fNl1I7c8xYKMVWWee54cQ4xzjVL2fZW+n+hRdhMXczX3Wncp eD7SOEhdxeNIy8A87R1yqvNjflUR+1jCbr9DOA0EVMg1N1FtZfKbH/08 BFIA355xt0ymWadJdDWpcndxPKG40IQS04IwOqQPySwiqoEIX9gWhzZM 8BcR6rLH/S0Ek3fBriOl9W0f2IGDIAZG2aBzVg0A0y8HmQrQUQXha/IR GWCdYJ3DWUQBO8T+PEsnxttmc3eo/9QiZdMyqfBruuN725c/yaPli1nt XxpVdQ==
;; Received 1097 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

com.            172800    IN    NS    a.gtld-servers.net.     
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20200104050000 20191222040000 22545 . a/xpMxtAAIKr/yUYmw90y918tkIrP44hMluM9wM9V40fzkvWgtRUtzwt ed3+2EDMfkZAfv3FQaJzxwqu3vjCzNPjlKNBzULrVADNfm913eVpImfb QqFUH4kfEMWDhIOchXsh7oTU89LdW8X4o+UbjcX2t3MLAYys+I9IwLDY BZGjJJiZ9BV8NIwClXQnJlFW/JtqFtkct8r641WOUpP7bqMRGzDJCwkX s4E/o7MGc6XSpAUCWREYVwbHNODUrS0UNzq8gkMOfGvVHN+yWfNXWxKH 1J9mM0SA8jinmuJfcBDhozRluXk1b0jy+mzlTssHtWcvGUVsmLJ+SwGj bagHPQ==
;; Received 1173 bytes from 199.7.83.42#53(l.root-servers.net) in 121 ms

baidu.com.        172800    IN    NS    ns2.baidu.com.
baidu.com.        172800    IN    NS    ns3.baidu.com.
baidu.com.        172800    IN    NS    ns4.baidu.com.
baidu.com.        172800    IN    NS    ns1.baidu.com.
baidu.com.        172800    IN    NS    ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191229054910 20191222043910 12163 com. OsRms3xeOt8QZaxpa5pVtCMtp/2MlbcISeFQL3+bDoVj9r4jfkEYOgIK +98iDR8F1bKC4x61ItMfkMVFSB4Vj8feYfHZUZUpfGwCHnQlhYTEokOT COOcGXXbT+mxnb2H3/ySul4YEH4aWxbVWVA/U4kDHtzSEIWdDdQNXESS 9smEen+J2IAqLQTZiYm89liv+q/flrh8LhuE3kMkvpGs4w==
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HPVVN3Q5E5GOQP2QFE2LEM4SVB9C0SJ6 NS DS RRSIG
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20191227055147 20191220044147 12163 com. I3mJNq+Rs6pT7Z5ZGfFLzcYkuyZ8Vo8OXAq53RR48tBfVaY92GN65fqy 0Lo8Rk7h5AztF+5C40Mu9wZR54bP7NA+CWNd/QqfTU+rrStlpUV4B4U3 qwZxmT8Komr6z/G7KqM99tm+L/cWhdn8/nRMc6c3mubqHkYzxlQQkEKb 7rxTTvpLppLbLQQvQVaLAXAn/2dQ+skUabd5KMeUjUckxw==
;; Received 761 bytes from 192.33.14.30#53(b.gtld-servers.net) in 190 ms

www.baidu.com.        1200    IN    CNAME    www.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns4.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns3.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns1.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns5.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns2.a.shifen.com.
;; Received 239 bytes from 202.108.22.220#53(ns1.baidu.com) in 99 ms

[root@localhost etc]# 

 

迭代第一次:开始从 e.root-servers.net. 518400 IN A 192.203.230.10  请求www.baidu.com 域名 ,返回com 对应的 ns,以及ns 对应的A 记录

 

 

 迭代第二次:向h.gtld-servers.net    请求 h.gtld-servers.net 的A 记录,这里应该是选择一个NS ,请求具体的域名信息,应该是镜像server 。

 

 

 返回的结果是这个dns 被委派走了

 

 

 迭代第三次: 到 e.gtld-servers.net: type A, class IN, addr 192.12.94.30   DNS  请求 av1 - av4 的信息

 

 响应了对应的信息

 

 这里返回了百度对应的NS,udp 报文无序不太好查数据流

 

 

 

最后这里返回了A 记录

 

 域名架构如下:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

posted on 2019-12-22 17:59  zzzzy09  阅读(3705)  评论(0编辑  收藏  举报