Clue appreciated, thanks!
One word: qmail. Google qmail dns any query.
It would actually be *good* to stop answering the ANY queries if that
would force qmail installations do something about this behavior. But
I don't have high hopes...
Steinar Haug, Nethelp consulting, sth...@nethelp.no
One word: qmail. Google qmail dns any query.
thinking about or acting against ANY is bad infosec economics. any
investment along those lines is wasted, since ANY is merely the low
hanging fruit, and an attacker need only switch over to TXT or RRSIG or
NSEC to get a similar amplification
Not supporting
ANY queries would also have side effects - simply dropping the
query maks the authoritative server appear unresponsive to the
recursive server initiating the query.
Note that in many cases the server receiving the ANY query is a
recursive server, not an authoritative server.
limiting EDNS responses to 1460 bytes, as suggested [by me], will
block quite a few legitimate replies (not just ANY replies).
Why? The response will be sent, just with a TC bit, and the client, if
it is not lying about its IP address, will retry with TCP. No
blocking.
Agreed, this
Surprised no one's brought up http://dk/ as an already existing scenario
that doesn't work (try it in various browsers).
Bad example. The first *four* browsers I tried (firefox, chrome, safari,
and opera on osx) handle this perfectly.
http://dk/ doesn't work particularly well on my Win 7
I'm seeing a bunch of DNS ANY requests to my authoritative servers with
Amazon EC2 source IPs. I guess somebody is now trying to run an
amplification attack against Amazon?
Highly likely.
This is the first time I've seen Amazon targeted this way; are others
seeing this (am I just late to
It would be nice if ANY queries just got thrown away. I can live with the
breakage that causes. YMMV. However if there was something that generally
blocked or discarded ANY queries, the bad guys would switch to some other
QTYPE that can't be blocked without causing significant operational
In addition to Nick Urbanik's work, which is log file based, we've also
provided some tooling to detect the originators and domains in the recent
flood of malicious DNS traffic based on PCAP files.
From our mailing list post to pdns-users yesterday:
Secondly, the botnet mitigation code in
According to Google - ns{1,2,3,4}.google.com:
gmail.fr. 345600 IN NS ns1.google.com.
gmail.fr. 345600 IN NS ns2.google.com.
gmail.fr. 345600 IN NS ns3.google.com.
gmail.fr. 345600 IN NS
By the way, as far as i know french people use gmail.com in place of
gmail.fr. They won't even notice ! ;)
Indeed, I've never seen gmail.fr advertised by Google and I'm
surprised to learn it is used in Norway. Google Search finds only one
link for gmail.fr :-)
It may not actually be
Our current thinking (based on evidence from some of our customers, and
also from Nominum's analysis presented at the Warsaw DNS-OARC workship
earlier this year) that the majority of these recent query spates are
intended as an attack on the domain (e.g. feile.com) or the
nameserver
Although the attack could be done with a botnet or by reflecting traffic
off end-user equipment, many of the attacks I have seen involve source
IP spoofing. I deduce this by noting that a fairly large percentage of
the traffic comes from blocks of IPs that are not currently routed on
the open
I am seeing a lot of them (9,997) with Transaction ID of 0x04d2. This seems
to be something odd (but again I still need to learn a lot more about the
decisions implementations make with their queries) but it gives me a feeling
of a hard coded request.
...
I believe this may be a hard coded
>> Is anyone else experiencing resolution issues for names in this domain? We
>> are seeing a lot of queries of the form:
>> CNAME? bvusfvyq.s3.amazonaws.com
>> (the label before ".s3" looks random) and a lot of SERVFAIL responses.
>>
>> Any clues would be appreciated.
>
> If you believe The
> No, even small responses receive no answers from the IPv6 addresses
> of the C and F roots. Both of the below time out even though I'm
> not setting the "DO" bit:
>
> $ dig -6 +norecur -t soa arpa. @2001:500:2f::f
> $ dig -6 +norecur -t soa arpa. @2001:500:2::c
>
> Looks like an
> this isn't a flag day and shouldn't be called that. it cheapens the
> term.
>
> 1232 is a cargo-cult number. we must not revere as holy those things
> which fall out of the sky.
>
> there is a right way to deprecate fragmentation. it would not involve
> adding config complexity.
>
> there is
>> Are there any published numbers estimating how well the various DNSSEC
>> algorithms are supported in DNS caches and client software?
>
> Off the top of my head: https://dnsthought.nlnetlabs.nl/#ecdsa256
>
> but 13 in particular feels quite deployed in zones - I know about .cz
> but I'm sure
>
> 14:23:58.147601 IP customer.32769 > 212.60.63.246.53: 17710+ A?
> time-g.netgear.com. (36)
> 14:23:58.147603 IP customer.32769 > 212.60.61.246.53: 17710+ A?
> time-g.netgear.com. (36)
> 14:23:58.147613 IP customer.32769 > 212.60.63.246.53: 17710+ A?
> time-g.netgear.com. (36)
>
We are receiving a significant amount of query bursts on our resolvers
with the following characteristics:
- A client IP doing a burst of queries for the same name repeatedly,
very quickly.
- The query is typically an A query.
- A burst often has 50 - 100 queries for the same name within a few
> DNS speaking, I can query G root servers; at least, that's the most
> important.
>
> However, from several sites, either on IPv4 or IPv6, I cannot ping(6)
> them. Is it by design, or it's an issue?
>
> Side question: even if it was by design, is it a good practice to
> completely restrict
>> it occurred to me that it migh tme wise to have a rancid like
>> (https://shrubbery.net/rancid/) equivalent for critical domains.
>> i.e. to git record changes and warn of radical diffs.
>>
>> is there any foss tooling in this space?
>
> Assuming there isn't - yet...- What would you
21 matches
Mail list logo
