What type of queries?
ANY queries for ihren.org with no UDP checksum:
shaun# tcpdump -vv -n port 53
09:32:30.139803 IP (tos 0x0, ttl 251, id 24876, offset 0, flags
[none], proto UDP (17), length 66) 37.221.160.125.28832
93.186.33.42.53: [no cksum] 18554+ [1au] ANY? ihren.org. ar: .
are there legitimate reasons to continue supporting ANY queries?
Good question.
They are very useful for debugging. I would regret their
disappearance. What about forcing TCP for ANY requests only? It would
limit ANY requests to people who don't spoof their source IP address.
I do not
What about rate limiting clients which are not keeping the
TTL value?
We are talking about rate limiting on authoritative name
servers, right?
Not *only* on authoritative name servers. It is also relevant for
recursive name servers.
In general, yes of course. But I had ANY querys and
What I don't understand is that the source adresses are mostly out
of dynamic address pools from broadband ISP around the world.
So the victims are residentinal users?
No, most likely the residential users have CPEs with DNS proxies which
are open to queries from the WAN side. Thus the
Vernon Schryver v...@rhyolite.com wrote:
The second issue concerns log noise and the popular enthusiasm for
using Bloom filters for DNS response rate limiting. I've heard more
than one suggestion for using Bloom filters for DNS response rate
limiting. Bloom filters are a great idea for some
From: Tony Finch d...@dotat.at
To: Vernon Schryver v...@rhyolite.com
cc: dns-operati...@mail.dns-oarc.net
The reason I'm basing my work on a Bloom filter is to avoid any per-client
scaling costs. There's a fixed per-packet overhead, a fixed memory cost
(which should be scaled with the
Vernon Schryver v...@rhyolite.com wrote:
My hope and almost ambition for the code I've been working on is
find a default set of parameters response rate limiting parameters
to reduce the nuisance of open resolvers.
Do you expect the parameters to differ for reflected amplification attacks
on
From: Tony Finch d...@dotat.at
I think it's wrong to focus on ANY queries: restricting them just
encourages the attackers to move on to another query type. For a domain
with DNSSEC you get almost as much data in return to an MX query - 2KB vs
1.5KB for cam.ac.uk.
Today I see 2232 byte
On Jun 11, 2012, at 6:34 PM, Tony Finch wrote:
For a domain with DNSSEC you get almost as much data in return to an MX
query - 2KB vs 1.5KB for cam.ac.uk.
They've been doing that for a while.
---
Roland Dobbins
On Jun 11, 2012, at 10:07 PM, Vernon Schryver wrote:
But spending any long term effort on ANY queries in this context
All I'm saying is that tactically filtering out ANY queries whilst one is under
attack may be a valid tactical response, and that encouraging software
developers not to make
From: Tony Finch d...@dotat.at
To: Vernon Schryver v...@rhyolite.com
cc: dns-operati...@mail.dns-oarc.net
At the moment I'm just using BIND's sockaddr_hash routine, adapted to hash
on the network prefix and to provide two variant hashes.
I think you would do better by treating the IP
Paul,
how about much simpler configuration option to force all
any queries to be reissued over TCP,
restrict-any-udp yes/no;
And have Bind reply with TC=1 and empty answer section on ANY UDP queries.
This is simple, no state needed, no firewall rules, and gets rid of
spoofed
Well, partly from what I see.
Posts from yesterday already mentioned that many sources are not spoofed for
the actual query the nameserver sees.
If I look at our logs I see that most of the any queries come from
north-america, not china. They use spoofed source ip's to reach the cpe, but
the
how about much simpler configuration option to force all
any queries to be reissued over TCP,
restrict-any-udp yes/no;
as i charge by the byte, i like it a lot. ymmv.
randy
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
In case anyone wants a little help finding out if their name servers are being
hit
with ANY queries, a new version of dnstop has been released with a filter to
show only the ANY queries.
You can get the source code at
http://dns.measurement-factory.com/tools/dnstop/src/dnstop-20120611.tar.gz
* Kyle Creyts:
Wouldn't an ANY query to a recursive ONLY return the cached records?
This is implementation-dependent, and you can make sure that the cache
contains sufficient amounts of data anyway.
___
dns-operations mailing list
Vernon Schryver and Paul Vixie have been working on DNS Response Rate
Limiting (DNS RRL) as a patch set to BIND9 (9.9.1-P1 or 9.8.3-P1) and we
are ready for broader external testing.
Details on how to fetch the patches and specifications are at:
http://www.redbarn.org/dns/ratelimits
A note
bigger question: why allow the UDP 53 to CPE to be answered as if it
were from internal? the external connectivity to port 53 should be
able to be forwarded at the consumer's discretion, but should
certainly not be answered by the DNS proxy!
On Mon, Jun 11, 2012 at 9:46 PM, Vernon Schryver
18 matches
Mail list logo
