Getting "query failed (REFUSED) for ./IN/ANY"
Hi,
I'm getting lots of log lines like the following:
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2a3b80 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2784d0 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:27 30 north named[22233]: client @0x7fe0fc2953f0 74.74.74.8#57620
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Is that meant to be a DoS attack?
Yesterday I got 42639 of those, from 41 different IPs, the most frequent
clients looking like so:
821-north:~$ sed -rn 's/^.{15} 30 north named[^:]*: client @0x[0-91-f]*
([0-9.]*)#[0-9]* ...: view external: query failed .REFUSED. for ..IN.ANY at
.bin.named.query.c:7144/\1/p' < /var/log/daemon.log.0 |sort |uniq -c
|sort -rn |head
4957 68.42.225.19
2914 73.73.73.73
2868 24.21.125.251
2783 193.70.81.112
2440 73.73.3.73
2273 101.71.138.9
2032 74.74.74.8
1814 98.25.235.45
1785 209.94.134.20
1756 73.109.143.81
I looked up some of these on AbuseIPDB, and I see there are a few people
reporting them for the same DDoS.
Are the queries refused because of the dot (.)? In the query log, I also found
some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which probably got
away with a NXDOMAIN.
This morning, queries for IN ANY are filling up a 63% of total queries. Named
seems to be pretty quick at discarding them. I'm wondering whether it takes
more resources to track and firewall those IPs or just ignore them.
I'd be also curious of what they are after. Is there a protest against RFC
8482? It looks pretty nonsensical. Any insight?
Best
Ale
--
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On 13.01.21 10:21, Alessandro Vesely wrote:
I'm getting lots of log lines like the following:
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2a3b80 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:18 30 north named[22233]: client @0x7fe0fc2784d0 74.74.74.8#24048
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Jan 12 04:35:27 30 north named[22233]: client @0x7fe0fc2953f0 74.74.74.8#57620
(.): view external: query failed (REFUSED) for ./IN/ANY at
../../../bin/named/query.c:7144
Is that meant to be a DoS attack?
most probably.
Yesterday I got 42639 of those, from 41 different IPs, the most frequent
clients looking like so:
821-north:~$ sed -rn 's/^.{15} 30 north named[^:]*: client @0x[0-91-f]*
([0-9.]*)#[0-9]* ...: view external: query failed .REFUSED. for ..IN.ANY at
.bin.named.query.c:7144/\1/p' < /var/log/daemon.log.0 |sort |uniq -c
|sort -rn |head
4957 68.42.225.19
2914 73.73.73.73
2868 24.21.125.251
2783 193.70.81.112
2440 73.73.3.73
2273 101.71.138.9
2032 74.74.74.8
1814 98.25.235.45
1785 209.94.134.20
1756 73.109.143.81
I looked up some of these on AbuseIPDB, and I see there are a few people
reporting them for the same DDoS.
can be ddos attempt on those IPs.
Are the queries refused because of the dot (.)? In the query log, I also
found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which
probably got away with a NXDOMAIN.
no. the dot is just the root domain.
This morning, queries for IN ANY are filling up a 63% of total queries.
Named seems to be pretty quick at discarding them. I'm wondering whether
it takes more resources to track and firewall those IPs or just ignore
them.
fail2ban should help not to see those messages
I'd be also curious of what they are after. Is there a protest against RFC
8482? It looks pretty nonsensical. Any insight?
often, nameservers respond with list of delegations for this query:
% dig +noall +stats -t any . @localhost
;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 13 11:01:08 CET 2021
;; MSG SIZE rcvd: 2272
this way, server will respond with >2KB packet which may flood the
destination IP.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.
% dig +noall +stats -t any . @localhost
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On Wed 13/Jan/2021 11:03:01 +0100 Matus UHLAR - fantomas wrote: On 13.01.21 10:21, Alessandro Vesely wrote: Are the queries refused because of the dot (.)? In the query log, I also found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which probably got away with a NXDOMAIN. no. the dot is just the root domain. I see. This morning, queries for IN ANY are filling up a 63% of total queries. Named seems to be pretty quick at discarding them. I'm wondering whether it takes more resources to track and firewall those IPs or just ignore them. fail2ban should help not to see those messages Ditto for grep -v :-) I use a sort of fail2ban-lite, but hadn't bothered to firewall UDP. Indeed, if the intent is an amplification attack, the IPs I'd find are those of the victims, not the attackers. I'd be also curious of what they are after. Is there a protest against RFC 8482? It looks pretty nonsensical. Any insight? often, nameservers respond with list of delegations for this query: % dig +noall +stats -t any . @localhost ;; Query time: 17 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 13 11:01:08 CET 2021 ;; MSG SIZE rcvd: 2272 this way, server will respond with >2KB packet which may flood the destination IP. Aha, thanks for the tip! That may make sense, except that the server won't amplify: ; <<>> DiG 9.16.1-Ubuntu <<>> @north.tana.it . any ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 29022 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ee8e36f499f24056c063244b5ffece98904d8e19b39c94a8 (good) ;; QUESTION SECTION: ;. IN ANY ;; Query time: 287 msec ;; SERVER: 62.94.243.227#53(62.94.243.227) ;; WHEN: mer gen 13 11:42:32 CET 2021 ;; MSG SIZE rcvd: 56 Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On Wed, 13 Jan 2021 10:21:19 +0100
Alessandro Vesely wrote:
> Yesterday I got 42639 of those, from 41 different IPs, the most frequent
> clients looking like so:
> 821-north:~$ sed -rn 's/^.{15} 30 north named[^:]*: client @0x[0-91-f]*
> ([0-9.]*)#[0-9]* ...: view external: query failed .REFUSED. for ..IN.ANY at
> .bin.named.query.c:7144/\1/p' < /var/log/daemon.log.0 |sort |uniq -c
> |sort -rn |head
> 4957 68.42.225.19
> 2914 73.73.73.73
> 2868 24.21.125.251
> 2783 193.70.81.112
> 2440 73.73.3.73
> 2273 101.71.138.9
> 2032 74.74.74.8
> 1814 98.25.235.45
> 1785 209.94.134.20
> 1756 73.109.143.81
Through a side project I report on IN ANY queries and have seen all of
those addresses and more as you can examine here:
Some may be sourced from a security/research survey project, but some
sources performing this may be for more nefarious purposes - building a
list of open resolvers that will answer for the purposes of maintaining
an amplication/reflection hit list.
Unfortunately there are many open resolvers that answer, but perhaps
except for a name you are authoritative for, responding with a REFUSED
response is generally considered reasonable and appropriate.
John
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
> >Are the queries refused because of the dot (.)? In the query log, I also > > found some 28 IN ANY queries from 7 IPs for xxx.at.fragolina.it, which > > probably got away with a NXDOMAIN. > > no. the dot is just the root domain. Correct that . is the root domain, but I'd say the answer is a qualified yes. If you are not providing open recursive services and are not authoritative for the root domain, BIND will respond with REFUSED just like it would if someone asked you about example.com when you're not authoritative for that. In the old days you'd get a root referral for authoritative resolution, but now you get a minimal REFUSED to signal lack of authority for the question. -- tale ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Getting "query failed (REFUSED) for ./IN/ANY"
On Wed 13/Jan/2021 14:31:58 +0100 John Kristoff wrote: Some may be sourced from a security/research survey project, but some sources performing this may be for more nefarious purposes - building a list of open resolvers that will answer for the purposes of maintaining an amplication/reflection hit list. I see some IPs are the same. However, my attacker seems rather to be (blindly) attempting an amplification attack than building a list of open resolvers, because the same IP is usually retried 4~6 times. Best Ale -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Getting "query failed (REFUSED) for ./IN/ANY"
Matus UHLAR - fantomas wrote: > fail2ban should help not to see those messages I expect there are probably only two people on the planet running BIND on Windows: me, and the ISC Developer responsible for building the Windows binaries 😊 As part of a larger project I've been developing a series of tools for BIND log file analysis on Windows. One of these tools includes dynamically updating the Windows firewall to block requests from IP addresses that are issuing these sorts of queries. The source IP is of course being spoofed when the request is sent over UDP, but I block it anyway because that means I'm *preventing* my BIND servers from participating in the DDoS attack by sending *any* traffic to the intended victim (the spoofed IP). If anyone is interested in this then please get in touch - I'd be very happy to share my work if it will help others in the community. And who knows, perhaps that means there'll eventually be up to THREE of us running BIND on Windows! Best, Richard rich...@richardneal.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: "not subdomain of zone {XXXX} -- invalid response" errors found in named.run log
> On 7 Jan 2021, at 00:57, 同屋 <39223...@qq.com> wrote:
>
> Actually, the background is a little bit complicated. In short, the topo is
> as belows. dns1 were swapped by a new one (say dns1*), then the issue
> happened. After that, we dropped all the request from dns1*, then the
> issue was gone.
Well if you stop making requests that result in negative responses (NXDOMAIN or
NOERROR/NODATA) you no longer send responses with the incorrect SOA record in
the authority section.
> There is no config change during the whole process, no idea why the caching
> server has such log.
You get such logs because there are servers that are misconfigured. If you
delegate a zone to a server then ALL negative responses for queries in that
delegated namespace should be coming back with a SOA record that matches the
delegated zone. Named checks the returned SOA record in the authority section
and if it isn’t a expected value then named logs the messages you are seeing.
You can reproduce this with the following setup where example.com is delegated
to server1.example.com and child.example.com is delegated to
server2.example.com but it is incorrectly configured for a different version of
example.com.
server1.example.com(192.0.2.1):
example.com.SOA server1.example.com. . 0 0 0 0 0
example.com.NS server1.example.com.
server1.example.com.A 192.0.2.1
server2.example.com.A 192.0.2.2
child.example.com. NS server2.example.com.
server2.example.com(192.0.2.2):
example.com.SOA server2.example.com. . 0 0 0 0 0
example.com.NS server2.example.com.
server2.example.com.A 192.0.2.2
child.example.com. A 192.0.2.3
A proper delegation would have:
server2.example.com(192.0.2.2):
child.example.com. SOA server2.example.com. . 0 0 0 0 0
child.example.com. NS server2.example.com.
child.example.com. A 192.0.2.3
Load balancers often end up with broken configuration because, it appears, the
documentation is not clear enough. The load balancing software knows about A
queries and returns for them but punts all the other queries to a backing
server which instead of being configured with the zone child.example.com is
configured with the zone example.com which contains just the SOA and NS records.
example.com.SOA server1.example.com. . 0 0 0 0 0
example.com.NS server1.example.com.
Client -> load balancer -> backing server.
If you ask for child.example.com/A you get back a A record with the computed
value.
If you ask for child.example.com/ the load balancer says this not something
I deal with and passes the request on to the backing nameserver which, because
it has been configured to serve example.com instead of child.example.com,
returns a negative response with example.com as the owner name of the SOA
record rather than a child.example.com SOA record that is expected.
Mark
> -
> |dns1 | | dns2 |
> -
> | |
> --
> |
>-
> |caching server| (where the log was observed)
> --
>
> -- Original --
> From: "同屋";<39223...@qq.com>;
> Send time: Wednesday, Jan 6, 2021 8:43 PM
> To: "同屋"<39223...@qq.com>; "marka";
> Cc: "Bind-users";
> Subject: re:Re: "not subdomain of zone {} -- invalid response" errors
> found in named.run log
>
> Thanks mark, but why this issue is related to load balancer?
>
>
>
> -- Original Message --
> From: "Mark Andrews";
> Date: 2021-01-06 19:09
> To: "同屋"<39223...@qq.com>;
> To:
> "bind-users";
>
> Subject: Re: "not subdomain of zone {} -- invalid response" errors found
> in named.run log
>
>
> Complain to the administrators of the zone. They have not properly delegated
> it. We see this often with load balancers.
>
> The zone a.b.example has been delegated but the answer is as if it is from
> b.example.
>
> --
> Mark Andrews
>
>> On 6 Jan 2021, at 21:02, 同屋 <39223...@qq.com> wrote:
>>
>>
>> The version of bind is BIND 9.10.5-P3 id:7d5676f
>>
>> One day, I found that the size of named.run is increasing very quickly. And
>> a lot of "invalid response" entries were spotted in the log. Details is as
>> follows (I replace the sensitive info with {},{AAA} etc.)
>>
>> DNS format error from {IP}#53 resolving
>> {}.bf.bf.node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org/ for client
>> 169.254.4.50#51099: Name epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org (SOA) not
>> subdomain of zone node.epc.mnc{AAA}.mcc{BBB}.3gppnetwork.org -- invalid
>> response
>>
>> The response related to the above log is as follows:
>>
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50664 ;; flags: qr aa rd
>> ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT
>> PSEUDOSECTION: ; EDNS: version
