Re: support for roaming and captive portal detection?
On Mon, 14 May 2018, Martin Monperrus via Unbound-users wrote: I'm using unbound as DNS forwarder on my laptop. When I'm traveling, each time I am behind a captive portal, I have to manually set the name server to the one provided by the ISP: How to automate this? What kind of captive portal detection is compatible with unbound? Install the dnssec-trigger package and start the dnssec-triggerd service. It's still not the best. But I'm hopeful that due to HTTPS everywhere, the IETF captive portal people are finally being taken seriously so we can do real proper portal detection and interact more cleanly, which would hopefully result in only using the network DNS servers for the captive portal authentication itself (in a sandbox?) and for nothing else. PS: Firefox has such a feature in their new DNS-over-HTTPS feature, see https://bugzilla.mozilla.org/show_bug.cgi?id=1434852 That does not help you if you cannot browse the internet yet before the captive portal. Paul
Re: unbound fail after upgrade Ubuntu from 17.10 to 18.04
On Mon, 30 Apr 2018, Phil Pennock via Unbound-users wrote: You needed Unbound before. Are you _sure_ you still need it? It might be that systemd-resolved does what you need now. Does systemd-resolved still sends out your query over ALL interfaces' DNS servers and trusts the FIRST answer that comes back regardless of DNSSEC status? Paul
unbound 1.7.0 crashes
We have a report of crashing unbound servers in fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1562594 Unfortunately, there is not much information there: Description of problem: Unbound 1.7.0 from updates-testing crashes on a frequent basis with a buffer overflow error being logged: Apr 01 09:46:56 arden.compton.nu unbound[15415]: [15415:0] notice: sendto failed: Invalid argument Apr 01 09:46:56 arden.compton.nu unbound[15415]: [15415:0] notice: remote address is (inet_ntop error) port 45798 Apr 01 09:46:56 arden.compton.nu unbound[15415]: *** buffer overflow detected ***: /usr/sbin/unbound terminated Paul
Re: unbound binaries execution issue
On Mon, 5 Mar 2018, SIMON BABY via Unbound-users wrote: I get the below error while trying to launch unbound-host or unbound-anchor or any unbound executable in my build env. Can someone help to solve this issue? sbaby@ubuntu:~/workspace/wqar/tmp/work/mips-mv-linux/libunbound-1.6.8-r0/libunbound/unbound-1.6.8$ ./unbound-host is "sbaby" a mips machines too? It looks like you are perhaps cross-compiling, so in that case the binary cannot be tested on the build host. Or maybe your "mips-mv-linux" is a cross compile using a different set of libraries (like a different c library) ? Paul
Re: wildcard dnssec test fails
On Thu, 14 Dec 2017, Sebastian Schmidt via Unbound-users wrote: I’ve unbound setup on FreeBSD 11.1 and I can’t figure out why "drill www.wilda.nsec.0skar.cz" gives SERVFAIL. The domain is from this (http://0skar.cz/dns/en) test site where it reports three failures (2a, 2b and 4). Any help would be appreciated. It does not fail for me: $ dig www.wilda.nsec.0skar.cz ; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> www.wilda.nsec.0skar.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18098 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.wilda.nsec.0skar.cz. IN A ;; ANSWER SECTION: www.wilda.nsec.0skar.cz. 300IN CNAME flexi.oskarcz.net. flexi.oskarcz.net. 3599IN A 85.239.227.179 Is your unbound configured to use another DNS as forwarder? There are some older known bugs that fail in some corner cases with older forwarders. Paul
unbound-1.6.6rc1 spun out of control
Hi, Today I found my laptop very unresponsive, and noticed that unbound was using 230% CPU. Unfortunately, I was rather busy, so I just killed and restarted unbound and have no further information what went wrong :( It happened just after opening my laptop, and not having connected to wifi at all. If it happens again, I'll hopefully be in a better position to investigate and report back. Paul
Re: [NLnet Labs Maintainers] Unbound 1.6.6rc1 prerelease
On Mon, 4 Sep 2017, W.C.A. Wijngaards wrote: Unbound 1.6.6rc1 prerelease is available: https://unbound.net/downloads/unbound-1.6.6rc1.tar.gz Compiles without issues and seems to run without issues too, but only did limited testing. It seems I had a bug in my ipsecmod hook, that caused the hook to accidentally also try a lookup of the name that triggered the hook, and while this previously succeeded, it is now getting a servfail (justifiably so!), so I'm fixing up my code :) Paul
ipsechook and unbound-checkconf
Hi,
The unbound-checkconf code checks for the ipsecmod hook to exist:
check_chroot_string("ipsecmod-hook", >ipsecmod_hook, cfg->chrootdir
,
cfg);
I want to ship unbound with the ipsecmod module enabled via the
modules line, but activated via unbound-control. This means that
the unbound.conf needs no changes when switching from regular mode
to the mode where it uses the ipsec module for lookups. Currently,
the ipsecmod hook is checked for, but if people don't have libreswan
installed, unbound-checkconf fails, and with the systemd service,
it means unbound won't start.
I've patched this check out to prevent this.
Paul
ps. minor nit: you should rename check_chroot_string() if you use
it for multiple things, one of which does not involve chroot :)
val-permissive-mode not working via unbound-control ?
I tried the following: service unbound restart sudo unbound-control set_option val-permissive-mode: yes dig www.dnssec-failed.org But that still gives a servfail. Sprinking various flush_* options also did not seem to help. Is this a bug or a feature? :) Setting val-permissive-mode: yes in unbound.conf and restarting does work as expected. Paul ps. don't test this using dnssec-tools.org as test.dnssec-tools.org seems to have lost its DS record so all test domains are insecure and no longer bogus :P
Re: Python module to ignore query
On Tue, 9 May 2017, Eduardo Schoedler via Unbound-users wrote: No exist ip address like 333.x.x.x, for example. So, I wrote a python module to filter this questions. But is that wise? If this malware ends up sending the DNS query to a legitimate system DNS function, then such a DNS function will retry the query a number of times to all the DNS resolvers configured on the client. So you are actually making the problem worse. Filtering a DNS query on a recursor is almost never the right solution. Paul
Re: unicode request blocking
On Sat, 22 Apr 2017, Joris L. wrote: Thanks Paul, i understand, mostly. I must admit i'm somewhat dumbfounded with "The real fix here is that .com needs to come up with proper policies regarding mixing scripts and domain bundling, something that the newGLTDs did properly. " See https://archive.icann.org/en/meetings/saopaulo/presentation-IDN-tutorial-03dec06.pdf What do you mean with "mixing scripts and domain bundling" ? Mixing a Cyrillic "c" in a latin alphabet will very hard for humans to distinguish from a Latin "c", so this must be disallowed, or at the very least end up at the same Registrant. For domain bundling, see https://cira.ca/assets/Documents/Legal/IDN/faq.pdf It means that since I have registered "nohat.ca", no one but me can register "nohâts.ca". These names come in a "bundle" to the same Registrant only. Paul
Re: configure --with-libevent not causing make unbound-event-install
On Mon, 10 Apr 2017, W.C.A. Wijngaards via Unbound-users wrote: This install is triggered by the option --enable-event-api . Just enabling --with-libevent does not trigger the install by itself. What does --with-libevent without --enable-event-api do? The packages I've created now used --with-libevent and a manually installed header file. Does --enable-event-api do anything else I am missing? My point being of course, I see a bug where you see a feature :) And since every distro got it wrong, I think merging --enable-event-api and --with-libevent into one target that also installs the header file is the proper bugfix. Paul
configure --with-libevent not causing make unbound-event-install
When building unbound with --with-libevent support, the make install phase should also call make unbound-event-install or else unbound-event.h does not get installed and the header file for using the unbound event functionality is not available. I've just updated the fedora packages to manually call this, but the rhel packages will take some more time to get this fixed :( We will need this to work properly for librswan in the next release. I hope debian maintainers and other maintainers are on this list as well, if not please let them know to issue a fix. Paul
Re: [NLnet Labs Maintainers] Unbound 1.6.1rc3 prerelease
On Tue, 14 Feb 2017, W.C.A. Wijngaards wrote: Unbound 1.6.1rc3 is available: Still compiled successfully on all architectures Paul
Re: Unbound 1.6.1rc2 prerelease
On Fri, 10 Feb 2017, W.C.A. Wijngaards via Unbound-users wrote: Unbound 1.6.1rc2 is available: That fixed the issues on fedora and it now compiles properly. Paul
Re: Unbound 1.6.1rc1 prerelease
On Thu, 9 Feb 2017, W.C.A. Wijngaards via Unbound-users wrote: - configure --enable-systemd and lets unbound use systemd sockets if you enable use-systemd: yes in unbound.conf. Also there are contrib/unbound.socket and contrib/unbound.service: systemd files for Looking at the unbound.conf man page, I see that the socket support is for socket activation. I know that the systemd people think that is all cool and stuff, but I really don't know if this is appropriate for various daemons, especially DNS. Any service requiring DNS will pretty much block until it gets a DNS answer. I don't think pointing resolv.conf to something not running yet is a swell idea either. Much better to confirm the DNS server is working before pointing resolv.conf at it. And what is port 1153 used for? According to IANA this port is used for transporting ANSI C12.22/IEEE 1703/MC12.22 Advanced Metering Infrastructure (AMI) Application Layer Messages on an IP network as per RFC-6142. I don't think unbound should be using that port. c1222-acse 1153/tcp# ANSI C12.22 Port Also, the port is > 1024, so that makes me double reserved about unbound as a daemon running the port. Any user could grab that port. I'm not clear on the security implications of that. If you really want to ship an unbound service file, I think this one that is used by rhel/fedora is much better, as it also deals with not restarting and failing on a bad configuration file, trying to update the DNSSEC root key before starting, and generating the keys and certs to use unbound-control properly. [Unit] Description=Unbound recursive Domain Name Server After=network.target After=unbound-keygen.service Wants=unbound-keygen.service Wants=unbound-anchor.timer Before=nss-lookup.target Wants=nss-lookup.target [Service] Type=simple EnvironmentFile=-/etc/sysconfig/unbound ExecStartPre=/usr/sbin/unbound-checkconf ExecStartPre=-/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS ExecReload=/usr/sbin/unbound-control reload [Install] WantedBy=multi-user.target Paul
Re: [NLnet Labs Maintainers] Unbound 1.5.10rc1 prerelease
On Tue, 20 Sep 2016, W.C.A. Wijngaards wrote: Unbound 1.5.10rc1 prerelease is available: http://www.unbound.net/downloads/unbound-1.5.10rc1.tar.gz sha256 2e4caddab49bb07900d5ae8d9d4571ee1f32d2d3cabac6c02d6cfc3f78907fa8 pgp http://www.unbound.net/downloads/unbound-1.5.10rc1.tar.gz.asc win32 http://www.unbound.net/downloads/unbound-1.5.10rc1.zip and http://www.unbound.net/downloads/unbound_setup_1.5.10rc1.exe This is the maintainers prerelease to catch packaging and release issues. Seems to work, although I haven't tested any of the new features. Paul
Re: EL6 EPEL Version
On Fri, 10 Jun 2016, Phil Mayers via Unbound-users wrote: On 09/06/16 20:00, Paul Wouters via Unbound-users wrote: On Thu, 9 Jun 2016, Ehren Hawks via Unbound-users wrote: > With the release of 1.5.9 are there any plans to update the package > available in EPEL repository? My caching servers are on > CentOS 6 and have 1.5.1 installed from the epel repo. Prior to 1.5.1 I > recall new versions appearing regularly. Unfortunately, no. Because unbound moved into core RHEL, and so updates will I don't know the EPEL rules, but do they allow things like "unbound15" as a package i.e. move to a separate name for the "newer/upstream" combo? Yes that could be done. But I'd rather try and see if the base package can get a better update mechanism. Paul
RE: EL6 EPEL Version
On Fri, 10 Jun 2016, Ehren Hawks via Unbound-users wrote: Or put newer packages in another hosted repository? While possible, not many people would find them available. You could just grab the fedora package and rebuild it - at least for RHEL7. For RHEL6 the changes to the spec file will be minimal (like the version change and possibly some patch removal) Paul -Original Message- From: Unbound-users [mailto:unbound-users-boun...@unbound.net] On Behalf Of Phil Mayers via Unbound-users Sent: Friday, June 10, 2016 7:16 AM To: unbound-users@unbound.net Subject: Re: EL6 EPEL Version On 09/06/16 20:00, Paul Wouters via Unbound-users wrote: On Thu, 9 Jun 2016, Ehren Hawks via Unbound-users wrote: With the release of 1.5.9 are there any plans to update the package available in EPEL repository? My caching servers are on CentOS 6 and have 1.5.1 installed from the epel repo. Prior to 1.5.1 I recall new versions appearing regularly. Unfortunately, no. Because unbound moved into core RHEL, and so updates will I don't know the EPEL rules, but do they allow things like "unbound15" as a package i.e. move to a separate name for the "newer/upstream" combo?
RE: EL6 EPEL Version
On Thu, 9 Jun 2016, Ehren Hawks via Unbound-users wrote: With the release of 1.5.9 are there any plans to update the package available in EPEL repository? My caching servers are on CentOS 6 and have 1.5.1 installed from the epel repo. Prior to 1.5.1 I recall new versions appearing regularly. Unfortunately, no. Because unbound moved into core RHEL, and so updates will happen within RHEL and the EPEL package is now retired and cannot be updated to be a higher version than what's in RHEL. Although currently, that is the case because EPEL was newer than what was in RHEL7, and the RHEL6 packages are just clones of the RHEL7 ones. (the reason unbound became part of RHEL was because libreswan replaced openswan in RHEL-6.8, and we needed to keep that package and its dependencies the same) If people with a RHEL subscription file a bug to ask for an upgraded version, that would help me push for unbound updates in RHEL6/RHEL7. Paul
Re: ldns -> unbound migration
On Fri, 3 Jun 2016, Vladimir Levijev via Unbound-users wrote: Given the requirement to perform up to 20-40 DNS queries to different name servers asynchronously in a single task, how well can unbound handle such load (with all the possible timing outs and so on)? What would be the recommended limit of queries in this case? Seeing that the unbound DNS server uses libunbound, you can be sure this library can handle many orders of magnitude more than 40 qps. More like 400.000 qps :) And the second question, perhaps anybody has an idea, how easy is switching from libldns to libunbound? What are the advantages/disadvantages of doing that? There is some great documentation at unbound.net/documentation You are probably interested in: http://unbound.net/documentation/libunbound-tutorial-4.html http://unbound.net/documentation/libunbound-tutorial-5.html Paul
Re: unbound listening sporadically on 0.0.0.0 high ports when configured for 127.0.0.1 ?
On Fri, 3 Jun 2016, Daisuke HIGASHI wrote: Subject: Re: unbound listening sporadically on 0.0.0.0 high ports when configured for 127.0.0.1 ? My guess is: UDP sockets for outgoing query from Unbound to authoritative servers. I also see these "listening" UDP sockets at my laptop running unbound when resolver is under load. And I see no them when no load. That was my first thought too, but these entries do not have a destination IP or port, so it "appears" that these sockets are listening. Still it could be that perhaps these are sockets that are starting up for use or something? Paul -- Daisuke HIGASHI 2016-06-03 0:34 GMT+09:00 Paul Wouters via Unbound-users <unbound-users@unbound.net>: See https://bugzilla.redhat.com/show_bug.cgi?id=1342105 from time to time "netstat -l" shows unbound listening on some high-ports not bound to 127.0.0.1 - that makes no sense when the service is configured for 127.0.0.1 only as a local resolver on a inbound mailfilter udp0 0 0.0.0.0:42663 0.0.0.0:* 563/unbound udp0 0 127.0.0.1:530.0.0.0:* 563/unbound udp0 0 0.0.0.0:12387 0.0.0.0:* 563/unbound unbound.conf interface: 127.0.0.1 access-control: 127.0.0.0/8 allow interface-automatic: no Paul
unbound listening sporadically on 0.0.0.0 high ports when configured for 127.0.0.1 ?
See https://bugzilla.redhat.com/show_bug.cgi?id=1342105 from time to time "netstat -l" shows unbound listening on some high-ports not bound to 127.0.0.1 - that makes no sense when the service is configured for 127.0.0.1 only as a local resolver on a inbound mailfilter udp0 0 0.0.0.0:42663 0.0.0.0:* 563/unbound udp0 0 127.0.0.1:530.0.0.0:* 563/unbound udp0 0 0.0.0.0:12387 0.0.0.0:* 563/unbound unbound.conf interface: 127.0.0.1 access-control: 127.0.0.0/8 allow interface-automatic: no Paul
Re: message is bogus, non secure rrset with Unbound as local caching resolver
On Wed, 2 Mar 2016, Olav Morken via Unbound-users wrote: Unfortunately, the BIND server only tends to return responses where the authority-section has NS-records but no RRSIG-record during the night. I suspect it has something to do with traffic levels and what other systems are accessing it. It makes it all a bit hard to troubleshoot. The main source of information for troubleshooting has been a combination of PCAP-files and log files. Are you sure this is not the bind wildcard bug? Can you try to resolve something like pwouters.fedorahosted.org. That's an expanded wildcard. If so, this is the same bug as: https://bugzilla.redhat.com/show_bug.cgi?id=824219 We have a test for this, but I don't this dnssec-trigger has included this test yet. Paul
Re: Unbound does not honor forwarder DNSSEC verification?
On Mon, 29 Feb 2016, la9k3 via Unbound-users wrote: Is there a way to make unbound honor my forwarder's dnssec validation? For example, I use unbound as a caching forwarder and have "." set as a forwarding zone that forwards everything to Google's public DNS (8.8.8.8). However, when I test dnssec, I get a valid reply from servers such as www.dnssec-failed.org. This doesn't happen if I use Google's DNS as my normal resolver, in which case I get a SERVFAIL response. That works fo me: paul@bofh:~$ sudo service unbound restart Redirecting to /bin/systemctl restart unbound.service paul@bofh:~$ sudo unbound-control list_forwards paul@bofh:~$ sudo unbound-control forward_add . 8.8.8.8 ok paul@bofh:~$ cat /etc/resolv.conf # Generated by NetworkManager search nohats.ca nameserver 127.0.0.1 paul@bofh:~$ dig +dnssec www.dnssec-failed.org ; <<>> DiG 9.10.3-P3-RedHat-9.10.3-10.P3.fc23 <<>> +dnssec www.dnssec-failed.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.dnssec-failed.org. IN A ;; Query time: 490 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Mar 01 00:43:08 EST 2016 ;; MSG SIZE rcvd: 50 paul@bofh:~$
Re: Unbound 1.5.8rc1 prerelease
On Thu, 25 Feb 2016, W.C.A. Wijngaards via Unbound-users wrote: The 1.5.8rc1 release candidate is available looks good. The release fixes line endings in the unbound-control-setup script, and Confirmed. a potential gost-hash validation failure and handles the ".onion" domain to avoid privacy leakage. confirmed Seems all good, but I have only ran it for a little while so far. Paul
Re: unbound returns SERVFAIL although forwarder works just fine
On Wed, 23 Dec 2015, martin f krafft via Unbound-users wrote: I am running unbound (1.5.7 on Debian unstable) on a laptop as a recursive resolver for localhost and a number of test VMs running on the machine. I am aware that others use dnsmasq for this, but I don't particularly like this monolithic do-everything tool and am rather familiar with unbound already. Unfortunately, I am experiencing problems at regular intervals. One such problem is that occasionally, unbound will be unable to resolve records, returning SERVFAIL: % host debian.org Host debian.org not found: 2(SERVFAIL) According to the log (full log below), unbound thinks that the forward server is failing: unbound: [1144:0] debug: configured forward servers failed -- returning SERVFAIL However, querying the configured forwarding server works just fine. unbound: [1144:0] debug: processQueryTargets: targetqueries 0, currentqueries 0 sentcount 0 unbound: [1144:0] info: DelegationPoint<.>: 0 names (0 missing), 1 addrs (0 result, 1 avail) parentNS unbound: [1144:0] debug:ip4 192.168.1.1 port 53 (len 16) unbound: [1144:0] debug: attempt to get extra 3 targets unbound: [1144:0] debug: servselect ip4 192.168.1.1 port 53 (len 16) unbound: [1144:0] debug:rtt=12 unbound: [1144:0] debug: No more query targets, attempting last resort unbound: [1144:0] debug: configured forward servers failed -- returning SERVFAIL unbound: [1144:0] debug: store error response in message cache Did your forwarder perhaps not answer (in time) ? Maybe try setting cache-max-negative-ttl: to something like 5 seconds ? Paul
Re: Best practices for coding new RR Types
On Thu, 22 Oct 2015, Woodworth, John R via Unbound-users wrote: I am trying to implement logic for an experimental (Internet Draft) RR type and am curious if there is a common methodology to get the ball rolling. Glancing through the code it appears as if most of the magic is in sldns/rrdef.h and sldns/rrdef.c . do you need specific processingthat is not like normal record serving? Because if you just want your RRtype blob served, you can use a generic record format with a private user number. Paul
Re: unbound and systemd
On Fri, 16 Oct 2015, W.C.A. Wijngaards via Unbound-users wrote: Your patch seems to want to customize the compile itself, and always-active, install for systemd. This is because the Makefile is also trying to do the package install. Most package systems can pick up files and install them, especially system files like init.d/rc.d. It would be inappropriate (I think) for Unbound's Makefile to install these files, and even more so, install them when systemd is not present. So, I would leave those files in contrib, the Makefile then does not need any changes (I think). A packager or package-script can then pick then up and install them. Wouldn't that be cleaner and more portable? But that would cause a "make install" to leave something on the filesystem that is not ready to be enabled as a service or started on boot. So make install does need to make some decision on what init system support files to install. For libreswan, we detect the init system, and we provide an override. Our detection script supports systemd, sysvinit, upstart and openrc. See: https://github.com/libreswan/libreswan/blob/master/packaging/utils/lswan_detect.sh But we might be a little more linux-centric then you are. We allow an override running make with INITSYSTEM=sysvinit which is used to install sysvinit support on RHEL6 (which technically has upstart but no one uses it). Paul
Re: [NLnet Labs Maintainers] Unbound 1.5.6rc1 maintainers prerelease
On Thu, 15 Oct 2015, W.C.A. Wijngaards wrote: - - Default for ssl-port is port 853, the temporary port assignment for secure domain name system traffic. If you used to rely on the older default of port 443, you have to put a clause in unbound.conf for that. Hmmm. One use of this feature was not privacy but breaking through DNS restrictions, for which 443 has a much higher chance of working. Also, isn't the dprive dnsotls a different protocol from what unbound currently implements? Paul
Re: rfc6761 compliance
On Tue, 22 Sep 2015, Robert Edmonds via Unbound-users wrote: W.C.A. Wijngaards via Unbound-users wrote: It is not a particularly heavy root server load to mitigate, less code is better and easier, the unblock-lan-zones statement is a frequently asked question from our users. That said, we could add new code for this (and .onion?). Here are the caching DNS considerations for the zones that Unbound currently doesn't handle: [ "test." ] [ "invalid." ] [ "onion." ] While I don't see much harm in test and valid, there is a stronger case for onion not to leak out. I hope upstream will block it per default. If not, I might add a conf file to do so in the default unbound configuration for Fedora. Paul
Re: unbound-control flush_zone behaviour w.r.t the DS record
On Tue, 22 Sep 2015, W.C.A. Wijngaards via Unbound-users wrote: Today I ran into an unexpected flush issue. A domain with DS record no longer signed its zone and became BOGUS. Once the registrar removed the DS record, I ran an unbound-control flush_zone on the zone, but I still received a SERVFAIL. Turns out the DS record of a domain is not flushed because it does not live in the child zone but in the parent zone. I suggest to change the behaviour of unbound to also flush DS records of a zone in its parent with the flush_zone command. The flush_zone command flushes the DS record too. This works for me (eg. lookup a domain, dig DS record, flush it, dig DS record - fresh TTL). But I understand the domain you had did not become non-bogus after the flush? Was something else not flushed that should be? I'm not sure. It did not become non-bogus for sure. I didn't drop the cache and the domain is fixed now. So you'll have to create a test case I guess? :) Paul
Re: Question about DNS server address definition
On Wed, 19 Aug 2015, Rafael Santiago de Souza Netto via Unbound-users wrote: I'm new on libunbound. I tried to find in documentation some info about how to specify the exact DNS server to be queried when ub_resolve() is called but I was not able to found anything related. Is there a way to do it? ugh = ub_ctx_resolvconf(ctx, /etc/resolv.conf); You can use a tmp file and specify nameserver 1.2.3.4 in it. There might be an easier way to do this, but we use the system's nameserver as forwarder. Paul
Re: Using unbound-anchor for non-default trust anchor
On Tue, 28 Jul 2015, Edward Lewis via Unbound-users wrote: unbound-anchor, by default, pulls DNSSEC trust anchors from data.iana.org. I am trying to test RFC 5011 capabilities by following these websites: http://keyroll.systems and http://icksk.dnssek.info/fauxroot.html Goal is to run unbound-anchor as a first step before trying to tune unbound to either of those experiments. Have you tried using /etc/hosts entries for data.iana.org pointing to the others? :) More seriously, from the man page: -u name The server name, it connects to https://name. Specify without https:// prefix. The default is data.iana.org. It connects to the port specified with -P. You can pass an IPv4 addres or IPv6 address (no brackets) if you want. -x path The pathname to the root-anchors.xml file on the server. (forms URL with -u). The default is /root-anchors/root-anchors.xml. -s path The pathname to the root-anchors.p7s file on the server. (forms URL with -u). The default is /root-anchors/root-anchors.p7s. This file has to be a PKCS7 signature over the xml file, using the pem file (-c) as trust anchor. Paul
