Hacker News Reader

Comment by nubinetwork | Hacker News Reader

This sounds like bad advice, I don't know why ISC is pushing this... they would be better off trying to make DNS a TCP-only service to stop amplification attacks.

View on HN

> This sounds like bad advice

Please elaborate.

As they say a typical DNS request comes in as one packet and is replied in one packet, there is no ongoing connection so there's no point keeping tracking information.

The implication of not tracking the connection is that any packets will have to match a more specific rule than the "allow established,related" at the top of the firewall chain.

> they would be better off trying to make DNS a TCP-only service to stop amplification attacks.

Sure, lets get literally everyone on the intenet to agree to a new version of DNS that uses TCP...

Even if you do that - the problem moves from conntrack filling up we can fill up on ephemeral ports stuck in TIME_WAIT because some genius thought a service that doesn't maintain a connection should use TCP

> lets get literally everyone on the intenet to agree to a new version of DNS that uses TCP

That's already done. DNS servers already all speak both TCP and UDP. Try "dig google.com @8.8.8.8 +tcp".

Sorry, I didn't see the replies... but you technically don't have to connect for every new request, just connect once and leave it open for new requests. /shrug

TCP is less efficient for request-response protocol. The root of the problem (DDoS with amplification) IMHO is not DNS but ISPs which allow to spoof source addresses. Most don’t allow. RFC2827 (BCP38) was published >20 years ago and the problem was not new even back then. How bad guys find ISP (or hostings) permitting src IP spoofing? Is there a way to encourage such ISP to follow BCP38?

You could de-peer/internet-death-penalty them, but, as is often the case, there is not alignment between the business objectives and network operator objectives.

If you want to stop UDP DNS from being able to amplify, require bigger query datagrams.

I would rather prefer responses to become smaller. If you would check TXT record for almost any big company you'll find a lot of verification records which either unnecessary (because better way to confirm domain ownership exists, e. g. by adding a DNS record with unique name instead of using main domain TXT record) or outdated (e. g. they did verify multiple times but kept records from all attempts). And more generally big companies tend to treat domain's DNS TXT record as an append-only structure and never clean junk it accumulates.

  host -t txt amazon.com | wc -l
  35

and that's not the worst example unfortunately.

> never clean junk it accumulates

That's true of everything inside a corporate codebase. There's no reward for refactoring, only adding new features or fixing a SEV1. Why should that be everyone else's problem because they can't clean it up?

Reply on news.ycombinator.com