4 ms·

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 attac

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.

bogantech 2y ago
> 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
- nubinetwork 2y ago
  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
- josephcsible 2y ago
  > 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".
Dylan16807 2y ago
If you want to stop UDP DNS from being able to amplify, require bigger query datagrams.
- citrin_ru 2y ago
  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.
  - burnt-resistor 2y ago
    > 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?
citrin_ru 2y ago
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?
- vetrom 2y ago
  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.

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.

bogantech 2y ago

> 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

nubinetwork 2y ago
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
josephcsible 2y ago
> 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".

Dylan16807 2y ago

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

citrin_ru 2y ago
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.
- burnt-resistor 2y ago
  > 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?

citrin_ru 2y ago

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?

vetrom 2y ago
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.