关于dns使用协议的探究

简介:

这几天有人问我dns使用协议的问题,之前只知道大概的一个情况,为了详细了解下,google并进行了测试,做下总结:

首先dns是使用tcp + udp的。

使用tcp的场景:

1.区域复制

2.解析返回结果比较大的时候(udp报文内容超过512字节时)

3.rndc 管理dns

4.udp端口不能返回解析,重新使用tcp请求解析(这个和dns的版本有关,bind9是不行的)

使用udp的场景:

用户解析访问。


为什么区域复制时使用tcp而用户访问时使用udp呢?

1.tcp是面向链接的,而且会对数据进行验证,这样区域复制的数据就不会出错,另外由于报文大小的限制也导致区域传送时使用tcp报文

2.正因为tcp是面向连接的,而且建立连接时需要3次握手,用户在使用dns解析时,如果使用tcp报文响应速度会受影响,服务器也会因为维护

大量的tcp连接而产生比较大的压力

3.udp相对来说比较安全些?不多dns的安全还是使用dnssec比较好(dnssec返回的内容会比较大,在超过限制时使用tcp报文,不超过限制时还是使用udp)


那么再思考下:区域复制是否可以使用udp?查询是否可以在不超过限制时使用tcp?

在dig中有几个参数可以方便做下相关的测试:

+[no]tcp
Use [do notuse] TCP when querying name servers. The default behavior is to useUDP unless an AXFR or IXFR
query isrequested, in which case a TCP connection is used.

+[no]ignore
Ignoretruncation in UDP responses instead of retrying with TCP. Bydefault, TCP retries are performed.

+[no]dnssec
Requests DNSSEC records be sent by setting theDNSSEC OK bit (DO) in the OPT record in the additional
section of the query.

+[no]vc
Use [do notuse] TCP when querying name servers. This alternate syntax to+[no]tcp is provided for
backwardscompatibility. The "vc" stands for "virtual circuit".

几个测试结果:

1.区域复制和普通的udp解析就不用说了。

2.dnssec默认使用udp的也比较好测试。

3.普通dns请求也可以使用tcp

dig @servera.vimage2.com  +tcp

标准的tcp解析流程:

关于dns使用协议的探究


4.区域复制是否可以使用udp?

dig@180.186.22.61 dnsserver  axfr +notcp

测试结果:抓包,发现不起作用,还是使用tcp. 不过网上搜到下面一句话,大意是区域复制返回报文内容大小在512字节以内也是可以使用udp的,应该还是和dig的版本有一定关系。。。

Lets saythat target system personnel have foolishly decided to prevent DNSZone transfers by blocking TCP port 53 instead of configuring alist of servers allowed to do zone transfers on the DNS. Everyoneknows that zone transfers occur over TCP port 53 and queries occurover UDP port 53. So blocking TCP port 53 should block zonetransfers right? Wrong.

Wellfirst of all, if the targets zone file is less than 512 bytes youcan transfer it over UDP using DIG with the +notcp option. (Note:dig on my Mac does a TCP transfer regardless of whether or not Ispecify +notcp. Dig on BT5 works fine.)


5.512限制的测试,主要测试3点,512是指整个报文大小还是去除ip头和udp头之后的大小?超过512时请求是什么样的?超过512时可以使用udp么?


1)构造一个大的返回测试

整个消息报文是533bytes(消息大小为533-20(ip报文头)-8(udp报文头)=505),仍然使用的是udp报文。

结论,只是消息大小,不包括header


rfc1035也明确说明了这一点:

Messages carried by UDP are restricted to 512 bytes (not counting the IPor UDP headers).  Longer messages are truncated and the TC bit is set in
the header.

2)超过512时的请求流程?

tcpdump抓包测试:


关于dns使用协议的探究


可以看到用户首先使用udp进行访问,返回的数据被truncate后,用户在使用标准的tcp请求流程进行请求。


根据RFC 1123的解释:

用户在发起dns请求时,默认是以udp开始的(指定+tcp时,使用tcp),在返回udptruncate的包后,再使用tcp进行请求

Specifically,a DNS resolver or server that is sending a
non-zone-transferquery MUST send a UDP queryfirst. Ifthe
Answer section of the response is truncated
andif the
requestersupports TCP, it SHOULD try the query again using
TCP.


3)超过512时可以使用udp么?

网上看到下面的一句话:

说是通过在dnsserver端进行设置,可以改变这种行为,不过我的dns版本没有测试成功,后面有环境的话再进行测试。。。


One ofthe key issues mentioned is that DNSSEC can cause DNS replies to belarger than 512 bytes. DNSSEC(Defined in RFC 4033, RFC 4034, and RFC 4035) requires the abilityto transmit larger DNS messagesbecause of the extra key information contained in the queryresponses. TCP port 53 can be used in the cases where the DNSresponses greater than 512bytes. However,using UDP messages are preferable to using TCP for large DNSmessages is due to the factthat TCP connections can consume computing resources for eachconnection. DNS servers get numerous connections per second andusing TCP can add too much overhead.Toaddress this issue, the IETF RFC2671"ExtensionMechanisms for DNS (EDNS0)" defines a method to extend the UDPbuffer size to 4096 bytes to allow for DNSSEC and larger queryresponses. To enable EDNS0 on your BIND 9 configuration you can usethe following BIND operations statement
edns-udp-size 4096 ;


6.另外看到一句话,说是在udp不能正常响应时,会使用tcp重试。

使用iptables墙掉udp 53测试。

dig @server a.vimage2.com  +time=1 +tries=2


结果:

两次重试后,没有数据返回。

20:03:39.177810 IP (tos 0x0, ttl 64, id 625, offset 0, flags[none], proto UDP (17), length 59)
server.60301>  server.domain: [bad udp cksum39f!] 39449+ A? a.vimage2.com. (31)
20:03:40.178088 IP (tos 0x0, ttl 64, id 626, offset 0, flags[none], proto UDP (17), length 59)
server.60301>  server.domain: [bad udp cksum39f!] 39449+ A? a.vimage2.com. (31)

看到别人说了一句话。这个行为应该和dns的不同版本有关:

DifferentDNS resolvers may handle it differently. It is well known thatMicrosoft DNS resolvers will query with TCP if the UDP responsedidn't come back in time. However, some other resolvers may notrequery with TCP if the UDP queries don't come back and this is perfectly within the standard aswell.


没了。。。额,说了这么多还是要告诉大家,有些细节方面的东西还是需要自己动手做测试的。




本文转自菜菜光 51CTO博客,原文链接:http://blog.51cto.com/caiguangguang/1331135,如需转载请自行联系原作者
相关文章
|
XML 监控 网络协议
云深处绝影四足机器人协议学习解析
本文详细介绍并解析了云深处绝影X20四足机器人的通信协议,包括TCP服务端端口号、基于Service的请求/响应通信机制、通信帧结构、消息类型、常见的通信示例如获取状态和导航请求,以及运动控制的参数和命令。文中还提出了对协议中某些未明确说明或可能存在的问题的疑惑。
598 1
云深处绝影四足机器人协议学习解析
|
域名解析 存储 网络协议
深入解析网络通信关键要素:IP 协议、DNS 及相关技术
本文详细介绍了IP协议报头结构及其各字段的功能,包括版本、首部长度、服务类型、总长度、标识、片偏移、标志、生存时间(TTL)、协议、首部检验和等内容。此外,还探讨了IP地址的网段划分、特殊IP地址的应用场景,以及路由选择的大致流程。最后,文章简要介绍了DNS协议的作用及其发展历史,解释了域名解析系统的工作原理。
618 5
深入解析网络通信关键要素:IP 协议、DNS 及相关技术
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
912 3
|
缓存 网络协议 安全
【网络攻防战】DNS协议的致命弱点:如何利用它们发动悄无声息的网络攻击?
【8月更文挑战第26天】DNS(域名系统)是互联网的关键组件,用于将域名转换为IP地址。然而,DNS协议存在安全漏洞,包括缺乏身份验证机制、缓存中毒风险及放大攻击的可能性。通过具体案例,如DNS缓存中毒和DNS放大攻击,攻击者能够误导用户访问恶意站点或对目标服务器实施DDoS攻击。为了防范这些威胁,可以采用DNSSEC实现数字签名验证、利用加密的DNS服务(如DoH或DoT)、限制DNS服务器响应以及及时更新DNS软件等措施。理解并应对DNS的安全挑战对于确保网络环境的安全至关重要。
674 2
|
11月前
|
网络协议
为何UDP协议不可靠?DNS为何选择UDP?
总的来说,UDP和TCP各有优势,选择哪种协议取决于应用的具体需求。UDP可能不如TCP可靠,但其简单、快速的特性使其在某些场景下成为更好的选择。而DNS就是这样的一个例子,它利用了UDP的优势,以实现快速、高效的名字解析服务。
608 14
|
存储 缓存 网络协议
DNS协议详解
通过本文,您可以全面了解DNS协议的各个方面,从而更好地理解和应用这一重要的互联网基础服务。
1994 44
|
编解码 监控 网络协议
RTSP协议规范与SmartMediaKit播放器技术解析
RTSP协议是实时流媒体传输的重要规范,大牛直播SDK的rtsp播放器基于此构建,具备跨平台支持、超低延迟(100-300ms)、多实例播放、高效资源利用、音视频同步等优势。它广泛应用于安防监控、远程教学等领域,提供实时录像、快照等功能,优化网络传输与解码效率,并通过事件回调机制保障稳定性。作为高性能解决方案,它推动了实时流媒体技术的发展。
638 5
|
网络协议 安全 网络安全
探索网络模型与协议:从OSI到HTTPs的原理解析
OSI七层网络模型和TCP/IP四层模型是理解和设计计算机网络的框架。OSI模型包括物理层、数据链路层、网络层、传输层、会话层、表示层和应用层,而TCP/IP模型则简化为链路层、网络层、传输层和 HTTPS协议基于HTTP并通过TLS/SSL加密数据,确保安全传输。其连接过程涉及TCP三次握手、SSL证书验证、对称密钥交换等步骤,以保障通信的安全性和完整性。数字信封技术使用非对称加密和数字证书确保数据的机密性和身份认证。 浏览器通过Https访问网站的过程包括输入网址、DNS解析、建立TCP连接、发送HTTPS请求、接收响应、验证证书和解析网页内容等步骤,确保用户与服务器之间的安全通信。
928 3
|
监控 网络协议 网络性能优化
网络通信的核心选择:TCP与UDP协议深度解析
在网络通信领域,TCP(传输控制协议)和UDP(用户数据报协议)是两种基础且截然不同的传输层协议。它们各自的特点和适用场景对于网络工程师和开发者来说至关重要。本文将深入探讨TCP和UDP的核心区别,并分析它们在实际应用中的选择依据。
707 3
|
网络协议 网络安全 网络虚拟化
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算
本文介绍了十个重要的网络技术术语,包括IP地址、子网掩码、域名系统(DNS)、防火墙、虚拟专用网络(VPN)、路由器、交换机、超文本传输协议(HTTP)、传输控制协议/网际协议(TCP/IP)和云计算。通过这些术语的详细解释,帮助读者更好地理解和应用网络技术,应对数字化时代的挑战和机遇。
1386 3