Apparently there seems to be a misunderstanding at my end, e. g. where
is the point of validation if the majority of domains are not signed?
The validation happens at the resolver and the result of the
validation could be relayed to the client, that if the
Hi,
as the root zone is supporting AXFR/IXFR and in order not only to
mitigate the amount of upstream queries to authoritative servers and
speed up lookups but also to enhance privacy for client queries I am
facilitating queries for delegated TLDs via auth-zone:.
Hi,
the following error showing in unbound logs when querying an upstream
server over DoT on port 443:
> outnettcp got tcp error -1
The upstream server in question is also serving DoH and web content on
the same ip/port (443) and thus inquiring clients are supposed to
utilize SNI in order to
On 13.12.2018 05:47, Joe Abley wrote:
I don't see that Unbound needs any modifications to consult a different root zone on a different set of servers, though.
With different root zones in existence unbound can currently handle only one.
On 13.12.2018 05:27, Joe Abley via
Unbound-users wrote:
I
personally have no reason to make my life difficult by doing this,
and I have no users I hate enough to inflict this kind of ticking
timebomb on them, but there are no DNS style police here
Hi
If that has been discussed previously than I was not able to trace
it but being interested in whether there are plans to resolve
blockchain domains with Unbound?
Thus far my understanding is that it would require:
a transaction ID with the
://nohats.ca/wordpress/blog/2012/04/09/you-cant-p2p-the-dns-and-have-it-too/
Paul
Sent from mobile device
On Dec 13, 2018, at 16:58, ѽ҉ᶬḳ℠ via Unbound-users <unbound-users@nlnetlabs.nl>
Are both instances using the same ISP and DNS upstream resolver
(from the ISP)?
On 30.11.2018 13:57, A. Schulze via
Unbound-users wrote:
Hello,
we notices the name "www.revenue.ie" is un-resolvable via one of
our unbound
, Wouter
On 11/23/18 7:44 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
On 23.11.2018 18:36, via Unbound-users wrote:
however, those concerns are in a way off topic for this mailing list,
so allow me to ask a more direct unbound question. why does the cache
bloat? you're using LRU
The log is riddled with
query response was timeout
Maybe a protective measure. firewall or ant-virus or some, on the OS
that uses some checksum on the unbound.exe is preventing the new
*.exe from connecting to the internet.
On 04.12.2018 18:26, RayG
Hi,
from what I comprehend the current unbound syntax supports one root
at a time, e.g. either ICANN roots or alt-roots such as OPENNIC, but
not 2 roots in parallel. It seems currently not possible to have 2
root-hint files, 2 name . as auth-zone or 2 name . as
On 30.11.2018 11:50, Anand Buddhdev via Unbound-users wrote:
On 30/11/2018 11:37, ѽ҉ᶬḳ℠ via Unbound-users wrote:
With hyperlocal (RFC7706) requiring the root zone DNS server ip addresses listed
as master in auth-zone and since this information is already
On 30.11.2018 11:59, nusenu wrote:
I did
send an example unbound config for review to the DNSOP mailing
list:
https://mailarchive.ietf.org/arch/msg/dnsop/KLJFVjgALzvjZY0F0aZjFhE60LQ
The sample is using URL instead of ip addresses and thus have to
On 30.11.2018 11:59, nusenu wrote:
ѽ҉ᶬḳ℠ via Unbound-users:
With hyperlocal (RFC7706) requiring the root zone DNS server ip addresses listed
please don't use the term "hyperlocal" (reasoning: Paul Hoffman - RFC7706bis auth
With
auth-zone:
zonefile: /etc/unbound/zones/root
the is stating
error: could not open
/etc/unbound/zones/root.tmp1612: No such file or directory
The directory is existent (root:root). Whether the files exists or
has been created as
Whilst concurring on the abuse statement I am not sure why DNS
tunnel users should actually be wary of caching. The caching
related to the DNS tunnelling is bloating the cache, especially NULL
records not serving any legitimate purpose in DNS. But to detect
such users I
On 23.11.2018 18:36, via Unbound-users wrote:
however, those concerns are in a way off topic for this mailing
list, so allow me to ask a more direct unbound question. why does
the cache bloat? you're using LRU replacement, and these records
are
Oh yes, how silly of me having missed it...
For ratelimit-below-domain is there a wildcard syntax eligable, e.g.
for second level domain queries = ratelimit-below-domain: .* 2
or third level domain queries: = ratelimit-below-domain: *.* 1
The
Not to cache TXT records in general sounds sort of detrimental to
the concept of a caching resolver. And apparently none of the
resolvers does evaluate which TXT records are legitimate and which
are useless/nefarious - as in being attempts of DNS tunnelling.
TXT
I have read the following story about VPN tunnelling over port 53 at
a mobile carrier but that is related to routing and I would trust
that unbound is not the tool/place to control/analyse routing or be
in charge of network traffic/package payload control, though bind
I will be preventing DoH on my networks/nodes for those reasons
though likely DoH will find a receptive user/fan base (out of
convenience and being promoted as saviour to DNS privacy/security).
But that aside, and not having contributed to the creation of the
0 detached),
0 waiting replies, 21 recursion replies sent, 0 replies dropped, 0
states jostled out
On 26.11.2018 09:57, Wouter via
Unbound-users wrote:
Hi,
On 10/28/18 7:08 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
the foll
On 26.11.2018 09:57, Wouter via
Unbound-users wrote:
Hi,
On 10/28/18 7:08 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
the following configuration is known to work with unbound 1.8.x
Seems it
I don't see how how the ip-ratelimit feature in unbound would need
to be protocol aware considering that is it is restrained to the
unbound daemon and its ports and not being in charge of the entire
network?
On 28.11.2018 19:08, Paul Vixie via
Hi,
I would appreciate feedback on how best to go about setting unbound
to handle queries for tor services/domains.
Running a tor daemon client node as SOCKS5 proxy with
username/password credentials @ 192.168.112.12:9100 (tcp)
First off my
On 13/01/2019 13:53, Hans-Cees Speel via Unbound-users wrote:
Hello,
as stated here
https://nlnetlabs.nl/documentation/unbound/unbound-control/
You can add resource records and zones like this to unbound:
On 09.12.2018 22:35, David Conrad wrote:
On Dec 9, 2018, at 4:23 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
On 09.12.2018 22:11, Anand Buddhdev wrote:
Your question doesn't even make sense. How would unbound know to resolve
TLD1 via root, and TLD2
On 09.12.2018 23:22, David Conrad wrote:
On Dec 9, 2018, at 5:06 PM, ѽ҉ᶬḳ℠ via Unbound-users <unbound-users@nlnetlabs.nl> wrote:
How do you distinguish “.TLD” in the root from “.TLD” in the al
With
Fix #4206:
support openssl 1.0.2 for TLS hostname verification
I would have thought of this be gone but it is still present?
unbound-checkconf error: no name
verification functionality in ssl library
Version 1.9.0
linked libs:
On OpenWRT with:
Version 1.9.1
linked libs: pluggable-event internal (it uses select), OpenSSL
1.0.2r 26 Feb 2019
linked modules: dns64 subnetcache respip validator iterator
the log is full of:
outnettcp got tcp error -1
and I am at
?
On 11/05/2019 21:12, ѽ҉ᶬḳ℠ via
Unbound-users wrote:
On OpenWRT with:
Version 1.9.1
linked libs: pluggable-event internal (it uses select), OpenSSL
1.0.2r 26 Feb 2019
linked modules: dns64 subnetcache respip validator
To mitigate upstream queries (save bandwidth, speed up queries,
enhance privacy) it might be worthwhile to consider (pre)serving a
copy of the root (.) for local usage via auth-zone as described in
example.conf.in (Authority zones) in the package documentation.
On 29/07/2019 07:28, Wouter Wijngaards via Unbound-users wrote:
> Hi,
>
> On 7/27/19 5:42 PM, ѽ҉ᶬḳ℠ via Unbound-users wrote:
>> debug: read zonefile /srv/unbound/zone files/root for .
>> debug: no zonefile /srv/unbound/zone files/root for .
>>
>> That is with
Got logrotate for managing the recycling of various os and userland
logs, however the unbound generated logs are running somehow "wild" - as
in exceeding the size constrain of the current log (as set in the
logrotate conf). Also unbound logs that been rotated to pasture, pending
shredding,
On 29/07/2019 18:30, Jaap Akkerhuis wrote:
ѽ҉ᶬḳ℠ via Unbound-users writes:
> Have tried various settings in logroate but none seems to able to tame
> the unbound logs.
>
> Anyone with a similar usecase who would not mind sharing some good
> practice for unbound logs
35 matches
Mail list logo
