我最近一直在阅读有关DNS cache-poisoning attacks 的信息。基本上它们是可能的，因为攻击者可以猜测DNS消息事务ID，因为它只是一个16位整数。即使整数是随机的，一小撮DNS数据包仍然可能在短时间内恰好匹配2 ^ 16个数据包中的1个。
所以第二个安全措施是端口随机化。如果UDP源端口是随机的，则攻击者必须在短时间窗口内猜测两者源端口和事务ID，这通常是不可行的。但我读到旧版本的DNS软件，例如9之前的BIND版本，没有执行端口随机化，因此容易受到攻击。
这让我想到了一个问题：在没有事先调用的情况下使用SOCK_DGRAM时，大多数UNIX操作系统都不像Linux和BSD 自动分配随机端口到bind？我认为这是短暂的端口的整个想法。为什么应用程序（如BIND）必须采用其执行端口随机化的方法？
我的理解是，从本质上讲，像Linux这样的操作系统将具有可用于每个进程的临时端口范围。进程可以调用bind()将UDP套接字绑定到特定端口。但是如果在没有先调用send的情况下使用UDP套接字（即调用bind），操作系统将懒惰地将一个随机短暂端口分配给套接字。那么，为什么较旧版本的BIND不能自动执行端口随机化呢？
答案 0 :(得分：1)
这让我想到了一个问题：大多数UNIX操作系统不像Linux和BSD在使用SOCK_DGRAM时自动分配随机端口而没有事先调用绑定？我认为这是短暂端口的全部想法。
短暂端口的主要思想不是以安全的方式随机，而是快速选择一些未使用的端口。不同的操作系统使用不同的策略，有些操作有点随机，有些使用更强的随机生成器，有些甚至以顺序方式分配端口。 这意味着并非所有操作系统临时端口都不可预测，无法与DNS一起使用。
有关详细信息，我建议您研究RFC 6506＆＃34;端口随机化建议＆＃34;以及https://www.cymru.com/jtk/misc/ephemeralports.html的端口选择策略概述。