仅发送DHCP Discover不提交Request获取DNS服务器是否安全？无租赁生效？

需求 #

在不改变任何DHCP状态的前提下，发现局域网DHCP服务器（通常为路由器）分配给客户端的DNS服务器。

实现方案 #

• 发送一个DHCP Discover报文，在参数请求列表（Option 55）中请求参数6（DNS服务器）。
• 包含Option 50（请求IP地址），设置为设备当前的DHCP租赁地址。
• 监听DHCP Offer报文，并从中解析Option 6（DNS服务器）。
• 不发送DHCP Request，也不使用任何提供的租赁——即绝不完成DORA流程（Discover→Offer→Request→Acknowledge）。

预期安全性 #

• 根据RFC 2131，当客户端发送Request且服务器返回Ack时，租赁才会生效。由于仅发送Discover而不发送Request，预期客户端标识符（如MAC地址）不会触发租赁生效。
• 服务器可能会临时保留该地址直至Offer超时（如60-120秒），超时后地址应返回地址池。
• 该操作执行频率极低（每24小时一次）。

疑问 #

是否可以安全地认为这种模式（仅发送Discover、不发送Request、低频率执行）不会触发租赁生效，且不会在常规网络中引发问题？是否存在实际的DHCP实现或网络配置（如严格地址池、中继代理或非RFC合规行为）会导致诸如租赁耗尽、保留地址卡住或其他副作用等问题？

回答 #

核心结论：绝大多数常规网络场景下，这种模式是安全的 #

按照你设计的流程操作，几乎不会触发租赁生效——RFC 2131明确规定，只有客户端发送Request且服务器返回Ack后，租赁关系才会正式确立。你只发送Discover并接收Offer，服务器只会临时锁定目标地址一段时间（通常1-2分钟），超时后地址会自动释放回地址池。再加上你每天只执行一次，对网络地址池的影响完全可以忽略。

需要留意的特殊情况 #

虽然常规场景没问题，但少数特殊配置或非合规设备可能带来小概率问题：

1. 极小规模的地址池：如果网络地址池可用地址极少（比如仅5-10个），同时有多台设备采用类似逻辑频繁操作（哪怕你是每天一次，但若存在其他同类设备），短时间内的临时地址锁定可能导致新设备无法获取地址。但单台设备低频率执行的话，基本不会碰到这种情况。
2. 非RFC合规的廉价DHCP服务器：部分低端路由器或定制化DHCP实现，可能违规将收到Discover报文直接视为租赁请求，提前占用地址且不按时释放。不过这种情况非常少见；而且你请求的是自己正在使用的租赁地址，服务器大概率会识别到该地址已被分配，不会重复锁定。
3. 存在DHCP中继代理的网络：如果网络中有DHCP中继，中继可能会将Discover报文转发给多台DHCP服务器，每台服务器都会针对请求的地址发送Offer并临时锁定。但同样，超时后所有临时锁定都会释放，低频率执行不会造成持续影响。
4. 地址静态绑定场景：如果你当前的地址是静态绑定到设备MAC的，发送带Option50的Discover报文时，服务器不会做额外锁定操作——因为地址本来就属于你，完全不会有问题。

额外保险建议 #

如果仍有顾虑，可以在发送Discover报文时，将客户端标识符（Option61）设置为一个临时值，而非设备真实MAC。这样服务器临时锁定的是该临时标识符对应的地址，不会影响你当前的正常租赁关系。不过这并非必需操作，只是多一层安全保障。

内容的提问来源于stack exchange，提问作者John Anthony