PPA for Raspbian distros
Greetings. Per chance, is there a repo of pre-built bind code for the Raspberry Pi platform? I tried using the PPA specified at https://launchpad.net/~isc/+archive/ubuntu/bind but it didn't support the release on my DNS server host (buster). I received the error Ign:2 https://ppa.launchpadcontent.net/isc/bind/ubuntu buster InRelease Err:3 https://ppa.launchpadcontent.net/isc/bind/ubuntu buster Release 404 Not Found [IP: 185.125.190.52 443] Hit:4 http://archive.raspberrypi.org/debian buster InRelease Reading package lists... Done E: The repository 'https://ppa.launchpadcontent.net/isc/bind/ubuntu buster Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. If I have to compile from source, so be it, but it would be far more convenient to get a binary build from the authority. Andrew Pavlin -- 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: latency and response time
Personally, I would consider response time to be the duration between the
arrival of a request at the DNS server and when the server spits the response
for the request out its local network interface, and latency to be the
additional time the request and response spend traversing the network between
the client and server.
So what the client sees is the sum of response_time + (2 * latency) {making the
somewhat arbitrary assumption that the latency is the same in both directions,
which isn't really valid just because of the different sizes of the request and
response, potentially exacerbated by network links on the path with
asymmetrical baud rates}.
Just my $.02 (or whatever your local currency is).
Andrew Pavlin
ka2ddo.org
From: bind-users on behalf of Matus UHLAR -
fantomas
Sent: Tuesday, June 27, 2023 12:54:09 PM
On 27.06.23 16:22, sami.ra...@sofrecom.com wrote:
>Hello In DNS benchmarking which is more important latency or response
> time? for a DNS server what is the difference between the two values?
I don't see any difference between those two.
--
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.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
--
--
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
How to selectively skip DNSSEC validation?
Greetings, all.
I'm having an odd problem, and I can't seem to figure out how to get Bind to
behave the way I need it to.
I have a computer with a caching-only Bind instance (version
9.11.24-RedHat-9.11.24-2.fc32), which is used both to access the regular
Internet and to access the Amateur Radio Emergency Data Network (AREDN). AREDN
is an RF intranet, and it has its own instance of name servers, which do not
use encryption (as this is prohibited by national and international amateur
radio laws and regulations). As such, I tried to add forwarding entries for the
top-level domains in AREDN to my /etc/named.conf file as follows:
zone "mesh." IN {
type forward;
delegation-only no;
forward only;
forwarders { 192.168.0.7; };
};
zone "local.mesh." IN {
type forward;
delegation-only no;
forward only;
forwarders { 192.168.0.7; };
};
zone "10.in-addr.arpa." IN {
type forward;
forward only;
forwarders { 192.168.0.7; };
};
The options section of the file specifies
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
Note that 192.168.0.7 is my local LAN address for my AREDN node (which includes
DNS service on standard port 53).
However, whenever I try to do a lookup of an AREDN mesh domain name, it
properly forwards to the AREDN node for service, and then complains to syslog:
Dec 7 14:54:39 server named[207007]: no valid RRSIG resolving
'aa3e-southwest-230.local.mesh/DS/IN': 192.168.0.7#53
Dec 7 14:54:39 server named[207007]: no valid DS resolving
'aa3e-southwest-230.local.mesh/A/IN': 192.168.0.7#53
and returns a SERVFAIL error to the client.
If I use nslookup directly to the AREDN node, the lookup succeeds. But this
won't work for a system that needs arbitrary applications (such as web
browsers) to look up both Internet and AREDN names.
I have confirmed that neither the global Internet servers nor the AREDN
intranet servers have RRSIG or DS records for the mesh or local.mesh domains.
And lookups of Internet domain names (or even my non-secured local private
subnet zones) still works successfully.
So, how can I configure Bind to skip the DNSSEC checks _only_ when going to the
specific AREDN server, or, alternatively, only for the zones mentioned above?
Either method would be acceptable; ideal would be to restrict it to the
intersection of both server and zones. Given the number of criminals and
identity thieves on the Internet, I can't just turn off DNSSEC checks globally.
And I can't use separate computers with separate Bind instances because I need
to be able to selectively relay traffic between the Internet and AREDN.
The use of "delegation-only no;" in the above zone definitions was an attempt
to work around the problem, but it didn't change the behavior over not having
the option there. The version of Bind I am using does not permit putting the
"dnssec-enable" and "dnssec-validation" options inside a zone definition.
I look forward to your advice in this matter.
Andrew Pavlin, KA2DDO
member, Amateur Radio Emergency Service
___
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
How does query denial actually work?
Greetings, all. I was curious about one of the features in BIND. Per the Best Practices, my on-site primary nameserver for my public domains (the secondaries being with a large public DNS provider) is configured to only allow queries from within my LAN and transfers in the LAN and to the designated servers at the DNS provider, and the zones don't actually list the primary in NS records (only in the SOA record). So I'm seeing large numbers of bursts of denied errors like this: client @0x6e702710 73.61.186.10#21509 (.): query (cache) './ANY/IN' denied I'll get maybe 20 in a row in under 2 seconds from one IP address, then a time gap, then a similar burst supposedly from a different IP address. So, my questions are: 1. Are these attacks? 2. Does BIND actually send a reject message back, or is it silent in such denial cases (as in, not still attacking with smaller packets the victim of a DNS amplication attack)? I can't figure it out from reading the source code; I haven't so far been able to trace back from where the messages are logged to where (if any) a response packet would be transmitted. Andrew ___ 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 Record Server Availability
Isn't this sort of dynamic functionality (real-time presence or absence of SRV records) what mDNS and the avahi daemon are for? From: bind-users on behalf of Matus UHLAR - fantomas Sent: Wednesday, January 6, 2021 8:51 AM To: bind-users@lists.isc.org Subject: Re: SRV Record Server Availability On 06.01.21 21:41, Wilfred Sarmiento via bind-users wrote: >Your understanding is correct, i just thought that SRV can detect whose >server is alive so it can choose and provide an answer with the available >Server. DNS is not designed to provide this functionality. While technically you can change contents of DNS depending on which servers are alive and which are not, it's almost never a good idea. That means, BIND has nothing like this built in. >> On Tue, Jan 5, 2021 at 4:30 AM Wilfred Sarmiento via bind-users >> wrote: >> > Is DNS Bind SRV record can detect the Server's availability? If yes, how? >On Tue, 5 Jan 2021, 23:53 tale wrote: >> Could you provide more information about your goal? I don't fully >> understand the question. >> >> For my reading, the answer is basically no, in that an SRV record just >> provides data about where.a particular service can be found. It's up >> to other systems to fetch that data and interpret it, including >> whether that service is actually available at the given endpoint. In >> its typical operation, BIND will just take whatever name and port the >> zone administrator said to provide for that SRV record, and not do any >> sort of availability checks on it. >> >> However, if you go deep into a far more complicated, custom use of >> BIND, you could set up a process that monitors the availability and >> changes the SRV record accordingly. -- 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. Microsoft dick is soft to do no harm ___ 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: Millions of './ANY/IN' queries denied
So why isn't there a way to tell BIND not to respond to queries for which it clearly is not authoritative (such as these attack vectors)? Since no legitimate resolver would be asking a non-authoritative server for information, why should his (or my) public BIND server respond to these even with an error message? From: bind-users on behalf of Ondřej Surý Sent: Wednesday, December 15, 2021 7:18 AM To: Danilo Godec Cc: bind-users@lists.isc.org Subject: Re: Millions of './ANY/IN' queries denied > Would I be doing a bad thing by using fail2ban to block these IPs? That’s the question that only you can answer. The IP addresses are not attacker’s but victim’s and you would be punishing those networks by blocking access from them to your network. Do you absolutely know that these IP addresses doesn’t need access to your DNS? If yes, then go ahead. Ondrej -- Ondřej Surý (He/Him) ond...@isc.org > On 15. 12. 2021, at 12:51, Danilo Godec via bind-users > wrote: > > Hello, > > > I'm noticing some unusual activity where 48 external IPs generated over > 2M queries that have all been denied (just today): > > 15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0 > 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied > 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20 > 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied > 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20 > 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied > 15-Dec-2021 00:01:42.023 security: info: client @0x7f9618019e20 > 194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied > 15-Dec-2021 00:01:42.123 security: info: client @0x7f9618019e20 > 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied > 15-Dec-2021 00:01:42.127 security: info: client @0x7f96180b3fe0 > 45.145.227.33#11092 (.): view outside: query (cache) './ANY/IN' denied > > > I'm guessing this is some sort of an reflection attack attempt, but I > don't quite understand if these are the perpetrators or victims? > > Would I be doing a bad thing by using fail2ban to block these IPs? > > > Regards, > > Danilo > > > ___ > 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 ___ 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: Millions of './ANY/IN' queries denied
Sorry about forgetting to post the list. I hit Reply instead of Reply All. Annoying inconsistent list servers You don't understand what kind of blacklist I want; I want to blacklist the domain name being asked for, so I don't answer for it. I'm not looking to blacklist forged IP addresses of requestors (since we all know criminals don't use their own identities; they use the identities of innocent bystanders). Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not a rootserver, and never will be. From: bind-users on behalf of Reindl Harald Sent: Thursday, December 16, 2021 8:14 AM To: bind-users@lists.isc.org Subject: Re: Millions of './ANY/IN' queries denied Am 16.12.21 um 14:04 schrieb Andrew P.: > So you're claiming that legitimate resolvers would still be pointing at the > wrong IP address for a public DNS server after over 16 years? besides that i don't know why you are answering off-list nowhere did i say anything about 16 years but it can take time just because some IP is asking for a domain you don't host is for sure not a justification for automated blacklisting - that will happen regulary after domain-transfers for some time > And asking repeatedly and rapidly for the same illegal root domain name in > synchronized bursts of 10 queries supposedly from 10 different IP addresses? that's what "Response Rate Limiting" is for > I say that because I have held the particular static IPv4 address that my > nameserver is running on for that long, and I have never run a root > nameserver of any sort, or hosted domains for anyone but myself. fine, that's *your* case - we host 800 domains and all the time some get transferred to us and some get away > I agree with the concept of a blacklist i don't because the IP is in most cases FORGED > how do I set up one on my copy of bind so I can refuse to answer those > obvious DNS DDoS attacks? While still answering legitimate requests for the > domains I do hosts, that is. "Response Rate Limiting" again: the IP you mostly see is FORGED and the victim not the attacker and all you do is blacklisting the innocent victim which never did anything bad with automated blacklisting you expose yourself to a simple DOS attack - when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i take your domain offline for anybody on the planet using the google resolvers and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP resolvers for endusers - game over, you blacklisted the world > > From: bind-users on behalf of Reindl > Harald > Sent: Wednesday, December 15, 2021 8:44 AM > To: bind-users@lists.isc.org > Subject: Re: Millions of './ANY/IN' queries denied > > > > Am 15.12.21 um 14:33 schrieb Andrew P.: >> So why isn't there a way to tell BIND not to respond to queries for which it >> clearly is not authoritative (such as these attack vectors)? Since no >> legitimate resolver would be asking a non-authoritative server for >> information, why should his (or my) public BIND server respond to these even >> with an error message? > > because in case of UDP it would make things much worser > > how do the client smell that you didn't respond by purpose and distinct > it from packet loss leading to retries? > > -- > > "Since no legitimate resolver would be asking a non authoritative server > for information" isn't true at all > > years ago we moved a server to a different location and all sorts of ISP > resolvers did respond with old IPs months later, the dumbest one even > played lottery responding 50% old and 50% new IP > > i found that out by random complaints because one domain had 60 count > subdomains and started to query all open rsolvers i was able to find > with script's - a tragedy > > that machine was sadly the primary NS for 800 domains and over the > months the old ip could have been ru-used for a new customer running a > nameserver for completly different domains > > -- > > long story short: no sane service should supress replies completly > unless a explicit blacklist saying so is involved > >> >> From: bind-users on behalf of Ondřej Surý >> >> Sent: Wednesday, December 15, 2021 7:18 AM >> To: Danilo Godec >> Cc: bind-users@lists.isc.org >> Subject: Re: Millions of './ANY/IN' queries denied >> >>> Would I be doing a bad thing by using fail2ban to block these IPs? >> >> That’s the question that only you can answer. The IP addresses are >&
Re: Millions of './ANY/IN' queries denied
Reindl Harald writes: Am 16.12.21 um 14:22 schrieb Andrew P.: >> You don't understand what kind of blacklist I want; I want to blacklist the >> domain name >> being asked for, so I don't answer for it. I'm not looking to blacklist >> forged IP addresses >> of requestors (since we all know criminals don't use their own identities; >> they use the >> identities of innocent bystanders). >> >> Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am >> not a rootserver, and never will be. > >AGAIN: you don't gain anything by not responding on a UDP protocol >because the client can't distinct no response and packet loss AGAIN, the criminal DDoS attacker who's creating these forged requests isn't looking for replies to themselves; they're looking to abuse some poor victim. And the victim can't make the attacker shut up. >so you *increase* the load by retries on the client No, the attacker is going to send their packets as often as they feel like it regardless of whether I answer, and they won't know if the load on the victim is sufficient to crush them (or if I am participating), since the attacker isn't receiving the attack. They won't speed up on me just because I refuse to participate in their ugly little games because they won't know I'm not playing along (at least until they decide to attack _me_ instead of someone else). >don't get me wrong but you need to understand the implications of what >you are doing - for DOS attacks "Response Rate Limiting" was invented >and for non-DOS requests there isn't any valid reason to take action Please tell me what non-DOS requests would be asking _my_ name server to dump the root domain. I'm not running a caching-only public nameserver (such as an ISP might run for their customers), so _no_ _one_ should be asking my nameserver for the entire root domain. Even webcrawlers don't need to harrass non-root-nameservers for root domain information. Note I haven't done anything yet; I'm asking if there _is_ a way to do it presently implemented in Bind. ___ 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: Millions of './ANY/IN' queries denied
Reindl Harald writes: >Am 16.12.21 um 14:56 schrieb Andrew P.: >> Reindl Harald writes: >> Am 16.12.21 um 14:22 schrieb Andrew P.: >>>> You don't understand what kind of blacklist I want; I want to blacklist >>>> the domain name >>>> being asked for, so I don't answer for it. I'm not looking to blacklist >>>> forged IP addresses >>>> of requestors (since we all know criminals don't use their own identities; >>>> they use the >>>> identities of innocent bystanders). >>>> >>>> Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am >>>> not a rootserver, and never will be. >>> >>> AGAIN: you don't gain anything by not responding on a UDP protocol >>> because the client can't distinct no response and packet loss >> >> AGAIN, the criminal DDoS attacker who's creating these forged requests isn't >> looking for replies to themselves > >but a legit client does while these attacks aren't successful at all And you still haven't told me who would be a legitimate client making that request for the root domain from my nameserver. Frankly, I can't think of _anyone_ who should be making that request of my nameserver. Sure, it's a legitimate request to make of someone's first-hop ISP-provided caching-only nameserver, or of a root nameserver. But not against _my_ nameserver. Or are you claiming there is DNS spoofing out there identifying legitimate name servers as authoritative for domains they are not actually authoritative for? Seems like a rather useless form of DNS spoofing, when such attackers could more usefully (to them) direct victims to nameservers under the attacker's control. >> they're looking to abuse some poor victim. And the victim can't make the >> attacker shut up > >this attacker must be pretty dumb then because the ANY request makes >only sense if it get answered and the response is magnitudes larger then >the request Not if the attacker has a huge bot-net to make the requests. He doesn't care how much of the bots' network capacity is used up, since the attacker isn't paying for it. And, based on the same philosophy as spam, if they hit enough name servers, some of them will be insecure and provide the full response, while even those who only send an error packet still need to have that packet consumed at the victim. >hence you need to send them to a server giving a full answer to the victim No, not if you get enough error responses, it will still work. It just takes more. >with just a error response he could send it's attack traffic directly >given that the attacker needs the full bandwidth anyways and not using a >valid DNS request, just blow out traffic to UDP 53 And why should the attacker give away the location of all his bots, when he can get all these legitimate nameservers to take the blame? >one couldn't care less about attackers which don't know what they are doing I suspect they do know what they are doing, or they wouldn't be wasting their time doing it. ___ 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
Why did my DNS bill go up?
Greetings, all. I had a surprise on the bill from my secondary DNS provider after I turned on DNSSEC. The number of record queries on my domains increased by a factor of about 5, compared to the number of record queries when I didn't have DNSSEC. Is this normal for DNSSEC? It's been a consistent significantly higher query level since deploying DNSSEC 3 months ago on 2 small domains (total of 120 records across the two domains), and it was 57 new RRSIG, DNSKEY, and NSEC3PARAM records added the domains for the DNSSEC. The average number of attacks per day on my webserver (according to the server logs) does not appear to have increased since the DNSSEC deployment. This is for the ka2ddo.org and ka2ddo.radio domains. So, is DNSSEC really that much more costly in terms of queries? Andrew Pavlin -- 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
