srv lookup in record
Is it possible to use srv lookups, like eg cname. I do not want to create SRV record, I just want to 'get' the ip addresses, that I would get vai srv lookup. Say I have this task [@temp3]$ dig +short server.test.marathon.mesos 192.168.123.101 192.168.124.50 192.168.124.52 192.168.124.51 192.168.123.100 192.168.123.102 [@temp3]$ dig +short srv _http-apps._server.test._tcp.marathon.mesos 0 1 31024 server.test-usbzr-s3.marathon.mesos. 0 1 31852 server.test-z9x84-s3.marathon.mesos. 0 1 31790 server.test-k7g8r-s4.marathon.mesos. [marc@os0 temp3]$ dig +short srv _http-demo._server.test._tcp.marathon.mesos 0 1 31791 server.test-c8g8b-s4.marathon.mesos. 0 1 31025 server.test-wtbza-s3.marathon.mesos. 0 1 31853 server.test-d0x87-s3.marathon.mesos. I would like to only make available the ip addresses that are in the same range. If I would use a cname like this: server.local. CNAMEserver.test.marathon.mesos. I would get 6 of which 3 ip addresses are not in the same range. So I need to have something like server.local. ??? _http-apps._server.test._tcp.marathon.mesos. Is this possible in bind-9.8.2-0.68.rc1.el6_10.3.x86_64? ___ 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: srv lookup in record
> I don't think so, nor does it seem to make sense to me that you would > want such a thing (in the general case, you may have a use-case). What would be better way to solve this then? To filter out only the ip addresses that are in the same netmask? ___ 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: Bind stats - denied queries?
Are newer version of bind still logging like this Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to 3.9.41.0/24 Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to 35.177.154.0/24 Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses to 35.177.154.0/24 Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses to 3.9.41.0/24 I already reported, that it is not to smart to log 3.9.41.0/24, better could be logged 3.9.41.100/24 so you know the offending ip. -Original Message- From: Karl Pielorz [mailto:kpielorz_...@tdx.co.uk] Sent: Monday, November 30, 2020 11:08 AM To: bind-users@lists.isc.org Subject: Bind stats - denied queries? Hi, We've been seeing a huge increase in 'denied queries' against a couple of Bind servers we look after (Bind 9.16.9) - these are currently logged as: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " This appears like it might be someone trying (unsuccessfully) to use us as an amplifier / reflector. We've got Bind's statistics file setup - but I can't see there's any entry for these "denied" queries? - As we'd really like to monitor this. If anyone knows what stat these turn up in the statistics file (if at all?) Thanks, -Karl ___ 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 ___ 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: Bind stats - denied queries?
Regardless if the source is spoofed or not, one should log it. Especially with this amazon abuse cloud, how can you report abuse, they want to have an ip address to be able to investigate if something originated from their network. If you log 0/24 you might as well log no range at all. Am 30.11.20 um 11:12 schrieb Marc Roos: > Are newer version of bind still logging like this > > Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to > 3.9.41.0/24 > Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses to > 35.177.154.0/24 > Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses to > 35.177.154.0/24 > Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses to > 3.9.41.0/24 > > I already reported, that it is not to smart to log 3.9.41.0/24, better > could be logged 3.9.41.100/24 so you know the offending ip there is nothing like an "offending ip" in case of dns-amplification which is usually what happens in context of RRL it's the forged destination of the attack you see and nothing else ___ 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: Bind stats - denied queries?
You assume incorrectly that every such log entry is from spoofed traffic. This is about correct logging. Even if it is spoofed, logging the correct spoofed address is better than logging a range (that include ip's that are maybe not even participating) There is only, but only one advantage I can think of, and that is grouping to one log entry. -Original Message- Subject: Re: Bind stats - denied queries? the source of dns amplification is *always* spoofed because it's by design the IP of the victim and not the offender the goal of dns amplification is to flood the connection of the victim until no regular traffic is possible the same /24 is sharing the same line and so it doesn't make sense in that context talk about single ip's at all it also doesn't make sense to write abuse reports for such things because additionally to the technical packet flood you also flood human ressources with nosense there they aren't the offender, they can't do anything about your issue because the are *the victim* you are one of thousands or even millions of hosts the attacker is trying to get responses from to the victim please try to understand https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/ and RRL is only useful for that type of attack, everything else don't matter for a DNS server and more important you can't distinct it anyways Am 30.11.20 um 18:23 schrieb Marc Roos: > Regardless if the source is spoofed or not, one should log it. > Especially with this amazon abuse cloud, how can you report abuse, > they want to have an ip address to be able to investigate if something > originated from their network. > > If you log 0/24 you might as well log no range at all. > > Am 30.11.20 um 11:12 schrieb Marc Roos: >> Are newer version of bind still logging like this >> >> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses >> to >> 3.9.41.0/24 >> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses >> to >> 35.177.154.0/24 >> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses >> to >> 35.177.154.0/24 >> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses >> to >> 3.9.41.0/24 >> >> I already reported, that it is not to smart to log 3.9.41.0/24, >> better > >> could be logged 3.9.41.100/24 so you know the offending ip > > there is nothing like an "offending ip" in case of dns-amplification > which is usually what happens in context of RRL > > it's the forged destination of the attack you see and nothing else ___ 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: Bind stats - denied queries?
Every entry is relevant, because that is how you configured it to be. Do
you even know that this limit is configured in your config at
'rate-limit {};'? It logs everything that exceeds this limit. (<- notice
the . period)
So you can dump queries from a host 192.168.a.b, exceeding this limit
and your log entry is incorrect! Because it will have 192.168.a.0 and
not 192.168.a.b. Let me put it like this, logging 192.168.a.0 is just
plain stupid. Your log an incorrect event! The idea about logs, is that
they are correct.
-Original Message-
Sent: Monday, November 30, 2020 10:45 PM
To: Marc Roos; bind-users; kpielorz.lst
Subject: Re: Bind stats - denied queries?
Am 30.11.20 um 20:01 schrieb Marc Roos
> You assume incorrectly that every such log entry is from spoofed
> traffic.
every relevant one, yes
> This is about correct logging. Even if it is spoofed, logging the
> correct spoofed address is better than logging a range (that include
> ip's that are maybe not even participating)
there is nothing like "not even participating" in a /24 in case of
reflection
> There is only, but only one advantage I can think of, and that is
> grouping to one log entry.
no, it logs what it does: responses to that /24 are rate-limited because
otherwise you won't be able to reduce the impact
you still refuse to understand wo is attacker and who is victim! *you
are* the attacker sending responses larger then the request to the
forged sources
you are *not* target, you are part of the attack und you have no way to
do anything against that on a UDP protocol except rate-limit your
responses because you have no way to find out the real source
> -Original Message-
> Subject: Re: Bind stats - denied queries?
>
> the source of dns amplification is *always* spoofed because it's by
> design the IP of the victim and not the offender
>
> the goal of dns amplification is to flood the connection of the victim
> until no regular traffic is possible
>
> the same /24 is sharing the same line and so it doesn't make sense in
> that context talk about single ip's at all
>
> it also doesn't make sense to write abuse reports for such things
> because additionally to the technical packet flood you also flood
> human ressources with nosense there
>
> they aren't the offender, they can't do anything about your issue
> because the are *the victim*
>
> you are one of thousands or even millions of hosts the attacker is
> trying to get responses from to the victim
>
> please try to understand
> https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack
> / and RRL is only useful for that type of attack, everything else
> don't matter for a DNS server and more important you can't distinct it
> anyways
>
> Am 30.11.20 um 18:23 schrieb Marc Roos:
>> Regardless if the source is spoofed or not, one should log it.
>> Especially with this amazon abuse cloud, how can you report abuse,
>> they want to have an ip address to be able to investigate if
>> something
>
>> originated from their network.
>>
>> If you log 0/24 you might as well log no range at all.
>>
>> Am 30.11.20 um 11:12 schrieb Marc Roos:
>>> Are newer version of bind still logging like this
>>>
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses
>>> to
>>> 3.9.41.0/24
>>> Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses
>>> to
>>> 35.177.154.0/24
>>> Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit responses
>>> to
>>> 3.9.41.0/24
>>>
>>> I already reported, that it is not to smart to log 3.9.41.0/24,
>>> better
>>
>>> could be logged 3.9.41.100/24 so you know the offending ip
>>
>> there is nothing like an "offending ip" in case of dns-amplification
>> which is usually what happens in context of RRL
>>
>> it's the forged destination of the attack you see and nothing else
___
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
