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:

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.finch http://dotat.at/ South Fitzroy:

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

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.finch

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

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

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. >

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

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

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

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.finch

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

Re: unbound NXDOMAIN TTL shared between records

Patrik Lundin via Unbound-users unbound-users@unbound.net 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