【网络通信】DNS、SNMP、DHCP 等 UDP 服务解析

DNS、SNMP、DHCP 等 UDP 服务解析

UDP（User Datagram Protocol）是无连接、尽力而为的传输层协议，具备如下特性：

下文围绕 DNS、SNMP、DHCP 等经典 UDP 场景，说明其为何选择 UDP、何时需要 TCP 兜底、以及工程侧的实战注意点。

功能：将人类可读的域名（如 www.example.com）解析为 IP 地址
默认端口：53/UDP（查询为主），53/TCP（兜底与区域传送）
为何使用 UDP：
- 典型查询/响应很短，无需连接建立即可完成一次查询，端到端时延更低
- 解析器（Resolver）并发量大，UDP 可减少服务端资源消耗
何时使用 TCP：
- 响应超过 UDP 负载阈值时（历史 512B，EDNS0 可提升，仍可能超出）：响应设置 TC（Truncated）=1，客户端按标准回落到 TCP 53 重新获取完整答案
- 区域传送 AXFR/IXFR 必须使用 TCP（数据量大、完整性要求高）
- 加密 DNS 场景：
  - DoT（DNS over TLS）：端口 853/TCP
  - DoH（DNS over HTTPS）：端口 443/TCP（或 HTTP/3/QUIC，见下）
  - DoQ（DNS over QUIC）：基于 QUIC/UDP 的加密传输
重要补充与安全实践：
- EDNS0 扩展：协商更大的 UDP 载荷（常见 1232/1280/4096 等），仍需关注路径 MTU
- DNSSEC：为应答引入签名与验证，防范缓存投毒
- 随机源端口 + TXID：缓解 DNS 投毒
- 放大攻击防护：QPS 限速（RRL）、BCP38 源地址反射过滤、最小化应答

小结：DNS 以 UDP 为主、TCP 为辅，结合 EDNS0 与安全机制，在性能与可靠性之间取得工程均衡。

功能：网络设备（路由器、交换机、服务器等）的状态监控与配置管理
端口：161/UDP（Agent 请求/应答）、162/UDP（Trap/Inform 告警上报）
协议版本与安全：
- v1/v2c：基于 community string，安全性较弱
- v3：支持认证与加密（USM），生产环境优先
为何使用 UDP：
- 轮询式监控为主（小报文、频次高），UDP 开销更低、更易扩展
- Trap/Inform 告警"火即发"，不依赖长连接，降低资源占用
Trap vs Inform：
- Trap：设备单向上报（不要求确认），时延更低，但可能丢失
- Inform：管理端需确认（应用层实现"可靠"），更稳妥但稍有额外负担
何时考虑 SNMP over TCP：
- 跨复杂网络、丢包高/抖动大、或需要中继穿越且对可靠性更敏感时
- 报文较大且不希望依赖 IP 分片时
- 说明：多数设备默认仍为 UDP，TCP 需要额外支持与评估
工程实践：
- 合理设置采样/轮询周期与超时重试，避免网络与设备过载
- 使用 v3，配合 ACL 与隔离管理网段，降低暴露面
- 结合 Telemetry/流式遥测（gNMI/GRPC）可补充更高频/结构化数据

功能：自动分配 IP、子网掩码、网关、DNS 等网络参数
端口（IPv4）：67/UDP（Server），68/UDP（Client）
为何使用 UDP：
- 客户端初始"无 IP"，以 0.0.0.0 为源、255.255.255.255 为目的广播发现；UDP 支持广播
- 无需连接建立，开机即插即用
典型四步（DORA）：
1. Discover（客户端广播"谁能给我租约？"）
2. Offer（服务器提出租约方案）
3. Request（客户端选择并请求确认该租约）
4. ACK（服务器确认，客户端正式启用租约）
续租与重绑定（关键计时器）：
- T1 ≈ 50% 租约期：客户端向原服务器单播 Renew（Request）
- T2 ≈ 87.5%：若无响应，广播 Rebind，请求任意 DHCP 服务器续租
- Option 51：租约时间
DHCP Relay 与 Option：
- 跨网段通过中继（Relay Agent，常运行于三层设备）转发广播为单播
- 常用选项：网关（3）、DNS（6）、域名（15）、租约（51）、中继信息（82/插桩）
DHCPv6（IPv6）要点（对照 IPv4）：
- 端口：547/UDP（Server），546/UDP（Client），使用多播 ff02::1:2
- 无 ARP，前缀/地址分配与状态/无状态（SLAAC）协同
- 安全与 RA（路由通告）配合，需要网段策略设计

NTP（Network Time Protocol）
- 端口：123/UDP
- 作用：时间同步（层级/Stratum 体系）
- 注意：NTP 放大攻击风险，建议仅对受信网段开放，NTP Auth、KOD、限制 monlist
TFTP（Trivial File Transfer Protocol）
- 端口：69/UDP（仅初始协商，数据流常转入临时端口）
- 作用：简化文件传输（固件/启动配置）
- 特点：无认证/加密、停等（Stop-and-Wait），默认块 512B，可协商更大
QUIC
- 基于 UDP 的传输层协议（集成加密与拥塞控制）
- HTTP/3 的基础，具备 0-RTT、连接迁移、头部加密等能力
- 以 UDP 为承载，但在应用层提供"类似 TCP 的可靠性"

共性总结：

工程侧进一步补充：

MTU 与 IP 分片
- 大报文易触发分片，丢片即失败；建议控制单包尺寸（如 DNS 配合 EDNS0 与路径 MTU）
- PMTUD（路径 MTU 发现）与 DF 位策略需结合网络环境校准
UDP 校验和
- IPv4 中可选（但业界实现基本都会开启），IPv6 中强制启用
NAT/防火墙与会话保持
- UDP 无连接，NAT 绑定超时较短；需要 keepalive（如 STUN/QUIC 的保活）
- 规避对称 NAT 带来的穿透问题（打洞场景需要协议配合）
放大与反射攻击防护
- 针对 DNS/NTP/SSDP 等：速率限制、响应最小化、BCP38 源地址反欺骗
指标与重试策略
- 针对查询型协议：超时、退避重试（指数退避）、错误码统计与可观测性

DNS、SNMP、DHCP 等服务选择 UDP，体现"简单即高效"的设计取舍：在应用层补齐可靠性/安全机制，保留 UDP 的性能优势与广播/多播能力。
当报文变大、需要长会话/可靠传输或安全加密时（如 DNS 区域传送、DoT/DoH/DoQ、SNMPv3 安全增强、DHCP 跨网段中继），可结合 TCP/QUIC 或配套机制兜底。
工程实践需兼顾性能、可靠性、安全与可运营性（观测/限速/告警），以取得面向生产的最优平衡。