From anandb at ripe.net Mon Aug 3 09:54:38 2020 From: anandb at ripe.net (Anand Buddhdev) Date: Mon, 3 Aug 2020 11:54:38 +0200 Subject: [SUSPECT EMAIL: No Reputation] Re: unbound API and authenticated data In-Reply-To: References: <37f2d829-f034-db3d-d49c-dd9a859607b3@nlnetlabs.nl> <4d8c930b-1c4d-bf98-2016-99340a5709a5@nlnetlabs.nl>

Message-ID: <7b3dd95d-eb5a-98be-3717-cd10dbe2f8c5@ripe.net> Hello Anthony, On 22 July, George very clearly wrote to you: "However cloudflare.net is a DNSSEC signed domain, whereas google.com is not." Your log file below also shows unbound resolving "www.google.com", getting an answer, and saying that it's not secure. All of this is consistent, because "google.com" is NOT a signed domain. So what's the problem? Regards, Anand On 01/08/2020 01:59, Modster, Anthony via Unbound-users wrote: > Hello George > > I setup forwarding to 8.8.8.8. > The unbound API still indicates the resolve is not secure. > My root.key is from iana. > > What should I check ? > > test-unbound main start [snip] > libunboundclient:[31179]: ResolveURL IP address 74.125.138.104 (domain name=www.google.com). > libunboundclient:[31179]: ResolveURL result is insecure (IP address 74.125.138.104, domain name=www.google.com). > main resolve www.google.com 74.125.138.104 (cnt 1). > UnboundStop stopping unbound (unbound pid 31193). > test-unbound main end From Anthony.Modster at Teledyne.com Mon Aug 3 17:10:08 2020 From: Anthony.Modster at Teledyne.com (Modster, Anthony) Date: Mon, 3 Aug 2020 17:10:08 +0000 Subject: [SUSPECT EMAIL: No Reputation] Re: unbound API and authenticated data In-Reply-To: <7b3dd95d-eb5a-98be-3717-cd10dbe2f8c5@ripe.net> References: <37f2d829-f034-db3d-d49c-dd9a859607b3@nlnetlabs.nl> <4d8c930b-1c4d-bf98-2016-99340a5709a5@nlnetlabs.nl>

<7b3dd95d-eb5a-98be-3717-cd10dbe2f8c5@ripe.net> Message-ID: Sorry I mist that, no problem for this item. -----Original Message----- From: Anand Buddhdev Sent: Monday, August 3, 2020 2:55 AM To: Modster, Anthony Cc: unbound-users at lists.nlnetlabs.nl Subject: Re: [SUSPECT EMAIL: No Reputation] Re: unbound API and authenticated data ---External Email--- Hello Anthony, On 22 July, George very clearly wrote to you: "However cloudflare.net is a DNSSEC signed domain, whereas google.com is not." Your log file below also shows unbound resolving "www.google.com", getting an answer, and saying that it's not secure. All of this is consistent, because "google.com" is NOT a signed domain. So what's the problem? Regards, Anand On 01/08/2020 01:59, Modster, Anthony via Unbound-users wrote: > Hello George > > I setup forwarding to 8.8.8.8. > The unbound API still indicates the resolve is not secure. > My root.key is from iana. > > What should I check ? > > test-unbound main start [snip] > libunboundclient:[31179]: ResolveURL IP address 74.125.138.104 (domain name=www.google.com). > libunboundclient:[31179]: ResolveURL result is insecure (IP address 74.125.138.104, domain name=www.google.com). > main resolve www.google.com 74.125.138.104 (cnt 1). > UnboundStop stopping unbound (unbound pid 31193). > test-unbound main end From c.kelinski at emetriq.com Wed Aug 5 09:41:18 2020 From: c.kelinski at emetriq.com (Christian Kelinski) Date: Wed, 5 Aug 2020 09:41:18 +0000 Subject: Ubuntu 18.04, unboud 1.6.7 and python module Message-ID: Hi, we have a unbound python modul up and running which resolves Hostnames like ip-1-2-3-4.some.domain to 1.2.3.4. Currently our environment is Ubuntu 16.04 and unbound 1.5.8. Since Ubuntu 16.04 is EOL in some months I want to update our Servers to Ubuntu 18.04. But the module is not working anymore. First it seems that accessing qstate.qinfo.qname_str in operate() doesn't work. I get an error: error: pythonmod: Exception occurred in function operate, event: module_event_moddone No big deal since the info could be retrieved from qstate.qinfo.qname_list But when calling msg.set_return_msg(qstate) with a DNSMessage Object which has the answer appended it always fails (and unbound returns SERVFAIL). I compiled the documentation for unbound 1.6.7 and tried the "Response generation" example without luck. I both tried python2 and python3 with same results. With some small modifications I got the module up and running with Ubuntu 20.04 which ships with unbound 1.9.4. This modified version also works with Ubuntu 18.04 and a from source compiled unbound 1.11.0. I attached the module to this E-Mail. Doing a "dig I seems I'm missing something since - based on the documentation - I doing it okay __ Has someone experienced something similar with Ubuntu 18.04/unbound 1.6.7? Thanks in advance and thanks for creating such a lovely software! Christian [https://www.emetriq.com] [https://www.emetriq.com] Whitepaper, Analysen & Reports rund um Data-driven Advertising gibt es auch im monatlichen E-Mail-Newsletter emetriq Data Update . [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] emetriq GmbH Vorsetzen 35 20459 Hamburg Sitz der Gesellschaft: Bonn Handelsregister: AG Bonn, HRB 20117 Gesch?ftsf?hrer: Claas Voigt, Stephan J?ckel ________________________________ Wir sind Mitglied im BVDW (Bundesverband Digitale Wirtschaft) ________________________________ Datenschutz ist emetriq sehr wichtig. Weitere Informationen finden Sie in unseren Datenschutzhinweisen unter www.emetriq.com/datenschutz . This e-mail is confidential and is intended for the addressee(s) only. If you are not the named addressee you may not use it, copy it or disclose it to any other person. If you received this message in error please notify the sender immediately. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unbound-module.txt URL: From wouter at nlnetlabs.nl Wed Aug 5 10:35:07 2020 From: wouter at nlnetlabs.nl (Wouter Wijngaards) Date: Wed, 5 Aug 2020 12:35:07 +0200 Subject: Ubuntu 18.04, unboud 1.6.7 and python module In-Reply-To: References: Message-ID: Hi Christian, If I try this with the latest version from the code repository, I can make it work just fine. I guess it would also work with unbound 1.11.0. It turns out to work just fine with qname_str=qstate.qinfo.qname_str Also the qnamelisttostr can work with ".".join. The python_script variable has changed to a config_strlist in the newer releases, and thus I included something to print that correctly. The list for that python_script config parameter means you can load multiple python scripts by having more than one python-script: "file" line in the config file, and in that order, having more than one "python" element in the module-config list of modules. For here, it is only a type change and the script is easily fixed to print that right. Or print env.cfg.python_script.str the first element in the list. Perhaps these issues are already fixed as part of Python-3 related fixes in the code base. Here is the changes: --- test2.py.orig 2020-08-05 12:06:38.739887060 +0200 +++ test2.py 2020-08-05 12:25:21.826634657 +0200 @@ -4,13 +4,17 @@ debugModule = True def qnameListToStr( qname_list ): - qname_list_decode = list() - for l in qname_list: - qname_list_decode.append( l.decode('utf-8') ) - return ".".join( qname_list_decode ) + return ".".join(qname_list) + +def strlisttostr( str_list ): + thelist = list() + while str_list is not None: + thelist.append(str_list.str) + str_list = str_list.next + return " ".join( thelist ) def init_standard(id, env): - log_info("aws-hostnames: init called, module id is %d port: %d script: %s verbosity: %s" % (id, env.cfg.port, env.cfg.python_script, env.cfg.verbosity)) + log_info("aws-hostnames: init called, module id is %d port: %d script: %s verbosity: %s" % (id, env.cfg.port, strlisttostr(env.cfg.python_script), env.cfg.verbosity)) # Build pattern for checking, pattern matches everything like # ip-[0-9]-[0-9]-[0-9]-[0-9].domain.name @@ -39,6 +43,7 @@ return True elif event == MODULE_EVENT_MODDONE: + #qname_str = qstate.qinfo.qname_str qname_str = qnameListToStr(qstate.qinfo.qname_list) log_info("python: MODDONE with rcode '%s' and priming '%s' and query '%s' of type '%s'" % ( qstate.return_rcode, qstate.is_priming, qname_str, qstate.qinfo.qtype_str Best regards, Wouter On 05/08/2020 11:41, Christian Kelinski via Unbound-users wrote: > Hi, > > we have a unbound python modul up and running which resolves Hostnames like ip-1-2-3-4.some.domain to 1.2.3.4. Currently our environment is Ubuntu 16.04 and unbound 1.5.8. > > Since Ubuntu 16.04 is EOL in some months I want to update our Servers to Ubuntu 18.04. But the module is not working anymore. > > First it seems that accessing qstate.qinfo.qname_str in operate() doesn't work. I get an error: > error: pythonmod: Exception occurred in function operate, event: module_event_moddone > > No big deal since the info could be retrieved from qstate.qinfo.qname_list > > But when calling msg.set_return_msg(qstate) with a DNSMessage Object which has the answer appended it always fails (and unbound returns SERVFAIL). I compiled the documentation for unbound 1.6.7 and tried the "Response generation" example without luck. > > I both tried python2 and python3 with same results. > > With some small modifications I got the module up and running with Ubuntu 20.04 which ships with unbound 1.9.4. This modified version also works with Ubuntu 18.04 and a from source compiled unbound 1.11.0. > > I attached the module to this E-Mail. Doing a "dig > > I seems I'm missing something since - based on the documentation - I doing it okay __ Has someone experienced something similar with Ubuntu 18.04/unbound 1.6.7? > > Thanks in advance and thanks for creating such a lovely software! > Christian > > > [https://www.emetriq.com] > > [https://www.emetriq.com] > > Whitepaper, Analysen & Reports rund um Data-driven Advertising gibt es auch im monatlichen E-Mail-Newsletter emetriq Data Update . > > [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] > > emetriq GmbH > Vorsetzen 35 > 20459 Hamburg > > Sitz der Gesellschaft: Bonn > Handelsregister: AG Bonn, HRB 20117 > Gesch?ftsf?hrer: Claas Voigt, Stephan J?ckel > ________________________________ > Wir sind Mitglied im BVDW (Bundesverband Digitale Wirtschaft) > ________________________________ > Datenschutz ist emetriq sehr wichtig. Weitere Informationen finden Sie in unseren Datenschutzhinweisen unter www.emetriq.com/datenschutz . > > This e-mail is confidential and is intended for the addressee(s) only. > If you are not the named addressee you may not use it, copy it or > disclose it to any other person. If you received this message in error > please notify the sender immediately. > From sca at andreasschulze.de Thu Aug 6 22:25:52 2020 From: sca at andreasschulze.de (A. Schulze) Date: Fri, 7 Aug 2020 00:25:52 +0200 Subject: rpz question Message-ID: <890dd496-76d4-5b16-3f76-134066b1a459@andreasschulze.de> Hello, I thought I could build a resolver allow only a limited set of domains to resolve. That set of allowed domains should come from an rpz. unbound.conf: server: module-config: "respip validator iterator" rpz: name: "allow-rpz.example." zonefile: "/tmp/allow-rpz.example" /tmp/allow-rpz.example: allow-rpz.example. SOA localhost. rpz.localhost. 1 43200 7200 2419200 3600 allow-rpz.example. NS localhost. *.allow-rpz.example. CNAME . com.allow-rpz.example. CNAME . de.allow-rpz.example. CNAME rpz-passthru. expectation: QNAME=com will be answered with NXDOMAIN QNAME=de will be answered with real data QNAME=net/org/anything will be answered with NXDOMAIN result: QNAME=com is answered with NXDOMAIN QNAME=de is answered with real data QNAME=net/org/anything is answered with real data reading https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00#section-4.2 let me believe, *.allow-rpz.example. would match any subdomain of "." looks like unbound/RPZ don't think so. Is this a bug, a feature or simply not possible (why?) with unbound's RPZ implementation? Are there other ways to build such a system? Andreas From jkomissa at cisco.com Fri Aug 7 13:17:09 2020 From: jkomissa at cisco.com (Jan Komissar (jkomissa)) Date: Fri, 7 Aug 2020 13:17:09 +0000 Subject: rpz question In-Reply-To: <890dd496-76d4-5b16-3f76-134066b1a459@andreasschulze.de> References: <890dd496-76d4-5b16-3f76-134066b1a459@andreasschulze.de> Message-ID: Hi Andreas, I think you need to add *.com.allow-rpz.example. CNAME . *.de.allow-rpz.example. CNAME rpz-passthru. to the rpz. Jan. ?On 8/6/20, 6:27 PM, "Unbound-users on behalf of A. Schulze via Unbound-users" wrote: Hello, I thought I could build a resolver allow only a limited set of domains to resolve. That set of allowed domains should come from an rpz. unbound.conf: server: module-config: "respip validator iterator" rpz: name: "allow-rpz.example." zonefile: "/tmp/allow-rpz.example" /tmp/allow-rpz.example: allow-rpz.example. SOA localhost. rpz.localhost. 1 43200 7200 2419200 3600 allow-rpz.example. NS localhost. *.allow-rpz.example. CNAME . com.allow-rpz.example. CNAME . de.allow-rpz.example. CNAME rpz-passthru. expectation: QNAME=com will be answered with NXDOMAIN QNAME=de will be answered with real data QNAME=net/org/anything will be answered with NXDOMAIN result: QNAME=com is answered with NXDOMAIN QNAME=de is answered with real data QNAME=net/org/anything is answered with real data reading https://tools.ietf.org/html/draft-ietf-dnsop-dns-rpz-00#section-4.2 let me believe, *.allow-rpz.example. would match any subdomain of "." looks like unbound/RPZ don't think so. Is this a bug, a feature or simply not possible (why?) with unbound's RPZ implementation? Are there other ways to build such a system? Andreas From rgsub1 at btinternet.com Sat Aug 8 15:42:59 2020 From: rgsub1 at btinternet.com (RayG) Date: Sat, 8 Aug 2020 16:42:59 +0100 Subject: No Network problem - Running Unbound on Windows 10 V2004 Message-ID: Hi, Since the Windows 10 V2004 update has been out and about, every time I have upgraded a system I have had issues with the networking. Windows thought that it was not connected to the internet. The little system tray icon always showed the little world icon (as I call it) to say no internet access. I could never get it to show the little TV screen icon to say networking was up and running and the internet was fully accessible. I was made aware of this issue: https://www.bleepingcomputer.com/news/microsoft/windows-10-hosts-file-blocki ng-telemetry-is-now-flagged-as-a-risk/ where blocking MS telemetry IP addresses (DNS Names) via the hosts file would cause Windows Defender to complain that the hosts file had been "infected" and would return it to defaults depending on how you answered Defenders prompt. This apparently has been the case sine the end of July. This got me thinking and I have now upgraded my desktop to V2004 again and low and behold - networking issues. I use Macrium Reflect as backup software and that allows me to take a backup and then convert that into a VM. I did this and then played with the Unbound configuration. What I found was: Any reference to 127.0.0.x or ::1 for DNS entries in the Adapter configuration causes the networking to fail to detect internet access is available. I don't know if this is intentional on MS's behalf or a bug - time will perhaps tell. That said, if I changed the Adapter configuration so that it pointed to the IPV4 and IPV6 address the IPCONFIG /ALL IPv6 Address. . . . . . . . . . . : :x:x:x:x(Preferred) IPv4 Address. . . . . . . . . . . : x.x.x.x(Preferred) For the DNS server entries then the networking worked correctly if I also set the "interface:" and "access_control" definitions in the unbound configuration file to the same addresses interface: :x:x:x:x interface: x.x.x.x & access_control: :x:x:x:x allow_snoop access_control: x.x.x.x allow_snoop I also commented out the references to 127.0.0.0/8 and ::1 I don't know if anyone else is having these issues but hopefully the above will help. I would also be VERY interested if nlnetlabs have come across this issue and how they have resolved it and if indeed it happens on anyone else's system(s). RayG -------------- next part -------------- An HTML attachment was scrubbed... URL: From sca at andreasschulze.de Sat Aug 8 20:24:48 2020 From: sca at andreasschulze.de (A. Schulze) Date: Sat, 8 Aug 2020 22:24:48 +0200 Subject: rpz question In-Reply-To: References: <890dd496-76d4-5b16-3f76-134066b1a459@andreasschulze.de> Message-ID: <1d39bf94-41bc-d773-b32d-6efb2c170948@andreasschulze.de> Am 07.08.20 um 15:17 schrieb Jan Komissar (jkomissa): > I think you need to add > *.com.allow-rpz.example. CNAME . > *.de.allow-rpz.example. CNAME rpz-passthru. > to the rpz. > expectation: > QNAME=net/org/anything will be answered with NXDOMAIN I don't see how adding *.com / *.de will help on the expectation Andreas From rgsub1 at btinternet.com Tue Aug 11 16:00:41 2020 From: rgsub1 at btinternet.com (RayG) Date: Tue, 11 Aug 2020 17:00:41 +0100 Subject: [Resolved] (for now) No Network problem - Running Unbound on Windows 10 V2004 Message-ID: Since writing up the issue below I have updated two systems and after a lot of experiments I have found that the best way to resolve this issue (at the moment) is in the following way: You can set up the interface statements to use your actual IP's (IPV4 & IPV6) which is OK if all are static addresses. If you are using DHCP then it is possible the address will change over time. This will certainly be true if you are using a WiFi Laptop to travel. So setting the interface: statements like this would seem to be best. interface: 0.0.0.0 interface: ::0 The access-control: statements now look like this: access-control: 0.0.0.0/0 allow_snoop access-control: 127.0.0.0/8 refuse access-control: ::0/0 allow_snoop access-control: ::1 refuse I have then used an event driven task: Microsoft-Windows-NetworkProfile_Operational_Microsoft-Windows-NetworkProfil e_10000 To run a PowerShell script that then sets the DNS servers for the adapter you want to configure it works for Ethernet and WiFi connections. You can define the name you want to use by renaming the adapter to something that makes it unique and identifiable from any others. I have not yet found a way to actually see which interface the event is derived from as the script only runs when the network interface comes up having it run several time (in my case 3) is not an issue it only sets the DNS addresses for one interface (the same one each time). The IP Addresses to use can be obtained using: $IPV4 = ([string](Get-NetIPAddress -InterfaceAlias $NetworkType).IPV4Address).Trim() $IPV6 = ([string](Get-NetIPAddress -InterfaceAlias $NetworkType -AddressState Preferred -SuffixOrigin Link -PrefixOrigin RouterAdvertisement).IPAddress).Trim() Where $NetworkType is the name of the adapter. You do have to work out a few more bits to set the address but this is essentially what I am doing and so far it is working OK. I know the system is not using other methods (as far as I can tell) to obtain DNS information as if I stop the Unbound service nothing appears to have network Access when a DNS name needs to be looked up. I hope this helps anyone else who is struggling in this way. I don't know if this is a bug in Microsoft s code see: https://www.bleepingcomputer.com/news/microsoft/microsoft-fixes-no-internet- bug-in-latest-windows-10-dev-build/ That looks like it will be in the next build not V2004 so watch this space. Subject: No Network problem - Running Unbound on Windows 10 V2004 Hi, Since the Windows 10 V2004 update has been out and about, every time I have upgraded a system I have had issues with the networking. Windows thought that it was not connected to the internet. The little system tray icon always showed the little world icon (as I call it) to say no internet access. I could never get it to show the little TV screen icon to say networking was up and running and the internet was fully accessible. I was made aware of this issue: https://www.bleepingcomputer.com/news/microsoft/windows-10-hosts-file-blocki ng-telemetry-is-now-flagged-as-a-risk/ where blocking MS telemetry IP addresses (DNS Names) via the hosts file would cause Windows Defender to complain that the hosts file had been "infected" and would return it to defaults depending on how you answered Defenders prompt. This apparently has been the case sine the end of July. This got me thinking and I have now upgraded my desktop to V2004 again and low and behold - networking issues. I use Macrium Reflect as backup software and that allows me to take a backup and then convert that into a VM. I did this and then played with the Unbound configuration. What I found was: Any reference to 127.0.0.x or ::1 for DNS entries in the Adapter configuration causes the networking to fail to detect internet access is available. I don't know if this is intentional on MS's behalf or a bug - time will perhaps tell. That said, if I changed the Adapter configuration so that it pointed to the IPV4 and IPV6 address the IPCONFIG /ALL IPv6 Address. . . . . . . . . . . : :x:x:x:x(Preferred) IPv4 Address. . . . . . . . . . . : x.x.x.x(Preferred) For the DNS server entries then the networking worked correctly if I also set the "interface:" and "access_control" definitions in the unbound configuration file to the same addresses interface: :x:x:x:x interface: x.x.x.x & access_control: :x:x:x:x allow_snoop access_control: x.x.x.x allow_snoop I also commented out the references to 127.0.0.0/8 and ::1 I don't know if anyone else is having these issues but hopefully the above will help. I would also be VERY interested if nlnetlabs have come across this issue and how they have resolved it and if indeed it happens on anyone else's system(s). RayG -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.kelinski at emetriq.com Thu Aug 13 08:21:10 2020 From: c.kelinski at emetriq.com (Christian Kelinski) Date: Thu, 13 Aug 2020 08:21:10 +0000 Subject: Ubuntu 18.04, unboud 1.6.7 and python module In-Reply-To: References:

Message-ID: <16DF2812-2045-411A-A8D2-CB8033686DAC@emetriq.com> Hi Wouter, thanks for your suggestions which I implemented! I was able to get the script running with a self compiled Ubuntu 1.6.7 (the version used by Ubuntu 18.04) without any problems (with qstate.qinfo.qname_str) so I think the problem is with the Ubuntu 18.04 package. The python-unbound package behaves a bit odd - it installs a python2 module but strace shows unbound is using python3. I opened a bug report @ launchpad.net. Greetings from Hamburg Christian ?Am 05.08.20, 12:35 schrieb "Unbound-users im Auftrag von Wouter Wijngaards via Unbound-users" : Hi Christian, If I try this with the latest version from the code repository, I can make it work just fine. I guess it would also work with unbound 1.11.0. It turns out to work just fine with qname_str=qstate.qinfo.qname_str Also the qnamelisttostr can work with ".".join. The python_script variable has changed to a config_strlist in the newer releases, and thus I included something to print that correctly. The list for that python_script config parameter means you can load multiple python scripts by having more than one python-script: "file" line in the config file, and in that order, having more than one "python" element in the module-config list of modules. For here, it is only a type change and the script is easily fixed to print that right. Or print env.cfg.python_script.str the first element in the list. Perhaps these issues are already fixed as part of Python-3 related fixes in the code base. Here is the changes: --- test2.py.orig 2020-08-05 12:06:38.739887060 +0200 +++ test2.py 2020-08-05 12:25:21.826634657 +0200 @@ -4,13 +4,17 @@ debugModule = True def qnameListToStr( qname_list ): - qname_list_decode = list() - for l in qname_list: - qname_list_decode.append( l.decode('utf-8') ) - return ".".join( qname_list_decode ) + return ".".join(qname_list) + +def strlisttostr( str_list ): + thelist = list() + while str_list is not None: + thelist.append(str_list.str) + str_list = str_list.next + return " ".join( thelist ) def init_standard(id, env): - log_info("aws-hostnames: init called, module id is %d port: %d script: %s verbosity: %s" % (id, env.cfg.port, env.cfg.python_script, env.cfg.verbosity)) + log_info("aws-hostnames: init called, module id is %d port: %d script: %s verbosity: %s" % (id, env.cfg.port, strlisttostr(env.cfg.python_script), env.cfg.verbosity)) # Build pattern for checking, pattern matches everything like # ip-[0-9]-[0-9]-[0-9]-[0-9].domain.name @@ -39,6 +43,7 @@ return True elif event == MODULE_EVENT_MODDONE: + #qname_str = qstate.qinfo.qname_str qname_str = qnameListToStr(qstate.qinfo.qname_list) log_info("python: MODDONE with rcode '%s' and priming '%s' and query '%s' of type '%s'" % ( qstate.return_rcode, qstate.is_priming, qname_str, qstate.qinfo.qtype_str Best regards, Wouter On 05/08/2020 11:41, Christian Kelinski via Unbound-users wrote: > Hi, > > we have a unbound python modul up and running which resolves Hostnames like ip-1-2-3-4.some.domain to 1.2.3.4. Currently our environment is Ubuntu 16.04 and unbound 1.5.8. > > Since Ubuntu 16.04 is EOL in some months I want to update our Servers to Ubuntu 18.04. But the module is not working anymore. > > First it seems that accessing qstate.qinfo.qname_str in operate() doesn't work. I get an error: > error: pythonmod: Exception occurred in function operate, event: module_event_moddone > > No big deal since the info could be retrieved from qstate.qinfo.qname_list > > But when calling msg.set_return_msg(qstate) with a DNSMessage Object which has the answer appended it always fails (and unbound returns SERVFAIL). I compiled the documentation for unbound 1.6.7 and tried the "Response generation" example without luck. > > I both tried python2 and python3 with same results. > > With some small modifications I got the module up and running with Ubuntu 20.04 which ships with unbound 1.9.4. This modified version also works with Ubuntu 18.04 and a from source compiled unbound 1.11.0. > > I attached the module to this E-Mail. Doing a "dig > > I seems I'm missing something since - based on the documentation - I doing it okay __ Has someone experienced something similar with Ubuntu 18.04/unbound 1.6.7? > > Thanks in advance and thanks for creating such a lovely software! > Christian > > > [https://www.emetriq.com] > > [https://www.emetriq.com] > > Whitepaper, Analysen & Reports rund um Data-driven Advertising gibt es auch im monatlichen E-Mail-Newsletter emetriq Data Update . > > [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] [https://www.emetriq.com] > > emetriq GmbH > Vorsetzen 35 > 20459 Hamburg > > Sitz der Gesellschaft: Bonn > Handelsregister: AG Bonn, HRB 20117 > Gesch?ftsf?hrer: Claas Voigt, Stephan J?ckel > ________________________________ > Wir sind Mitglied im BVDW (Bundesverband Digitale Wirtschaft) > ________________________________ > Datenschutz ist emetriq sehr wichtig. Weitere Informationen finden Sie in unseren Datenschutzhinweisen unter www.emetriq.com/datenschutz . > > This e-mail is confidential and is intended for the addressee(s) only. > If you are not the named addressee you may not use it, copy it or > disclose it to any other person. If you received this message in error > please notify the sender immediately. > From trashcan at ellael.org Mon Aug 17 19:10:45 2020 From: trashcan at ellael.org (Michael Grimm) Date: Mon, 17 Aug 2020 21:10:45 +0200 Subject: How to stop unbound reporting any statistics? Message-ID: Hi, I do have the following (default) set in unbound.conf: # print statistics to the log (for every thread) every N seconds. # Set to "" or 0 to disable. Default is disabled. statistics-interval: 0 But: Whenever I do stop unbound, a lot of statistics are reported like: : stopping /usr/local/etc/rc.d/unbound unbound[12792]: [12792:0] info: service stopped (unbound 1.10.1). unbound[12792]: [12792:0] info: server stats for thread 0: 1 queries, 0 answers from cache, 1 recursions, 0 prefetch, 0 rejected by ip ratelimiting unbound[12792]: [12792:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 unbound[12792]: [12792:0] info: average recursion processing time 1.667362 sec unbound[12792]: [12792:0] info: histogram of recursion processing times unbound[12792]: [12792:0] info: [25%]=0 median[50%]=0 [75%]=0 unbound[12792]: [12792:0] info: lower(secs) upper(secs) recursions unbound[12792]: [12792:0] info: 0.032768 0.065536 1 unbound[12792]: [12792:0] info: 0.262144 0.524288 2 unbound[12792]: [12792:0] info: 0.524288 1.000000 1 unbound[12792]: [12792:0] info: 4.000000 8.000000 1 ? This takes a very loooong time (recent FreeBSD 12.1-STABLE, unbound version 1.10.1). Sometimes > 10 minutes. How can I tell unbound to forget about that, and just stop right away by omitting those unwanted statistics? Thanks and regards, Michael From listas at esds.com.br Mon Aug 17 21:50:06 2020 From: listas at esds.com.br (Eduardo Schoedler) Date: Mon, 17 Aug 2020 18:50:06 -0300 Subject: How to stop unbound reporting any statistics? In-Reply-To: References: Message-ID: Hi Michael, Em seg., 17 de ago. de 2020 ?s 16:20, Michael Grimm via Unbound-users escreveu: > This takes a very loooong time (recent FreeBSD 12.1-STABLE, unbound version 1.10.1). Sometimes > 10 minutes. Something is wrong, never took >10min for me. Maybe your start/stop script is doing a dump of the cache in a file, for restore later. Try check this. -- Eduardo Schoedler From trashcan at ellael.org Tue Aug 18 19:33:01 2020 From: trashcan at ellael.org (Michael Grimm) Date: Tue, 18 Aug 2020 21:33:01 +0200 Subject: How to stop unbound reporting any statistics? In-Reply-To: References: Message-ID: Hi Eduardo, Eduardo Schoedler wrote: > Em seg., 17 de ago. de 2020 ?s 16:20, Michael Grimm via Unbound-users escreveu: >> This takes a very loooong time (recent FreeBSD 12.1-STABLE, unbound version 1.10.1). Sometimes > 10 minutes. > > Something is wrong, never took >10min for me. > Maybe your start/stop script is doing a dump of the cache in a file, > for restore later. Not to my knowledge, and I just double-checked. It seems to me, that the time needed until final shutdown of the daemon, is needed for evaluation of those statistics. unbound is running within a FreeBSD jail, and logging is forwarded to the host. That might slow down unbound's shutdown. But: I believed that setting "statistics-interval: 0" in unbound.conf would discard statistics completely, but that doesn't seem to be the case. Has anyone else succeeded in discarding statistics in toto? Thanks and regards, Michael From skysan at gmail.com Tue Aug 18 20:01:40 2020 From: skysan at gmail.com (san) Date: Tue, 18 Aug 2020 21:01:40 +0100 Subject: remote control failed ssl crypto error Message-ID: Few weeks back I installed unbound on my arm64 rockpi running ubuntu Linux rockpi 4.4.154-110-rockchip-gcef30e88a9f5 #1 SMP Mon Jun 22 07:37:10 UTC 2020 aarch64 aarch64 aarch64 GNU/Linux the version of unbound is 1.6.7 the service starts but continues to error Aug 18 19:47:34 rockpi systemd[1]: Starting Unbound DNS server... Aug 18 19:47:34 rockpi package-helper[8886]: /var/lib/unbound/root.key has content Aug 18 19:47:34 rockpi package-helper[8886]: success: the anchor is ok Aug 18 19:47:34 rockpi unbound[8890]: [8890:0] info: start of service (unbound 1.6.7). Aug 18 19:47:34 rockpi systemd[1]: Started Unbound DNS server. Aug 18 19:47:45 rockpi unbound[8890]: [8890:0] error: remote control failed ssl crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate Aug 18 19:47:49 rockpi unbound[8890]: [8890:0] error: remote control failed ssl crypto error:1408F09C:SSL routines:ssl3_get_record:http request Aug 18 19:48:00 rockpi unbound[8890]: [8890:0] error: remote control failed ssl crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate please help Best Regards, Sanjeev Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at forgue.io Thu Aug 20 16:43:36 2020 From: andrew at forgue.io (Andrew Forgue) Date: Thu, 20 Aug 2020 09:43:36 -0700 Subject: Unbound strange stub_zone behavior? In-Reply-To: <96CDD284-DBAD-4711-9C04-7E62F468858D@forgue.io> References: <384B6B87-F36D-4DFB-80D0-5ED706132E51@forgue.io> <8d70329e-778a-3ef2-86f0-550be650ab52@gmail.com> <96CDD284-DBAD-4711-9C04-7E62F468858D@forgue.io> Message-ID: > On Jul 14, 2020, at 11:48 AM, Andrew Forgue via Unbound-users wrote: > > > >> On Jul 13, 2020, at 11:55 AM, Jan Komissar (jkomissa) wrote: >> >> Hi Andrew, >> >> I believe that stub-zones will not work correctly for +norecurse (RD (recursion desired) flag unset) queries. Also, if your blah.example.com has delegations to subzones (even on the same server) and you use a non-standard port, you would need a stub-zone for each sub-zone. > > After restarting unbound, non-recursive queries work fine for several days, until they don't (not sure why). My understanding is that stub_zone presents as if it's local data, and the behavior you're describing would be more like the behavior of a forward zone. > >> I would follow Eric's advice to use an auth-zone, either as primary or secondary server (depending on your authoritative requirements). > > Yeah, Thanks Eric & Jan I'll take a look at that, but I'm not sure the "proxied" dns server can do notifies, but seems to be a good lead. Just to bump this again -- here's the progress so far. We've been able to reproduce this with auth_zones too. With my limited knowledge of unbound code and gdb it *appears* that in answer_norec_from_cache: daemon/worker.c:492 (or so): answer_norec_from_cache(...) { ... dp = dns_cache_find_delegation(&worker->env, qinfo->qname, qinfo->qname_len, qinfo->qtype, qinfo->qclass, worker->scratchpad, &msg, timenow); if(!dp) { /* no delegation, need to reprime */ return 0; } in the happy case, `dp` is NULL meaning there's no delegation (so it hits return 0), and the correct answer is returned. In the failure case: `dp` is a delegation point to what looks like the root zones: -- (gdb) p *dp $27 = {name = 0x7f66cc516d58 "", namelen = 1, namelabs = 1, nslist = 0x0, target_list = 0x0, usable_list = 0x0, result_list = 0x0, bogus = 0, has_parent_side_NS = 0 '\000', dp_type_mlc = 0 '\000', ssl_upstream = 0 '\000', auth_dp = 0 '\000', no_cache = 0} -- broken node: dns1 :: ~ ? sudo unbound-control lookup blah.example.com The following name servers are used for lookup of blah.example.com ;rrset 17491 13 1 5 2 . 17491 IN NS c.root-servers.net. . 17491 IN NS d.root-servers.net. . 17491 IN NS j.root-servers.net. . 17491 IN NS e.root-servers.net. . 17491 IN NS l.root-servers.net. . 17491 IN NS h.root-servers.net. . 17491 IN NS f.root-servers.net. . 17491 IN NS k.root-servers.net. . 17491 IN NS m.root-servers.net. . 17491 IN NS i.root-servers.net. . 17491 IN NS a.root-servers.net. . 17491 IN NS g.root-servers.net. . 17491 IN NS b.root-servers.net. . 17491 IN RRSIG NS 8 0 518400 20200827170000 20200814160000 46594 . ZxJeYw7vVyjxZg8y7mtt5N3YtejDrho11npxtnjt7MMZm/MlbSErowznceyvXYhTkgF4dJOFGcrUkwFekcN86Zw0tN+cHYYb4lpV2o/pYtXIzo2w2OtA0WJURMB1pWcclhma9y648OiGUsEwImRXpCQS7Mgk+XKU05KFCg5yrFW+UC4faaQ1ZiisVnK9GF8CwsHCC82xT7HU/pAMFgF2vEovsomysMuDhBKE1QTP9MN/DqD6bitdqGmhQSC9GxxcRrNCCU8fSnW4UVIiOJ95kaEMDk0kdpTGowBcKx2WCbXN8oKGSYRpJjE+y77mc2mv3cBUBwK9jnqB86jXwZ7enA== ;{id = 46594} Delegation with 13 names, of which 13 can be examined to query further addresses. It provides 0 IP addresses. cache delegation was useless (no IP addresses) Any other help finding out how dns_cache_find_delegation returns the root delegations instead of the auth_zone (in this case example.com is the auth zone, with a proper zone file on disk)? -Andrew > > -Andrew > >> Regards, >> >> Jan. >> >> ?On 7/12/20, 12:00 PM, "Unbound-users on behalf of Eric Luehrsen via Unbound-users" wrote: >> >> On 7/11/20 11:49 AM, Andrew Forgue via Unbound-users wrote: >>> I have an unbound server that acts as a recursive resolver for clients and also acts as a target for fully delegated DNS (i.e. unbound is the NS record). For the fully-delegated domain it is a simple stub zone with an upstream of localhost on a different port. Let's call it "blah.example.com". >>> >>> Occasionally, unbound (has happened on versions 1.10.1 and 1.7.3) will start responding to non-recursive queries with the list of root zones instead of a response from the stub-zone. It seems that clients that use the `rd` flag are fine and continue to be able to resolve records in the stub-zone. Only recursive desired clients will receive correct records from unbound (using the stub server). All records in seemingly all stub zones have this behavior simultaneously. >>> >>> I don't know what triggers it, but a full restart of unbound is the only thing that fixes it. I've tried flushing cache, flushing infra, and everything, nothing seems to matter. I've seen only 2 things that may point to the issue. >>> >>> - With verbosity turned up to 10, there's an entry produced in strace (but not in the actual log - maybe a misconfig): "unbound[2213085:5] debug: answer from the cache failed" >>> >>> - stracing the "broken" unbound process is a very tight recvmsg() (of the request) and sendmsg() (with the root servers) with no syscalls in between. >>> >>> Again, Using dig with +recurse works all the time, even when unbound gets in this state. So seems like an unbound bug / cache corruption or something? >> >> If it is a bug, you may want to try a work around while waiting for a >> fix. You could try "auth-zone:" instead of "stub-zone:" or as a >> companion to "stub-zone:" You may need to give the authoritative server >> permission for a wholesale zone transfer to the Unbound instance. This >> may help avoid some undiscovered bug in piecemeal zone recursion. >> - Eric >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomasnetk at gmail.com Wed Aug 26 09:19:29 2020 From: tomasnetk at gmail.com (Tomas Netk) Date: Wed, 26 Aug 2020 12:19:29 +0300 Subject: about Unbound ISP Config Message-ID: Hello, is anyone using Ubound for ISP, and can share config file ? Im new for DNS and I would like to check config to get better understanding. Thank you very much -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernesto.perez at cedia.org.ec Wed Aug 26 13:48:47 2020 From: ernesto.perez at cedia.org.ec (=?UTF-8?B?SW5nLiBFcm5lc3RvIFDDqXJleiBFc3TDqXZleiwgTWcu?=) Date: Wed, 26 Aug 2020 08:48:47 -0500 Subject: about Unbound ISP Config In-Reply-To: References: Message-ID: <64b58e9d-7c0a-8a32-e476-3e18d27ef64d@cedia.org.ec> El 26/8/20 a las 04:19, Tomas Netk via Unbound-users escribi?: > Hello, > is anyone using Ubound for ISP, and can share config file ? Im new?for > DNS and I would like to check config to get better understanding. > > Thank you very much hi there I think that the alternative for an authoritative DNS will be NSD instead of unbound. In my case I have ISPCONFIG for our first DNS (ispconfig+bind), and then rsync every few minutes to my second DNS (the NSD one) and "slightly" transform the configuration from bind to nsd. if you need more details you may write me directly. It is somehow easy. regards EPE -- CEDIA La principal herramienta de Investigaci?n en el Ecuador. Gonzalo Cordero 2-122 y J. Fajardo Cuenca - Ecuador Telf: +593 7 407 9300 Ext. 115 info at cedia.org.ec www.cedia.edu.ec From andrew at forgue.io Wed Aug 26 15:43:31 2020 From: andrew at forgue.io (Andrew Forgue) Date: Wed, 26 Aug 2020 08:43:31 -0700 Subject: Unbound strange stub_zone behavior? In-Reply-To: References: <384B6B87-F36D-4DFB-80D0-5ED706132E51@forgue.io> <8d70329e-778a-3ef2-86f0-550be650ab52@gmail.com> <96CDD284-DBAD-4711-9C04-7E62F468858D@forgue.io> Message-ID: <00FF0485-2B38-462E-9B46-027D727E1A40@forgue.io> Ok, I think we found the issue. First, when a auth_zone is `for-downstream: no` cache is used first. stub_zones seems to behave the same as `for-downstream: no`. Somehow, in our environment, someone is triggering a cache of the root zone NS records for ".", which causes unbound to do a referral to the root zone instead of answering from auth data. I was able to reproduce this by triggering it with `dig -t NS "." @server` More details: https://github.com/NLnetLabs/unbound/issues/292 -Andrew > On Aug 20, 2020, at 9:43 AM, Andrew Forgue wrote: > > > >> On Jul 14, 2020, at 11:48 AM, Andrew Forgue via Unbound-users > wrote: >> >> >> >>> On Jul 13, 2020, at 11:55 AM, Jan Komissar (jkomissa) > wrote: >>> >>> Hi Andrew, >>> >>> I believe that stub-zones will not work correctly for +norecurse (RD (recursion desired) flag unset) queries. Also, if your blah.example.com has delegations to subzones (even on the same server) and you use a non-standard port, you would need a stub-zone for each sub-zone. >> >> After restarting unbound, non-recursive queries work fine for several days, until they don't (not sure why). My understanding is that stub_zone presents as if it's local data, and the behavior you're describing would be more like the behavior of a forward zone. >> >>> I would follow Eric's advice to use an auth-zone, either as primary or secondary server (depending on your authoritative requirements). >> >> Yeah, Thanks Eric & Jan I'll take a look at that, but I'm not sure the "proxied" dns server can do notifies, but seems to be a good lead. > > Just to bump this again -- here's the progress so far. We've been able to reproduce this with auth_zones too. > > With my limited knowledge of unbound code and gdb it *appears* that in answer_norec_from_cache: > > daemon/worker.c:492 (or so): > > answer_norec_from_cache(...) { > ... > dp = dns_cache_find_delegation(&worker->env, qinfo->qname, > qinfo->qname_len, qinfo->qtype, qinfo->qclass, > worker->scratchpad, &msg, timenow); > if(!dp) { /* no delegation, need to reprime */ > return 0; > } > > in the happy case, `dp` is NULL meaning there's no delegation (so it hits return 0), and the correct answer is returned. > > In the failure case: `dp` is a delegation point to what looks like the root zones: > > -- > (gdb) p *dp > $27 = {name = 0x7f66cc516d58 "", namelen = 1, namelabs = 1, nslist = 0x0, target_list = 0x0, usable_list = 0x0, result_list = 0x0, bogus = 0, has_parent_side_NS = 0 '\000', dp_type_mlc = 0 '\000', ssl_upstream = 0 '\000', auth_dp = 0 '\000', no_cache = 0} > > -- > broken node: > > dns1 :: ~ ? sudo unbound-control lookup blah.example.com > The following name servers are used for lookup of blah.example.com > ;rrset 17491 13 1 5 2 > . 17491 IN NS c.root-servers.net . > . 17491 IN NS d.root-servers.net . > . 17491 IN NS j.root-servers.net . > . 17491 IN NS e.root-servers.net . > . 17491 IN NS l.root-servers.net . > . 17491 IN NS h.root-servers.net . > . 17491 IN NS f.root-servers.net . > . 17491 IN NS k.root-servers.net . > . 17491 IN NS m.root-servers.net . > . 17491 IN NS i.root-servers.net . > . 17491 IN NS a.root-servers.net . > . 17491 IN NS g.root-servers.net . > . 17491 IN NS b.root-servers.net . > . 17491 IN RRSIG NS 8 0 518400 20200827170000 20200814160000 46594 . ZxJeYw7vVyjxZg8y7mtt5N3YtejDrho11npxtnjt7MMZm/MlbSErowznceyvXYhTkgF4dJOFGcrUkwFekcN86Zw0tN+cHYYb4lpV2o/pYtXIzo2w2OtA0WJURMB1pWcclhma9y648OiGUsEwImRXpCQS7Mgk+XKU05KFCg5yrFW+UC4faaQ1ZiisVnK9GF8CwsHCC82xT7HU/pAMFgF2vEovsomysMuDhBKE1QTP9MN/DqD6bitdqGmhQSC9GxxcRrNCCU8fSnW4UVIiOJ95kaEMDk0kdpTGowBcKx2WCbXN8oKGSYRpJjE+y77mc2mv3cBUBwK9jnqB86jXwZ7enA== ;{id = 46594} > Delegation with 13 names, of which 13 can be examined to query further addresses. > It provides 0 IP addresses. > cache delegation was useless (no IP addresses) > > Any other help finding out how dns_cache_find_delegation returns the root delegations instead of the auth_zone (in this case example.com is the auth zone, with a proper zone file on disk)? > > -Andrew > > >> >> -Andrew >> >>> Regards, >>> >>> Jan. >>> >>> ?On 7/12/20, 12:00 PM, "Unbound-users on behalf of Eric Luehrsen via Unbound-users" on behalf of unbound-users at lists.nlnetlabs.nl > wrote: >>> >>> On 7/11/20 11:49 AM, Andrew Forgue via Unbound-users wrote: >>>> I have an unbound server that acts as a recursive resolver for clients and also acts as a target for fully delegated DNS (i.e. unbound is the NS record). For the fully-delegated domain it is a simple stub zone with an upstream of localhost on a different port. Let's call it "blah.example.com ". >>>> >>>> Occasionally, unbound (has happened on versions 1.10.1 and 1.7.3) will start responding to non-recursive queries with the list of root zones instead of a response from the stub-zone. It seems that clients that use the `rd` flag are fine and continue to be able to resolve records in the stub-zone. Only recursive desired clients will receive correct records from unbound (using the stub server). All records in seemingly all stub zones have this behavior simultaneously. >>>> >>>> I don't know what triggers it, but a full restart of unbound is the only thing that fixes it. I've tried flushing cache, flushing infra, and everything, nothing seems to matter. I've seen only 2 things that may point to the issue. >>>> >>>> - With verbosity turned up to 10, there's an entry produced in strace (but not in the actual log - maybe a misconfig): "unbound[2213085:5] debug: answer from the cache failed" >>>> >>>> - stracing the "broken" unbound process is a very tight recvmsg() (of the request) and sendmsg() (with the root servers) with no syscalls in between. >>>> >>>> Again, Using dig with +recurse works all the time, even when unbound gets in this state. So seems like an unbound bug / cache corruption or something? >>> >>> If it is a bug, you may want to try a work around while waiting for a >>> fix. You could try "auth-zone:" instead of "stub-zone:" or as a >>> companion to "stub-zone:" You may need to give the authoritative server >>> permission for a wholesale zone transfer to the Unbound instance. This >>> may help avoid some undiscovered bug in piecemeal zone recursion. >>> - Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg.gottleuber at digitalcourage.de Wed Aug 26 17:39:08 2020 From: georg.gottleuber at digitalcourage.de (Georg Gottleuber) Date: Wed, 26 Aug 2020 19:39:08 +0200 Subject: frequent crashes / restarts with unbound 1.9.0 Message-ID: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> Hello unbound users, I am new to unbound and running an open resolver (a project of digitalcourage.de against censorship attempts in germany[1]; we have taken measures outside of unbound against DNS amplification). It seems that unbound is frequently crashing / restarting. Once the service is started, nothing indicates a crash, but average time.up (from stats)never even reaches 120s (our monitoring interval). RAM usage stays very low and caches are not populated. After removing all "experimental" features from our config (see below) the situation got better. Now sometimes time.up reaches 1000s. At night time.up goes up to higher values, so I think server load plays some role in this strange behavior. Any ideas? Platform details: * Debian 10 (stable), Kernel 4.19.0-10-amd64 * unbound 1.9.0-2+deb10u2 * iptables, limiting UDP output (on public NS-interface) Hardware & stats: * VM with 4 VCPUs, 6 GB RAM * num.query.tls: 60/sec * total.num.queries: 1500/sec * load average: 2,67, 3,27, 3,33 -- config -------------------------------------------------------------- server: interface: 46.182.19.48 at 53 interface: 2a02:2970:1002::18 at 53 interface: 46.182.19.48 at 853 interface: 2a02:2970:1002::18 at 853 tls-additional-port: 853 tls-service-key: /path/dns2.digitalcourage.de/privkey.pem tls-service-pem: /path/dns2.digitalcourage.de/fullchain.pem outgoing-interface: [some IPv4] hide-identity: yes hide-version: yes prefetch: no # public access access-control: 0.0.0.0/0 allow access-control: ::/0 allow verbosity: 1 logfile: /var/log/unbound.log # platform / scaling / performance num-threads: 4 msg-cache-slabs: 4 rrset-cache-slabs: 4 infra-cache-slabs: 4 key-cache-slabs: 4 msg-cache-size: 1024m rrset-cache-size: 2048m # with libevent outgoing-range: 8192 num-queries-per-thread: 4096 incoming-num-tcp: 1000 outgoing-num-tcp: 1000 root-hints: root.hints deny-any: yes minimal-responses: yes statistics-interval: 0 extended-statistics: yes remote-control: control-enable: yes control-use-cert: no ------------------------------------------------------------------------ regards Georg [1]: https://en.wikipedia.org/wiki/Digitalcourage#Campaigns From georg.gottleuber at digitalcourage.de Wed Aug 26 21:40:49 2020 From: georg.gottleuber at digitalcourage.de (Georg Gottleuber) Date: Wed, 26 Aug 2020 23:40:49 +0200 Subject: frequent crashes / restarts with unbound 1.9.0 In-Reply-To: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> References: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> Message-ID: <49bd56d9-38ba-4af9-7ace-76c47d08d0f3@digitalcourage.de> Some additional information: /var/log/unbound.log showing a crash / restart ---------------------- ... [1598473907] unbound[32484:3] notice: ssl handshake failed IP port 35524 [1598473908] unbound[32484:3] error: ssl handshake failed crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate [1598473908] unbound[32484:3] notice: ssl handshake failed IP port 35536 [1598473908] unbound[32484:3] error: ssl handshake failed crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate [1598473908] unbound[32484:3] notice: ssl handshake failed IP port 35546 [1598473909] unbound[4285:0] notice: init module 0: subnet [1598473909] unbound[4285:0] notice: init module 1: validator [1598473909] unbound[4285:0] notice: init module 2: iterator [1598473909] unbound[4285:0] info: start of service (unbound 1.9.0). [1598473910] unbound[4285:0] info: generate keytag query _ta-4f66. NULL IN [1598473910] unbound[4285:3] info: generate keytag query _ta-4f66. NULL IN [1598473910] unbound[4285:2] info: generate keytag query _ta-4f66. NULL IN [1598473910] unbound[4285:1] info: generate keytag query _ta-4f66. NULL IN [1598473910] unbound[4285:3] error: ssl handshake failed crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate [1598473910] unbound[4285:3] notice: ssl handshake failed IP port 35566 [1598473916] unbound[4285:2] error: ssl handshake failed crypto error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate [1598473916] unbound[4285:2] notice: ssl handshake failed IP port 35670 ... ------------------------------------------------------------------- SSL-Errors are spread across the whole file and in no correlation to crash / restart. /var/log/syslog may be more interesting --------------------------- [trimmed date and hour] 28:13 package-helper[24457]: /var/lib/unbound/root.key has content 35:36 unbound[24461]: [err] evmap.c:381: Assertion nread >= 0 failed in evmap_io_del_ 35:36 systemd[1]: unbound.service: Main process exited, code=killed, status=6/ABRT 35:36 systemd[1]: unbound.service: Failed with result 'signal'. 35:37 systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart. 35:37 systemd[1]: unbound.service: Scheduled restart job, restart counter is at 125. 35:37 package-helper[25882]: /var/lib/unbound/root.key has content 46:19 unbound[25886]: [err] evmap.c:381: Assertion nread >= 0 failed in evmap_io_del_ 46:19 systemd[1]: unbound.service: Main process exited, code=killed, status=6/ABRT 46:19 systemd[1]: unbound.service: Failed with result 'signal'. 46:19 systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart. 46:19 systemd[1]: unbound.service: Scheduled restart job, restart counter is at 126. ... ------------------------------------------------------------------- Regards, Georg From edmonds at debian.org Wed Aug 26 22:45:59 2020 From: edmonds at debian.org (Robert Edmonds) Date: Wed, 26 Aug 2020 18:45:59 -0400 Subject: frequent crashes / restarts with unbound 1.9.0 In-Reply-To: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> References: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> Message-ID: <20200826224559.GA1081966@mycre.ws> Georg Gottleuber via Unbound-users wrote: > Platform details: > * Debian 10 (stable), Kernel 4.19.0-10-amd64 > * unbound 1.9.0-2+deb10u2 Try unbound 1.11.0-1~bpo10+1 from backports. -- Robert Edmonds edmonds at debian.org From fernando at softov.com.br Thu Aug 27 00:18:04 2020 From: fernando at softov.com.br (Luiz Fernando Softov) Date: Wed, 26 Aug 2020 20:18:04 -0400 Subject: about Unbound ISP Config In-Reply-To: <64b58e9d-7c0a-8a32-e476-3e18d27ef64d@cedia.org.ec> References: <64b58e9d-7c0a-8a32-e476-3e18d27ef64d@cedia.org.ec> Message-ID: Hi. There isd a lot of ISP in Brazil using Unbound as DNS. Some of then with 100 clients, a lot with 1000 and go on. Using to accept recursive cached requests with ACL. We had a SO with an Unbound Web UI, called BrbOS. It's a FresBSD 64, running our mod kernel. The config is the secret. :) It will mainly be based on how many clients, aka requests and how much hardware do you have memory to cache, HD to save and reload cache if needed CPU/processors, to run threads 1 thread per core, power of 2 slabs then you need to consider using root servers or forwards. Forwards and good, but sometimes they cause problems. Root servers are good, sometimes you got stuck in a BGP or some cached server Sometimes work fine for like a year without needed to clear cache Maybe this gives you some info about config. [https://prnt.sc/u6j1yr](https://prnt.sc/u6j1yr) Em qua., 26 de ago. de 2020 ?s 09:48, Ing. Ernesto P?rez Est?vez, Mg. via Unbound-users escreveu: > El 26/8/20 a las 04:19, Tomas Netk via Unbound-users escribi?: > > Hello, > > is anyone using Ubound for ISP, and can share config file ? Im new for > > DNS and I would like to check config to get better understanding. > > > > Thank you very much > hi there > > I think that the alternative for an authoritative DNS will be NSD > instead of unbound. > > In my case I have ISPCONFIG for our first DNS (ispconfig+bind), and then > rsync every few minutes to my second DNS (the NSD one) and "slightly" > transform the configuration from bind to nsd. > > if you need more details you may write me directly. It is somehow easy. > > regards > EPE > > -- > CEDIA > La principal herramienta de Investigaci?n en el Ecuador. > > Gonzalo Cordero 2-122 y J. Fajardo > Cuenca - Ecuador > Telf: +593 7 407 9300 Ext. 115 > info at cedia.org.ec > www.cedia.edu.ec > -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg.gottleuber at digitalcourage.de Fri Aug 28 06:34:48 2020 From: georg.gottleuber at digitalcourage.de (Georg Gottleuber) Date: Fri, 28 Aug 2020 08:34:48 +0200 Subject: frequent crashes / restarts with unbound 1.9.0 -- SOLVED (with unbound 1.11 from backports) In-Reply-To: <49bd56d9-38ba-4af9-7ace-76c47d08d0f3@digitalcourage.de> References: <2469049e-0c8e-ccb8-9618-f1c6dfe4444a@digitalcourage.de> <49bd56d9-38ba-4af9-7ace-76c47d08d0f3@digitalcourage.de> Message-ID: Hello, thank you for your help (via private messages). We are now running unbound 1.11 from backports. It is running for nearly a day without a crash. Regards, Georg