Re: [dns-operations] responding to spoofed ANY queries
* Paul Vixie: The spoofing problem could be mitigated if we actually wanted to, and were willing to punish those who try to send their pollution to the rest of the network. no. there is no we in this context. I meant the we in we the people. Punishment for community-harming behavior should be the prerogative of the sovereign, anyway. We just need to admit that self-regulation by the industry has failed to address this matter adequately. and having so admitted, what will we do next or do differently? We could lobby for law that makes those who push packets with forged source addresses (so that original network operator cannot be identified anymore) liable for the damage these packets cause. the internet is extra-legal because it is extra-national. Doesn't really matter. If a network peer doesn't have the same liability as you do, you better put in filters. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] ID of IPv4 fragments and DNS and the future RFC
The future RFC 6864, currently in AUTH48 state, talks about the
unicity of the ID (datagram identifier) field for IPv4. Its section
5.2 is of interest to us: basically, it says that senders of
non-atomic packets (a non-atomic packet is an IPv4 packet which is
fragmented or will possibly be, since it has no DF bit: unlike a HTTP
server, the traffic of a DNS server is typically mostly made of
non-atomic packets) MUST rate-limit such packets to enforce the old
(RFC 791) rule that ID must be unique for the duration of a packet in
the network (typically two minutes, a number I've always find very
high).
Is there a practical consequence for us? My first guess is No since
the unicity is only per couple {src, dest} and there is no chance a
DNS server will have to send more than 6.4 Mbps to a given destination
(6.4 is the maximum throughput with a 1500 B MTU with the ID unicity
limit).
Of course, during attacks, the throughput can be much higher but, when
there is an attack, we have a bigger problem than ID duplication.
So, my first reaction is let's do nothing. Do we agree?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
From: David Conrad d...@virtualized.org I suspect you're misunderstanding what I'm saying ... Yes, it is yet another form of security theatre, but when has that stopped anyone? Yes, I misunderstand your position as the same as others'. However, I'm pretty sure this isn't appropriate fodder for dns-operations... Perhaps not, if the supposed lack of laws is not an excuse for DNS recursive server operators to keep them open and for authoritative servers to refuse to install some kind of rate limiting. The many years of stop bothering me, spam isn't illegal responses from operators of open SMTP relays and other spam-critical services make me wonder. There are many open recursive servers and authority servers without rate limiting or with RRL manually disabled except for the previously common flavors of attack. ] From: Frank Bulk frnk...@iname.com ] If the problem is amplification, why not only perform RRL on only those DNS ] communications exchanges that have certain amplification factor (i.e. 1.5). That sounds nice but has problems. The main one for me is that you'd have wait until the response has been marshalled before determining it size and deciding whether to drop it. That seems to me harder to code in BIND9 and more expensive in CPU cycles. A better reason is that simple A requests are much smaller than typical non-DNSSEC responses. `dig iname.com @204.74.108.1` sends 38 bytes and receives 225 for 5.9X amplification. 5X is not as flashy as 30X, but is a big problem. 5X is a lot more than your 1.5X and so in practice you would rate limit all responses. If you always do it, you might as well do it in the cheapest way possible, before knowing and regardless of the size of the response. Even 1X or no amplification could be useful to a bad guy wiggling through firewall holes or obscuring an origin. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] responding to spoofed ANY queries
On 13 Jan 2013, at 16:28, Vernon Schryver v...@rhyolite.com wrote: If the problem is amplification, why not only perform RRL on only those DNS communications exchanges that have certain amplification factor (i.e. 1.5). That sounds nice but has problems. The main one for me is that you'd have wait until the response has been marshalled before determining it size and deciding whether to drop it. That seems to me harder to code in BIND9 and more expensive in CPU cycles. I suppose a name server could keep a (small?) cache of recently marshalled answers and use that to either rate limit responses which are too large or identical to one that has recently been sent to the same IP address(es). [For some definition of large and recent.] This might even be cheaper/faster in some cases. ie Generating a reply with a memcpy() from whatever outgoing packets have been kept in this cache instead of assembling all the RRs, doing label compression, etc. It could be good to have something which rate limits outgoing responses in addition to what's done with incoming queries. Doesn't some name server implementation - PowerDNS? - already do this? Might not be for rate limiting though... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ID of IPv4 fragments and DNS and the future RFC
On Sun, Jan 13, 2013 at 08:59:39PM +0100,
Florian Weimer f...@deneb.enyo.de wrote
a message of 30 lines which said:
A typical initial TTL is 64, so the packet lives for at most 64
seconds. (Originally, the TTL was measured in seconds,
It was a very long time ago. RFC 1122, in 1989, already said that the
TTL field is more a hop count than a real TTL.
Future RFC 6864 speaks about MDL (Maximum Datagram Lifetime) and,
relying on things like the reassembly timeout (RFC 1122, section
3.3.2), estimates it to two minutes.
1000 responses per second doesn't seem that much, though.
To the *same* destination? (The ID only has to be unique per each tuple
{src, dst, protocol}.) It looks a lot.
(Fortunately, IPv6 comes with a 32 bit fragment ID...)
That's an answer to my question: move all the traffic to IPv6 and the
problem will disappear.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
