Re: Making unbound-anchor very verbose
Thanks. That has kicked me off in some direction. On 9/21/15, 11:02, "Unbound-users on behalf of unbound-users@unbound.net" wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >Hi Ed, > >It does not say a lot because all it does is do an UDP query, see that >it works, and exit. If you add, say, -F (force TLS update), then >it'll print out a lot of info (with -). Like, https headers, ssl >certificates, xml contents ... > >Best regards, Wouter > >On 14/09/15 18:56, Edward Lewis via Unbound-users wrote: >> D'oh - smallapp/... >> >> On 9/14/15, 12:04, "Edward Lewis" wrote: >> >>> I'd like to have unbound-anchor be (able to be) much more >>> verbose. >>> >>> $ unbound-anchor -a testroot.key $ unbound-anchor -a testroot.key >>> -v testroot.key has content success: the anchor is ok $ >>> unbound-anchor -a testroot.key -v testroot.key has content >>> success: the anchor is ok $ unbound-anchor -a testroot.key -v -v >>> -v -v testroot.key has content success: the anchor is ok >>> >>> I.e., the latter two ought to "show the work done." I'm more >>> interested in the process than obtaining the result (so long as >>> the result is as expected). >>> >>> >>> I'm not too familiar with unbound distributions. Where (in what >>> files) can I add print/echo statements to do this? (I don't have >>> specific statements to add, I need to prototype it.) I just >>> don't read script well enough I guess. ;) > >-BEGIN PGP SIGNATURE- >Version: GnuPG v2 > >iQIcBAEBCAAGBQJWABwHAAoJEJ9vHC1+BF+Neb8P/jSBaxli4sPh8Ip2amMPo+7I >fT4FLX17Rgld6kbgG0KPKSpFI2vCCO+n/L98naqKSKwSZdDEyKDDQ80C2ARxLfuB >v1oFQRtDY4+FHpmIyhzbAVMz1Q0Ghs7VQvcpAJbTv5s0L+Gj6ZwoG8TmNb8rdG1A >GAoS2BZBC/Gb0WRsR5e9ZlkjV8i5jGDEFYybiNvGnrsc4HKZjPXOO7/EJlEGNjtX >EhYTrCm2XrvNIQx9Gm4b2OyGbUmsM6RsJZc6IDLyKFrHnC2Uo1VOulx2bLj1ekHl >g5ZifUimdluPJ5zeItSGpPtAxGFunA+N2l2D1ydph3S4Ov5o1yneWf4pbA9OSwJo >/gRChnRLzNFFEVu3CDJLlOQjHLo48Hxj5K87kuJmK301bVuhhnPzKHXu+O2qlSX9 >IyQPzMatG+XgM+hPg4N2OEJegoq6cCLANV4y9klvQ6tIGGl29185ZPI4Nz4h2FCB >+fWSz8/rEbpmAnbetg5Vl2hR5gJD8+Dbh29HAGZEw2YSbNAY0nXr6A7bXDmL1oRc >2Na4kp0VhsPK2ErK+gXCbL1hyYYaRQIJmVaw0+9y8CA6wGw5Lgfz6CbYGaV/HA6s >ihiWSVH0751WUNWl+2BrBR1xzK5sS1kduDirPdFBz5iSRmy1eMpWONqQ6G70TmDh >eAwS32SX1p/Gn/l0jY+K >=Sd/Z >-END PGP SIGNATURE- smime.p7s Description: S/MIME cryptographic signature
Re: inconsistent forward-zone behavior between config files, unbound-control
A. Schulze via Unbound-users wrote: > Am 22.09.2015 um 19:02 schrieb Mike Brown via Unbound-users: > >* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 & > >75.75.76.76) > why would you do that? Comcast's 75.75.75.75 and 75.75.76.76 nameservers are anycasted. 75.75.75.75 in particular should (probably) be routed to a nearby Comcast data center. For instance, on my home Comcast connection, 75.75.75.75, F-Root, and L-Root all have anycast instances located in a local Comcast facility, so the RTT to these three servers are identical (~10 ms) for me. Comcast's servers perform DNSSEC validation and it should in theory be possible to have a validating DNS server like Unbound forward to those servers and re-validate the answers, so for a lightly loaded server it may actually result in *better* performance (latency wise) to forward to the nearby Comcast cache rather than directly contacting authoritative nameservers that may be much farther than ~10 ms away. > Also I'm not aware any unbound configuration is modified in any way by a DHCP > client. > I use to ignore any resolver announced by a DHCP server: The stock upstream Unbound distribution does not have any DHCP client integration, true. However, some OSes (e.g. Debian) have optional resolvconf integration, which can be used to automatically configure nameservers learned via DHCP as forwarders for Unbound. Other OSes may have similar functionality. This only works well if those nameservers perform DNSSEC validation, however. -- Robert Edmonds edmo...@debian.org
Re: inconsistent forward-zone behavior between config files, unbound-control
Am 22.09.2015 um 19:02 schrieb Mike Brown via Unbound-users:
* by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 &
75.75.76.76)
why would you do that?
I expect Comcast not to block other DNS queries? Assuming that I would suggest
to run unbound simply in default configuration -> resolving direct via root
nameservers.
No default forwarding -> no need to configure exceptions for DNSBL zones.
Also I'm not aware any unbound configuration is modified in any way by a DHCP
client.
I use to ignore any resolver announced by a DHCP server:
$ stat --printf "%a\n" /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf
755
$ cat /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf
#!/bin/sh
make_resolv_conf() {
logger -p daemon.info -t /etc/dhcp/dhclient-enter-hooks.d/do_not_touch_resolv_conf
"ignore DHCP suggestion 'nameserver $new_domain_name_servers'"
:
}
inconsistent forward-zone behavior between config files, unbound-control
It is quite possible I am just clueless and doing things all wrong, so please forgive me if this is a waste of your time. I've Googled and experimented for hours, and am no closer to understanding what's going wrong here. I'm just trying to get Unbound configured on FreeBSD 10.2-STABLE such that: * the DHCP-assigned nameserver (10.0.1.1, my router) is ignored, even after lease renewals * by default, queries go to my ISP's resolvers (Comcast: 75.75.75.75 & 75.75.76.76) * DNSBL zone queries bypass the ISP's resolvers - e.g., *.multi.uribl.com needs to be resolved starting from the root servers, such that a TXT lookup of test.uribl.com.multi.uribl.com will return the descriptive text "permanent testpoint" rather than "127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 76.x.x.x]" At the bottom of this post you can see my config files. The reason I'm bypassing the DHCP-assigned nameserver is because I only get SERVFAIL for any lookup with it, even though it just forwards to my ISP. It's a current-model Apple AirPort Time Capsule, so you'd think it would be DNSSEC-friendly, but I guess not, and of course there's no advanced settings available in the AirPort Utility. The main thing I'm trying to diagnose at this point is not the DHCP stuff, rather just the DNSBL forwards. When using my config files, lookups for most domains work, but the DNSBL test only ever gives me SERVFAIL. tcpdump is not very helpful; nothing is going out over the wire for those lookups, even on first try: 17:06:36.553477 IP (tos 0x0, ttl 64, id 46664, offset 0, flags [none], proto UDP (17), length 76, bad cksum 0 (->c656)!) 127.0.0.1.52659 > 127.0.0.1.53: [bad udp cksum 0xfe4b -> 0xede4!] 60714+ TXT? test.uribl.com.multi.uribl.com. (48) 17:06:36.561421 IP (tos 0x0, ttl 64, id 46675, offset 0, flags [none], proto UDP (17), length 76, bad cksum 0 (->c64b)!) 127.0.0.1.53 > 127.0.0.1.52659: [bad udp cksum 0xfe4b -> 0x6d62!] 60714 ServFail q: TXT? test.uribl.com.multi.uribl.com. 0/0/0 (48) And here's the unbound -ddvvv output: http://pastebin.com/raw.php?i=dcRP67yZ It includes the startup messages and the messages resulting from these 4 commands (and I realize I may be a bit paranoid with the flushes): # unbound-control -c /var/unbound/unbound.conf list_forwards . IN forward 75.75.75.75 75.75.76.76 multi.uribl.com. IN forward multi.uribl.com. # unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # host -tTXT test.uribl.com.multi.uribl.com Host test.uribl.com.multi.uribl.com not found: 2(SERVFAIL) OK, bear with me here. If I remove the "." forward at this point, I still get SERVFAIL: # unbound-control -c /var/unbound/unbound.conf forward_remove . ok # unbound-control -c /var/unbound/unbound.conf list_forwards multi.uribl.com. IN forward multi.uribl.com. # unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # host -tTXT test.uribl.com.multi.uribl.com Host test.uribl.com.multi.uribl.com not found: 2(SERVFAIL) ...And everything works fine if I remove both forwards: # unbound-control -c /var/unbound/unbound.conf forward_remove . ok # unbound-control -c /var/unbound/unbound.conf forward_remove multi.uribl.com ok # unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # host -tTXT test.uribl.com.multi.uribl.com test.uribl.com.multi.uribl.com descriptive text "permanent testpoint" Now here's the really weird part: I can add the forwards back in with unbound-control, and the behavior is different. Now the DNSBL forward is still not working, but instead of SERVFAIL, it is going through the default forward! # unbound-control -c /var/unbound/unbound.conf forward_add . 75.75.75.75 75.75.76.76 ok # unbound-control -c /var/unbound/unbound.conf forward_add multi.uribl.com multi.uribl.com ok # unbound-control -c /var/unbound/unbound.conf list_forwards . IN forward 75.75.76.76 75.75.75.75 multi.uribl.com. IN forward multi.uribl.com. # unbound-control -c /var/unbound/unbound.conf flush_zone uribl.com ok removed 11 rrsets, 4 messages and 0 key entries # unbound-control -c /var/unbound/unbound.conf flush_zone multi.uribl.com ok removed 0 rrsets, 0 messages and 0 key entries # host -tTXT test.uribl.com.multi.uribl.com test.uribl.com.multi.uribl.com descriptive text "127.0.0.1 -> Query Refused. See http://uribl.com/refused.shtml for more information [Your DNS IP: 76.96.107.199]" (I do note one small difference: the
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: rfc6761 compliance
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?). Hi, Wouter: I would guess that the .test and .invalid zones are much less used in private networks than the .in-addr.arpa ones, so much less likely to be a FAQ. And most of the code to setup default empty zones has been written already. Here are the caching DNS considerations for the zones that Unbound currently doesn't handle: [ "test." ] Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network. [ "invalid." ] Caching DNS servers SHOULD recognize "invalid" names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve "invalid" names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. [ "onion." ] Caching DNS Servers: Caching servers, where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to look up records for .onion names. They MUST generate NXDOMAIN for all such queries. I notice the .onion Special-Use registration has a MUST while the other two only have SHOULDs. Probably there will be a few more additions to the Special-Use Domain Names registry, and even if they only generate a trivial amount of root server load now, that means it's easy to prevent them from becoming a problem later :-) -- Robert Edmonds edmo...@debian.org
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: unbound.conf(5) access-control suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Patrik, On 05/08/15 20:14, Patrik Lundin via Unbound-users wrote: > Hello, > > Following the recent man page modifications I was reminded of > another part of the manual that I am curios if it could be modifed > a bit. This is the part about the access-control statement. I have > two suggestions: > > #1. Mention how the rules are evaluated. Is it first match wins, > last match wins, or most specific match wins? This is important > when configuring overlapping rules (because only a specific subset > should have allow_snoop for example). My testing points towards > the most-specific-match option. Yes. Documented that. > > #2. Mention what the behaviour is for clients that do not match a > configured ACL. While it is stated that the unconfigured default > is "allow localhost and refuse the rest", it is not explicitly > stated what happens to unmatched clients when once an ACL is > configured. The "deny" action is taken if there are no rules. Documented that. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAVI2AAoJEJ9vHC1+BF+NVKQP/0XnpPn+1vqQjPsyl5S/Zmf2 5NnJP+p39neY+54QnUD7Ss37wzxLi/YdK3VE/KUeUeDrhoT8sH8vSGXJIfO8pwH2 gdd98xacv2XGyXo5/uWgc2xCPHGs2s/N2GI4UfEHGm+E36aa5dg+pWBR+6nE29rR DOFumveYk9uXqD7A59AF7Xo7z16zNnHT7/29ZANAO9lPTcFZujrPpWcDaxLG7+ly UP3Aa5lh+AcDbj0XkoyxNurAoxNsIJXEfPqnKj8/hOrHr0LIzjdya98yLd2fWR/M fM5zdxGF+EwpJzaPH1c58GdxSUmU2dq1x5jTUehJufKR6pPmB/o0qmUmXHq6+1Uc WZs78YhmEyR42DId8aNLKJzVG6JuPBesocDznlYNobrnGrtPf6occ9Zd3HbtHfhJ uORNHEwoplODOatsUq8MwodJq+9jleHc+LrUoMb3EtPmkrZc1qePt4sTjVQ3yxR0 yZvuDBXJV53eT6ZqCHT3R1/QiYhAIc4cEqeQqGs1STEcHwJmmV9rVak+nWR1wav9 YYI55LDx/PrqtHje1I963l1GK8UAwIrHgzmlKPoXQnHb63dv7zzOA+VB87a6DAcM idbe/1tw6uDH3vszjAIvQj94kpCUtJ5eplaFNE9/Iq9lGiLX5wOUKBwjO4/ch2K1 JdwTE3sGwyZe5HwNSZ2+ =KHiu -END PGP SIGNATURE-
Re: Minor error in unbound.conf.5.in
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Ross, On 01/09/15 06:29, Ross L Richardson via Unbound-users wrote: > Word repetition error: If the the minimum kicks in should be If the > minimum kicks in Thank you. Fixed. Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAVDoAAoJEJ9vHC1+BF+Nd2YQAKKUQIY44uOYPsIqUoGnUNFj uzrtoW8NIwNAThoqs85JRTkQwsOtphCOraCcvR6g3MrYy6Zm2moFQFRwrm5xeDTp J0FVU8JgHiNJTxD2ucizeJERzO5x2dBkv75JzxrTtgK7NaVaQkZZXpWCkFUzruDi scpYmwcDHw8/7wmNMtXVdAf621ONot23rsZa35G/VxTJXnje4mn4uvcJfOloGHkT BC0s1QfBCmtlZuzjFHpVLoDweskgLbHbpjdYOR5OrYkqcUSNwuG35cAEjLqZULHS Sdr1TOwcpVrNAdPm1XiwuLaJcJH/WvBduMiM1ZgTCc5hjuhGG9w01NVOI1I/EJUM ERZxH37JAEUqRu8EbSp1tau3frg1gRuuE0qT3ngryHr/uitBsF0+dh8Yc0clTMHd AIMn7MlSYiPce/SqhkIckAq/18gCkCRSpFYY8n4SUQ/Sp9P/3qTBsLtkeNsAeKHc KALQdpI78OI2DcvJ1r/QnkyXLiRT26+vtPgv2PsCFVOYe10sfUgymltA7RWWm9ku KcHAbCU8Zoy9jZQ4mBs0+jRyzY5gpDr51Cs1B2eyNjEKLZ24FKdB1JV7b5YSZ25V 3upnswfKlnWtFmPwgWNsnIDE0V0Dris2at9EIX7LAbfNfl/escB/ZxBwwZkQGlrU uYVMW9xPWlee4TuZ6F9q =cx1I -END PGP SIGNATURE-
Re: A record from cache for request that resolved to (some) CNAMEs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Mehmed, On 21/09/15 13:17, Mehmed Kahric via Unbound-users wrote: > Hi, > > I have a similar issue as reported in Bug 669. > > For some (one for now) CNAMEs we have a empty A record answer from > Unbound. Proper answer came from remote DNS as showed in Unbound > log and tcpdump. Identical issue came from both us Unbound > instances: - CentOS 6, Unbound 1.5.1 from EPEL, configured as > recursive caching with forward-zone; - CentOS 7, Unbound 1.4.20 > from base, configured as authoritative, validating, recursive > caching. > > Log from first Unbound instance (with verbosity level 4) and from > tcpdump is in attachment, and dig from client (with output) is: What happens is the query for www.sensoray.com gives a CNAME to sensoray.com and an A record. But when queried specifically for the sensoray.com name the A record does not exist, the A record in the CNAME answer was a lie! You can test this yourself, with dig sensoray.com @8.8.8.8 and this returns no A record. (according to the verbosity 4 logs you give) The A record is inserted in the same way some cache-poisoning attacks work. The cache-poisoning attack mitigations in unbound remove it. (and unbound logs that it is scrubbed out of the answer). Best regards, Wouter > > --- C:\Users\Moi>dig www.sensoray.com @192.168.10.14 > > ; <<>> DiG 9.10.2-P3 <<>> www.sensoray.com @192.168.10.14 ;; global > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > NOERROR, id: 38559 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, > AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; > QUESTION SECTION: ;www.sensoray.com. IN A > > ;; ANSWER SECTION: www.sensoray.com. 5433IN CNAME > sensoray.com. > > ;; Query time: 218 msec ;; SERVER: 192.168.10.14#53(192.168.10.14) > ;; WHEN: Fri Sep 18 11:13:30 Central Europe Daylight Time 2015 ;; > MSG SIZE rcvd: 59 > > C:\Users\Moi>dig sensoray.com @192.168.10.14 > > ; <<>> DiG 9.10.2-P3 <<>> sensoray.com @192.168.10.14 ;; global > options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: > NOERROR, id: 5722 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, > AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; > QUESTION SECTION: ;sensoray.com. IN A > > ;; Query time: 31 msec ;; SERVER: 192.168.10.14#53(192.168.10.14) > ;; WHEN: Fri Sep 18 11:13:37 Central Europe Daylight Time 2015 ;; > MSG SIZE rcvd: 41 > > --- > > > Regards, Mehmed > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAQ+qAAoJEJ9vHC1+BF+NBaoQAKCxfaHOoV1n59p7ujexXbom Ai/89fCcumvoWG7x1SpEnkKOD/3bSYh4/gYQsXb+f5Cwpf+L8mXWUeVtuWg03GWl 8MCcbRfhTFLrKS2Uaa3agLRSNkXo/hKDkixlsnf67rnAGPNonJ/FSg0VF0Q7bC5s IGpdCYmyF4L/W2xlkW+0gh5WWD05cCFXNu4l7/Gg7esxdmY72H9otqtJQNODU9t7 t/9xwIMOeDMKIdkHsXfKru73rGCuq1+VSAyzaPrjV9dv3S/9eg22QgF5CbVxUl++ rUxm/KCY8UqTJbSXB5hv7qB0d2viJuX2UJgkNKuSzWmaCq9aMy9zyOJ3OXTtduz8 G925GS7UrLpBMTEotPeDYn7d2cJCwdaMUNnRkfjqIGdvz6Aw5WbmnlwQLimiBRoJ U8pDw2zzRn/u5j6YFrocVjgn0DUjeod9UA0tnTdLtuocE7HM65UY+AwNnwonxg7u Xj1XQlIvhSw9JMHB8uVYDJGKZDkqDIoyEkifR47DK6/Xo/D3s17PPlHFBfOcskd0 kbb00MoR4wvUXlHZm5S4/5l9l5+ZbMDBJc6910/+53tn8M+gH/i6vWMTyCjT6gko 5cUKaHGN5wsm5VsUb396rGkLnyQUw0z0T5S016bAgPsoK9Yx0djhoVU9cezVEE4v OvmFyxkjassU5o0ZJnll =elOW -END PGP SIGNATURE-
Re: [PATCH] unable to reload globs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Dag-Erling,
On 17/09/15 18:39, Dag-Erling Smørgrav via Unbound-users wrote:
> When the configuration lexer processes an include directive and
> unbound is chrooted, it will attempt to strip the chroot directory
> from the front of the filename. Unfortunately, this is omitted
> from the loop that handles globs.
>
> The bug was reported to me by a 1.5.3 user and has been confirmed
> in 1.5.4. The patch below is relative to 1.5.4 and applies to the
> latest trunk with a slight offset.
Thank you for the patch. Fixed code base, included for the next release
.
Best regards, Wouter
>
> Index: util/configlexer.lex
> ===
>
>
- --- util/configlexer.lex (revision 3445)
> +++ util/configlexer.lex (working copy) @@ -126,6 +126,10 @@
> #endif ; memset(&g, 0, sizeof(g)); + if(cfg_parser->chroot &&
> strncmp(filename, cfg_parser->chroot, +
> strlen(cfg_parser->chroot)) == 0) { + filename +=
> strlen(cfg_parser->chroot); + } r = glob(filename, flags, NULL,
> &g); if(r) { /* some error */
>
> DES
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIcBAEBCAAGBQJWAQvJAAoJEJ9vHC1+BF+NEl8P/1t1OKKekP9FriL11kBck2Kq
ZTlv9pV7OlR5nwge29RT5Hs3SrvvwU5Hx55tshKRE7T5jgTD7S63ExkdnxdARFAJ
z3lDT5NMc6jkXMvVouAl5qvRHr9+mzXYqKjIhDuStBbgK43xzlH28W/idiER1guI
znNJd980dumTWm2lJ1sMA44CBebqb2G4LEWTtZHbvSggpiY6vW1WlAM3e9AmxXci
ThNInOygjYjUNvehlZD5wbeSRd3Zu0R179thNdCBzvY8DmH/KNHktoO116m3viWX
esjN2F1L3XnOD+r6TASmh9uGQirIQpr7hM7gIXrZqiZVblbVchKG1itFqd6auqrs
GFIW6QH/TlNDOANZd3IbYC0gBYidpIiY2xuTDtz3v9e0GzquPsEX+YD0QOn+148K
/SgC15D1hjSRLV5qSE+fwrOeT5kwXm7dC+RsCyPlgQycfmv2qSbN6DaNZXoJRAjx
OGImwJ/o9CAH+rkde8PxDj+nmHwyhERUNXP9V0lQippkwZc0EWOXLXKQRllkOc8K
RVTgk2h7hZJvRQtjFRhD4wYWR6mIrvO9OLL1z/eCJcZKWHi1pCSjb4Y0Z3mHVO+S
P6gDRdhAWYan5rPJ6LIh0pFQ++tuLwawCNEztW+WjlwxjDHn7L80H5RqWTq3s3tV
Z3l2SNI4swAbwEYBrUUR
=h0S+
-END PGP SIGNATURE-
Re: Unbound not always resolving immediately after start.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Tomas, On 15/09/15 09:55, Tomas Hozza via Unbound-users wrote: > On 14.09.2015 14:15, Daisuke HIGASHI via Unbound-users wrote: >> Hi, >> >> SERVFAIL on tweakers.net seems to be from fix on CVE-2014-8500. >> This fix essentially limits number of query (to authoritative >> servers) to resolve target qname. If a qname requires many query >> to resolve it becomes SERVFAIL This situation often occurs when >> cache is empty (e.g. just after starting unbound or cache flush) >> >> bind-users have discussed same issue last year: >> https://lists.isc.org/pipermail/bind-users/2014-December/thread.html >> >> >> Possible workarounds are to increase MAX_TARGET_COUNT >> (iterator/iterator.h) to relax number of query limitation but it >> may reduce robustness against CVE-2014-8500-related attack. > > I think it is worth considering not having to recompile Unbound. It > would be much nicer to have this configurable in unbound.conf. > Something similar like BIND allows by max-recursion-queries > option. What value should we use for MAX_TARGET_COUNT? I'll increase the compiled default to that value. Easier than a configuration option that the user can get wrong and then be vulnerable. Best regards, Wouter > > Tomas > >> Regards, -- Daisuke HIIGASHI >> >> >> 2015-09-11 18:39 GMT+09:00 Frank de Bot via Unbound-users >> : >>> Hi, >>> >>> Under FreeBSD I'm setting up a resolv-only unbound server. >>> While testing I've noticed some domain do not resolve (server >>> returns SERVFAIL) > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAQOoAAoJEJ9vHC1+BF+NQoMP/1JPBhD+Hdd7f8yDqKhZHGhx MJ2C58U1vqZJoNheroWhg0Z6gD4e4A4WsGLSb1Ij/85IuM9vkFZl4eHtzqPXt5ZA TbEQ8QOfeaf5EcZgBp6AySsEfK5xTITTP9vWygO4/S1N6ppm+F1oKR7rGchQvA1E aNfiWQb/M/ldU3j+qZHn/6KJV1TU/H140/qe7VsbJLJ61d505A7mKhINSf+EmfeB myb7lOYF+ximLTeE//JBX0orQS8sfFmVWns6oaNSA9lhOYrF75Vgtt3lL/LIzBAf HJCog9BWalb1XaF9Suvr+sud69tEzJHiXsHiYZ4U2A18ujQR24zA3hBPpcxn45RT 7Pld26scQeVBxUzKI7stNIA4JyP4YcMCZMoA2XQfMOho1LZC8W6TIhUQPZww3YxM bbMTHxxnuAf9mJqgxyePgWTXncIXuppjsw+pD1dSNVnF726kabRINBv7hDBeSu6H ibufZqIA156iUehg9IKAc843E9JlIfxTHXX/v9DlqqH02aBJXBHmWJDnwjLNCaNZ DwzX32chXJmdFuZuN13Q5ZvJeFpJp5+NoN2Ym/Lti2zDbYqHW2OaVywSFWBbNnNl bbMJDWKLEHoA5dcHCH1wRFsPc/npc3TDg8CPE65/3DKLk72CRxytzs+wX1TaO1+D 8lmspddKr2diZi882BjF =Us9K -END PGP SIGNATURE-
Re: unbound-control flush_zone behaviour w.r.t the DS record
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Paul, On 16/09/15 04:35, Paul Wouters via Unbound-users wrote: > > Hi, > > 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? Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAQMVAAoJEJ9vHC1+BF+NsNsQAIGwBKreLwwaSdCzHHU7J0q9 G9d19RxYNu9dxeUZqKmjzdunPz2w00DhTnii40VLIYVofpz2J/YgwLUy/yUVddg2 uUlJO+ym5tVFiaN9f+qOlNaM+WdtBrZ3xhMgntoP7so+fJSaG0+TxMOoS3KP2LFy HQERD7RU1RgEaldNjY6cXLr4ghX95og8b8vjCOzoNYhHKAzkjQIpZa/HAvuMsma0 Psp2By8vg2w+JNIzFa5a4tPa4c7Q57IAoQq18ZlJNRUuxCyieuvnfp1aFtlS3xhe 5apwnZRt3ql/fP+AFUv5iIsTwvEj9GicgYluTfa+C5rz8JIGZcHGiPQCH/PNr/yP OfevbXoadcB0qAm20VOXTrMh5nP2LS4CD9nu+tTo29P1KEuntwszfAjYlbNB6Ph9 M0RavSC84xiwJOLfCxfh4mlNoJKG7wvL8tiI6QgPWShZHX/oFIpGt/SHDGnEnhjs qChmy7i0VUPDrhmK7mZDl4loBMVIROXGadN9QQD+grtNvczbLkjhdrVFpKJhgywk 1L66Hyrch22KAf3I3k3t5klGv3nJjvYi9YrTIoWMG8Cpj2f1zlbWPEJTqEY53IZ7 fU3w+auBzaXl8AsKOiiLgywUeznkd3t16IpRiEMOQ2Z6O2rcC5mmctBpiRpaddrc PrsOrnxsc1ygZfWOK+Db =BVwV -END PGP SIGNATURE-
Re: rfc6761 compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Robert, Andreas, On 11/09/15 17:54, Robert Edmonds via Unbound-users wrote: > A. Schulze via Unbound-users wrote: >> Hello, >> >> the RFC 6761 give some advise how caching DNS servers SHOULD >> handle queries for reserved domains. Mostly it say "do not send >> queries to the root name servers" >> >> ... point 4 in any case ... >> http://tools.ietf.org/html/rfc6761#section-6.2 ( domain "test." >> ) http://tools.ietf.org/html/rfc6761#section-6.4 ( domain >> "invalid." ) >> >> looks like unbound don't follow that "SHOULD" recommendations. it >> this a miss-configuration on my side ? > > I am also curious why these domains are not handled specially by > Unbound as RFC 6761 recommends. Interestingly, BIND has the exact > same behavior as Unbound for these two domains. (See > https://bugs.debian.org/55032 for details.) > 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?). Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJWAP6FAAoJEJ9vHC1+BF+N0acP/izkFs3pdDv0OMXqIC2p6I7e Qfbo+FfHawVfA8u58AaWJIcO7mdCiSDmzj7vzr3pnTWvdIuOZRKNuZphtzTwKuuV H/+bB9oeFwXef61uX3hepjihKmpoCY7l/UOhDlLRVIyQvYV5hmN1HJ3yHRkIXXCH lNxl0i4upEF7pBtVvnhl9jr/mYmPz4+6T7yKs4FV63RaQAXezRJyt/qmpBXDdvuf it82RdF0HmWNXegMiW7oV3iwZW5xrOpHYUPmbhYw4t85y1VkOHz4lbpdVZL9lDCs 33SySG1fgXSRe5LS4MHWnUJVTE1byAkZ1Hl5nK6D5MvEt9B/3utYiLjKDmBQrCLP bGsFesWcGf0OzA3OyVYgS24Vhs9pSJhzTke7B1g6Tmxc5PSZhUJS6STE6SWlI6XL 9Crd8VKyb4pNwq44ZHMzwu90vCshLAsOaKWpdj4iq00l8zxudZiGRmBj7Lz3qTRv ui/U9RtDVx2QQ+EyArgrzynrTTlg7LJan80/yhH7qohfRKffcy8DyqLKchujt+Wf RkhxrJtN/DlZvWqnqSGKAXt1Ah7fHnyqmbNuuPh82eiADyD9tw9uJt3K9bbiVUyN 1OdfgfbOK+xs/gxWUHHj4kfwhFR1DSGqs/eZoc5YFfJIDja/zGT8ftnZ/rmy9ScA bKFLzSWsptRIQKkH45TH =xeKM -END PGP SIGNATURE-
