[dns-operations] DNS greylisting?

Paul Vixie paul at vix.com
Mon Mar 6 19:39:03 UTC 2006


# Would it violate the protocol too heinously if a nameserver returned  
# TC for all UDP queries from particular sources -- e.g. allow UDP  
# queries to function normally only if the sources were trusted, and  
# attempt to force all others to use TCP instead?

violate?  not exactly.  be useful?  also not exactly.

if large numbers of nonmalicious queries are forced to use TCP, then a
malfeasant can deny service for those queries by attacking the TCP quota
and connection management logic in the nameserver.  we've always known
that a SYN flood against a DNS server would prevent zone transfers, but
this isn't an exciting target (most of the time, anyway) and so it's not
attacked and so we don't have to worry that it's a very soft target.  if
we made TCP a normal fact of life for large numbers of nonmalicious queries
then even assuming we could maintain the transaction rates we have now
when there is NOT an attack, the softness of the target would put that
entire workload at the mercy of any malfeasant.  in fact this would be a
softer target than the one we're trying to protect now (DDoS by spoofed
sources of queries, with or without EDNS, through distant open recursive
name servers.)  so, there's no meat on this bone.

# If the truncated UDP response was small, that could limit the  
# amplification potential.

it wouldn't matter.  amplification is gravy.  reflection is still painful,
which is why any proper "closure" of a recursive name server has to result
in silence (no ICMP, no DNS-REFUSED, just empty air) when a query comes
from an unauthorized ("external") source.  that is of course counterintuitive.

# Clients which resubmitted their query using TCP might be whitelisted,  
# such that future UDP queries from those hosts within a window might  
# be allowed with no forced truncation (e.g. using a fixed-size, LRU  
# cache). The rationale this whitelisting would be that the client had  
# demonstrated behaviour consistent with a non-spoofed source address.

even if that wasn't patented (which it is, though i don't know the number
off hand), it's still a bad idea due to the softness of the target during
the initial probes.  new/churn workload is not less important than steady
state workload, or at least, it's a high-value target and must be protected.



More information about the dns-operations mailing list