RE: Unbound DNS on IPV6
RayG via Unbound-users wrote: This is off on a tangent which isn't very relevant to your problem, but it might still be of interest. You might want to add to your bogon list: 169.254.0.0/16 # link-local zeroconf I think this entry is a mistake - typo for 169.254? > private-address: 192.254.0.0/16 There's a bunch of weird stuff in 2001::/23 some of which you might want to blacklist, e.g. 2001:2::/48 which is analogous to the IPv4 test networks. https://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml Tony. -- f.anthony.n.finchhttp://dotat.at/ champion the freedom, dignity, and well-being of individuals
Re: Tuning for survey workloads
W.C.A. Wijngaards via Unbound-users wrote: > If you do a lot of DNSKEY queries, the prefetch-key: yes option > prefetches the DNSKEY query when a referral is followed. Nice :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ South Fitzroy: Northeasterly 5 to 7. Moderate or rough. Thundery showers. Good, occasionally poor.
Re: refuse ANY queries
A. Schulze wrote: > > but 4.4 suggest also truncation and force tcp, right? No, it just says implementations can return a full ANY response over TCP if they want - it doesn't say anything about truncation. > could a server send an answer without (or as less as possible data) and > set the TC bit? That would be a bad idea. The point of this draft is to make abusive ANY queries go away with the smallest response possible, so you don't want to encourage traffic to move to heavyweight TCP. There are reflection attacks that abuse recursive servers - sometimes many recursive servers symultaneously. These recursive servers will then bombard the authoritative servers for the name that is being abused in the attack. In this situation, if the authoritative server returns a truncated response, it will have many recursive servers hammering on TCP instead of UDP, which can easily lead to overload. If the authoritative server just returns a small subset response, the abused recursive servers will happily populate their cache with the small response and they won't hammer the authoritative servers, and the attackers will not get the amplification factor that they were expecting. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode German Bight, Humber, Thames, Dover, Wight, Portland: Variable mainly north 3 or 4, occasionally 5 at first. Mainly slight, but slight or moderate in north German Bight. Showers, perhaps thundery at first. Good, occasionally moderate at first.
Re: refuse ANY queries
A. Schulze via Unbound-users wrote: > > Any chance, someone implement "4.2. Synthesised HINFO RRset" > and let the operator choose 4.1 or 4.2? HINFO synthesis is only suitable for master servers that dynamically sign answers. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Bailey: Cyclonic, becoming mainly west 3 or 4, increasing 5 for a time. Moderate or rough. Showers. Mainly good.
Re: Persistent tcp-upstream
Gabriel Corona via Unbound-users wrote: > > This is quite suboptimal, especially when the connection is encapsulated > over TLS, and leads to many TIME_WAIT connections. In order to overcome > this problem, I wrote a prototypical daemon which aggregates DNS > requests over a single persistent TCP connection: > > http://www.gabriel.urdhr.fr/2015/12/09/dns-aggregator-tls/ > > https://github.com/randomstuff/dnsfwd This is cool :-) A couple of questions: I can't see where you are handling truncated responses. Since your upstream queries are over TCP, the responses can be too big to return to a UDP client - you need to strip them down and set the TC bit. I think, if I understand service::add_request() and client::add_request() correctly, you only have one outstanding query on the upstream connection at a time. You can reduce latency by pipelining queries over TCP. Make sure to allow for out-of-order responses! Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Portland, Plymouth: Southwest, veering west later, 4 or 5. Slight or moderate. Fair, then occasional rain. Moderate or good, occasionally poor.
Re: prevent unbound from attempting to contact root servers?
James Ralston via Unbound-users wrote: > > Any other ideas? Point the root-hints at a file containing your local server addresses? That might also not work properly since once Unbound has used the hints to get the current root server addresses, it'll probably try to refresh directly from the real root servers instead of your fake hints. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Northerly 4 or 5, increasing 6 to gale 8, occasionally severe gale 9 later. Very rough or high, occasionally rough. Thundery, wintry showers. Good, occasionally poor.
Re: What is the most convenient way for logging request including client source address?
Paul Vixie via Unbound-users wrote: > if anyone tries dnstap and encounters any trouble, please reach out to > me. it is farsight's goal to push this bsd-licensed open source > technology into the community and to make it easier for all operators to > see in real time what their name servers are doing. Do you have any tools for taking a full dnstap feed and fanning out filtered versions to multiple consumers? How about fan-in from multiple servers? Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Shannon: Southwesterly 5 or 6, becoming variable 3 or 4 in south. Moderate or rough. Occasional rain, fog patches later. Moderate or good, occasionally very poor.
Re: DNSSEC validaion fail for _25._tcp.eldinhadzic.com
W.C.A. Wijngaards via Unbound-users wrote: > > The server says it is > version.bind. 5 CH TXT "Rage4 DNS - https://rage4.com"; > and soa record also talks about rage4. > eldinhadzic.com.3600IN SOA ns1.r4ns.com. > postmaster.eldinhadzic.com. 1468246877 10800 3600 604800 3600 > I guess they have their own implementation. I reported a different DNSSEC bug in Rage4 DNS two years ago, and they were very responsive and fixed it within a day - I sent the bug report to off...@gbshouse.com (I can't remember where I got that address from I'm afraid...) Back then Rage4 DNS was a customized version of PowerDNS 3.1, so you might find a bug fix which matches this failure in the PowerDNS changelog. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Forties: Northwest 4 or 5, backing south 5 or 6. Slight or moderate. Rain later. Good, occasionally poor later.
Re: message is bogus, non secure rrset with Unbound as local caching resolver
Havard Eidnes wrote: > > > CD=1 is the wrong thing when querying a forwarder. When a > > domain is partly broken, queries that work with CD=0 can be > > forced to fail with CD=1. > > Relly? I interpreted the use of CD=1 as "I want to do my own > DNSSEC validation, and therefore don't want or need the > validation service which could be provided by the forwarder", > especially as noted above when the communication isn't secured. > It should not make much of a difference wrt. the validity of the > end result whether the forwarder or the unbound resolver does the > DNSSEC validation? This current case is a perfect example: unbound works when it queries upstream with CD=0 but not with CD=1. If a domain is a bit broken then you can get bogus data into the upstream cache using CD=1 and subsequent CD=1 queries will receive the bogus data. If the downstream validator doesn't have an alternative resolution path it is now stuck. But if it queries with CD=0 it can get unstuck. You need to suppress bogus data at every point in the resolution path. https://www.ietf.org/mail-archive/web/dnsop/current/msg11512.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Iceland: Easterly or northeasterly, 4 or 5, occasionally 6, becoming variable 4 later in west. Moderate or rough, occasionally very rough later in south. Mainly fair. Good.
Re: message is bogus, non secure rrset with Unbound as local caching resolver
W.C.A. Wijngaards via Unbound-users wrote: > > Following the "not a bug" response from the BIND maintainers > > yesterday evening, can you please point to chapter and verse > > mandating this behaviour for non-authoritative recursive > > resolvers? > > RFC4035 3.2.3 for validators, all RRsets in answer and authority > sections should be authentic ... > > https://tools.ietf.org/html/rfc4035#section-3.2.3 That's about setting the ad bit. Was it set in this response? Tony. -- f.anthony.n.finchhttp://dotat.at/ Humber, Thames: North 5 or 6, backing south 3 or 4, backing southeast 5 to 7 later. Slight or moderate, occasionally rough later. Showers, rain later. Good, occasionally poor later.
Re: message is bogus, non secure rrset with Unbound as local caching resolver
Havard Eidnes wrote: > > Come to think of it, anything you get from a recursive resolver are > possibly cached hints, including what you get in the Answer section. It isn't quite that bad due to the RFC 2181 trustworthiness ranking. > > Does Unbound use CD=1 when forwarding? If so, it should expect to receive > > partially bogus answers and should handle them gracefully. > > Yep, as Olav replied, and the pcaps I capture on the BIND recursor > agrees: CD=1 is set in the forwarded queries. CD=1 is the wrong thing when querying a forwarder. When a domain is partly broken, queries that work with CD=0 can be forced to fail with CD=1. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy, Sole, Lundy, Fastnet: West or northwest 5 to 7, perhaps gale 8 later. Moderate or rough in Lundy, otherwise rough or very rough, occasionally high later except in Fastnet. Rain or thundery showers. Good, occasionally poor.
Re: message is bogus, non secure rrset with Unbound as local caching resolver
Olav Morken via Unbound-users wrote: > > info: validate(cname): sec_status_secure > info: validate(positive): sec_status_secure > info: message is bogus, non secure rrset uninett.no. NS IN > > As far as I can tell, the problem here is caused by extra NS-records in > the authority-section that do not include the RRSIG element for the > NS-records, but I can't really say that for certain. This sounds a lot like a problem we discussed last year. See https://unbound.net/pipermail/unbound-users/2015-February/003757.html As I said back then, I think it's wrong to discard the entire response if parts of it are bogus. Unbound should keep the valid parts because it knows there is nothing wrong with them. Does Unbound use CD=1 when forwarding? If so, it should expect to receive partially bogus answers and should handle them gracefully. Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: North 4 or 5. Slight or moderate, occasionally rough later in north. Occasional rain. Good, occasionally moderate.
Re: postbank.de / dslbank.de and DNSSEC and DANE
A. Schulze via Unbound-users wrote: > But other people report they get NXDOMAIN and not SERVFAIL like I do. > (https://mail.sys4.de/mailman/private/dane-users/2016-February/thread.html) > > So I like to ask if unbound may behave different then bind. Yes, dig _25._tcp.mailrelay2.bonn.postbank.de. tlsa works for me with BIND. However dig +dnssec *.postbank.de. fails, so as you say, all is not well. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides, Bailey: Westerly 7 to severe gale 9 at first in south, otherwise cyclonic becoming northerly 5 to 7. Very high, becoming very rough or high. Rain, then wintry showers. Moderate, occasionally poor.
Re: Can DNSSEC resolvers pass through all mangling CPEs?
DNSSEC detects and blocks mangling, it does not bypass it. If your CPE or your ISP are lying to you, and you need to access the sites they are lying about, your only option is to use a different upstream resolver; you might also have to use a tunnel. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southwest Humber, Thames: Southeasterly 5 to 7. Moderate or rough. Showers. Moderate or good.
Re: NULL-checks before free()
Michael McConville via Unbound-users wrote: > > POSIX specifies that free() is NULL-safe. All modern and almost all > prehistoric platforms conform to this, and most codebases already assume > it. free() has been NULL-safe since C89. (Allocators were not very standard before then so I would expect 1980s pre-standard free() to behave weirdly.) Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Easterly 4 or 5, but 6 to gale 8 in southeast. Moderate or rough. Fair. Moderate or good.
Re: unbound NXDOMAIN TTL shared between records
Patrik Lundin via Unbound-users wrote: > > The first lookup (which also suspiciously seems to use the SOA TTL of 7200 > rather than the NXDOMAIN TTL of 18000): RFC 2308 section 5 Like normal answers negative answers have a time to live (TTL). As there is no record in the answer section to which this TTL can be applied, the TTL must be carried by another method. This is done by including the SOA record from the zone in the authority section of the reply. When the authoritative server creates this record its TTL is taken from the minimum of the SOA.MINIMUM field and SOA's TTL. Tony. -- f.anthony.n.finchhttp://dotat.at/ Plymouth: Southerly 4 or 5 becoming variable 3 or 4. Slight or moderate. Rain or drizzle, fog patches. Moderate or good, occasionally very poor.
