From what I understand, the newer versions of unbound(8) in -current (to be
shipped in OpenBSD 7.6) will mask the perceived problem with host(1)?
And the way host(1) now behaves, aborting at the first SERVFAIL, might be
intentional due to misbehaving DNS forwarders encountered in the past?
I’m
o get
>> what looks like a sensible response to A queries
>
> Same with base and package versions of host(1), FWIW.
Which is what I am using. OpenBSD 7.5 stable, unbound 1.18.0.
[snip]
> Hmm, and also going up a level to this which has both A and :
>
> $ host fwml
esting.
>
> Querying any of the auth servers directly with host or dig, I do get
> what looks like a sensible response to A queries
>
> $ host test.fwml42.v6.rocks. ns1.dynv6.com.
> Using domain server:
> Name: ns1.dynv6.com.
> Address: 95.216.144.82#53
> Aliases:
>
>
> Am 20.09.2024 um 13:13 schrieb Peter Hessler :
>
> On 2024 Sep 20 (Fri) at 12:45:08 +0200 (+0200), Mike Fischer wrote:
> :
> :> Am 20.09.2024 um 12:13 schrieb Stuart Henderson
> :
> :>
> :>> From what you've shown I can only assume the auth servers are broken
> :> and probably refusing to re
gt;> This is an example hostname I created at dynv6.com for the purpose of
>> figuring out this issue:
>> test.fwml42.v6.rocks
>>
>> $ dig +short test.fwml42.v6.rocks
>> 2001:db8::dead:beaf
>> $ host test.fwml42.v6.rocks
>> Host test.fwml42.v6.roc
host or dig, I do get
> what looks like a sensible response to A queries
Same with base and package versions of host(1), FWIW.
> $ host test.fwml42.v6.rocks. ns1.dynv6.com.
> Using domain server:
> Name: ns1.dynv6.com.
> Address: 95.216.144.82#53
> Aliases:
>
> test.fwml42.v
st -t a test.fwml42.v6.rocks. ns1.dynv6.com.
Using domain server:
Name: ns1.dynv6.com.
Address: 95.216.144.82#53
Aliases:
test.fwml42.v6.rocks has no A record
Testing with unbound 1.20.0 or 1.21.0 and there's no problem.
>From unbound (1.18.0) I get various of these,
unbound: [93237:0]
n source auth servers.
:
:Thanks!
:Mike
:
:>
:>
:> On 2024-09-20, Mike Fischer wrote:
:>> I am seeing a weird result on some OpenBSD 7.5 stable amd64 systems:
:>>
:>> The servers are running a local unbound(8) and /etc/res
v6.rocks
> 2001:db8::dead:beaf
> $ host test.fwml42.v6.rocks
> Host test.fwml42.v6.rocks not found: 2(SERVFAIL)
> $
Here host just succeeds with that name (not using unbound as resolver
but PowerDNS recursor)
$ host test.fwml42.v6.rocks
test.fwml42.v6.rocks has IPv6 addres
ome OpenBSD 7.5 stable amd64 systems:
>>
>> The servers are running a local unbound(8) and /etc/resolv.conf is
>> configured to use 127.0.0.1.
>> $ cat /etc/resolv.conf
>>
ially in custom DNS software like is probably used for a dynamic
dns zone.
If you show the real hostname, maybe someone can figure it out in
more detail.
On 2024-09-20, Mike Fischer wrote:
> I am seeing a weird result on some OpenBSD 7.5 stable amd64 systems:
>
> The servers are running
I am seeing a weird result on some OpenBSD 7.5 stable amd64 systems:
The servers are running a local unbound(8) and /etc/resolv.conf is configured
to use 127.0.0.1.
$ cat /etc/resolv.conf
On Mon, Mar 18, 2024 at 08:04:38PM +0100, Evan Sherwood wrote:
> > Wild guess, your time is off.
>
> Huh, I think you're right. `date` shows me 7 hours ahead of my timezone.
>
> I restarted ntpd and I see no errors in /var/log/daemon, but the time is
> still off. I should be 1200 PDT but it's s
> ... however I'm getting different errors now for the Slack-group
> specific URLs:
>
> ...
>
> validation failure : signatures from unknown keys
> from 2620:fe::fe
Was able to fix this by running `unbound-anchor` after fixing my system
clock. I think everything is working normally now.
Thanks!
> You can use rdate to jump the clock instead.
That updated my system clock to the correct time. dig queries against
Slack now work as expected, however I'm getting different errors now for
the Slack-group specific URLs:
```
# dig @::1 kubernetes.slack.com
; <<>> DiG 9.10.6 <<>> kubernetes.slack
On 2024-03-18, Evan Sherwood wrote:
>> Wild guess, your time is off.
>
> Huh, I think you're right. `date` shows me 7 hours ahead of my timezone.
>
> I restarted ntpd and I see no errors in /var/log/daemon, but the time is
> still off. I should be 1200 PDT but it's showing me as 1900 PDT (not
> U
> Wild guess, your time is off.
Huh, I think you're right. `date` shows me 7 hours ahead of my timezone.
I restarted ntpd and I see no errors in /var/log/daemon, but the time is
still off. I should be 1200 PDT but it's showing me as 1900 PDT (not
UTC).
What do I do to fix this? Pretty sure I ha
; WHEN: Mon Mar 18 18:42:15 UTC 2024
;; MSG SIZE rcvd: 207
The signature is only valid for an hour.
Wild guess, your time is off.
On 2024-03-18 19:20 +01, Evan Sherwood wrote:
> I have an unbound server using Quad9 as an upstream DNS provider. I have
> been unable to resolve records from s
I have an unbound server using Quad9 as an upstream DNS provider. I have
been unable to resolve records from slack.com recently using my local
unbound.
On the server:
```
# dig @::1 slack.com
; <<>> dig 9.10.8-P1 <<>> @::1 slack.com
; (1 server found)
;; global opt
Am Fr., 5. Jan. 2024 um 18:02 Uhr schrieb Roderick :
> Yes. It was mentioned in the list one or two years ago.
> The clock is OK, the internet connection also.
Indeed, this time was the clock!
I set the date to 2023-01-05 ... :)
Now corrected and is OK.
Rod.
Am Fr., 5. Jan. 2024 um 17:44 Uhr schrieb Capitan Cloud :
> Why you say old, is it reoccuring maybe?
Yes. It was mentioned in the list one or two years ago.
The clock is OK, the internet connection also.
> Do you mind to show here the actual content of resolv.conf?
nameserver 127.0.0.1
lookup f
The problem is old. Unbound does not resolve. I upgraded today to OpenBSD 7.4,
before I did not use the Nettop for some months. But when I upgraded
to 7.3 it worked,
today neither before nor after upgrading to 7.4 worked.
I added to the standard configuration file only:
do-ip6: no
log-servfail
erenberg (VE7TFX/VE6BBM)"
> wrote:
>
> > I am trying to get unbound to serve up reverse DNS for our internal
> > 1918 address space. I have been going hammer and tongs at unbound.conf
> > to try to make it forward requests for '*.10.in-addr.arpa.' to our
>
Todd C. Miller writes:
> local-zone: "1.1.10.in-addr.arpa." transparent
That (well, a variant) was the answer. I was having a real problem
wrapping my head around what 'transparent' did, so I was applying
it incorrectly. Thanks for prodding me to revisit it!
--lyndon
On Thu, 14 Dec 2023 12:05:24 -0800, "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote:
> I am trying to get unbound to serve up reverse DNS for our internal
> 1918 address space. I have been going hammer and tongs at unbound.conf
> to try to make it forward requests for '*.10.in-
I am at Witt's End.
I am trying to get unbound to serve up reverse DNS for our internal
1918 address space. I have been going hammer and tongs at unbound.conf
to try to make it forward requests for '*.10.in-addr.arpa.' to our
two internal nameservers that are authoritativ
Am So., 10. Dez. 2023 um 02:48 Uhr schrieb Todd C. Miller :
> By default, /etc/login.conf has umask set to 022. Is it more
> restrictive on your system?
Ah, yes. Mine is set to 077.
That would explain me being unable to start it via sudo.
And when I rebooted after a failed restart the permission
The mode on /var/unbound/db/root.key is influenced by the umask.
If you restart unbound from a shell with umask set to 077,
/var/unbound/db/root.key will be mode 0600. If the the umask is
022, the /var/unbound/db/root.key will be mode 0644.
By default, /etc/login.conf has umask set to 022. Is
Hi,
after the last erratas I rebooted my 7.4 and unbound failed to start because
unbound: [65439:0] error: unable to open /db/root.key for reading:
Permission denied
unbound: [65439:0] error: error reading auto-trust-anchor-file:
/var/unbound/db/root.key
unbound: [65439:0] error: validator: error
Il 09/09/23 16:54, Otto Moerbeek ha scritto:
On Sat, Sep 09, 2023 at 04:45:51PM +0200, Alessandro Baggi wrote:
Hi list,
when using unbound on OpenBSD 6.5 in the default configuration unbound comes
with root.hints file.
Upgrading to OpenBSD 7.3 I noticed that root.hints is not more supplied
On Sat, Sep 09, 2023 at 04:45:51PM +0200, Alessandro Baggi wrote:
> Hi list,
> when using unbound on OpenBSD 6.5 in the default configuration unbound comes
> with root.hints file.
>
> Upgrading to OpenBSD 7.3 I noticed that root.hints is not more supplied but
> unboun
Hi list,
when using unbound on OpenBSD 6.5 in the default configuration unbound
comes with root.hints file.
Upgrading to OpenBSD 7.3 I noticed that root.hints is not more supplied
but unbound manual page says:
"root-hints:
read the root hints from this file. Default is nothing,
Endeover:
In 7.3, I end up starting also unbound service by rcctl instead of
unbound-control (losing maybe something about security) hoping to give me a
better
general standard to control my services, including my approach
to sysupgrade.
Thanks to everyone who reply in the thread
Thanks Steve.
Jul 30, 2023 00:07:35 Steve Litt :
> I use runit (on Void Linux) every day, and love it to death. Runit is
> extremely simple. S6 is a little more capable and a little more complex.
Thank you for all the hints, expecially about runit, I didn't know it.
I'm going trying to fix thin
Daniele B. said on Tue, 25 Jul 2023 16:33:50 +0200 (GMT+02:00)
>My unattended upgrade happend like that:
>
>- I took up unbound
>- sysupgrade
>- 1st fw_update (this probbly is okay)
>- reboot
>- installation of the sets
>- 2nd fw_update (this fails because unattende
On Jul 28, 2023 20:00:24 I was still sleeping when suddenly Paul said:
> If you really want to go without DNS resolution, I invite you to
> travel back a few decades and learn about /etc/hosts.
did you hear my
"True, the hosts.. Oh Jesus!"... ?
Many thx! :D
-- Daniele Bonini
their DNS
resolution in such a way to need this kind of tomfoolery.
On Tue, Jul 25, 2023 at 09:58:35AM +0200, Daniele B. wrote:
|
| Hello,
|
| Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for
| it.. ;)
|
| No particular problem except my realization that with my settin
My unattended upgrade happend like that:
- I took up unbound
- sysupgrade
- 1st fw_update (this probbly is okay)
- reboot
- installation of the sets
- 2nd fw_update (this fails because unattended, local Unbound is down)
- reboot
- 3rd fw_update (this fails because unattended, local Unbound is
Thanks Steve,
Jul 25, 2023 14:41:53 Steve Litt :
> chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i
> resolv.conf
>
> I also don't understand why you start unbound manually instead of from
> computer initialization
-i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i
resolv.conf
I also don't understand why you start unbound manually instead of from
computer initialization. It sounds like if unbound started before
fw_update, there would be no problem.
SteveT
Steve
Hello Stuart, thanks for this one..
Yes, I agree that the final solution could be only the replace my listed
nameserver.
But do you remember I was using also the unmutable flag
on resolv.conf ? :D
I do not want to awake the lions and indeed I'm much happy about
my *unbound system
On 2023-07-25, Daniele B. wrote:
>
> Hello,
>
> Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for
> it.. ;)
>
> No particular problem except my realization that with my settings
> (unbound started manually) fw_update goes to fail (all the three
> at
Hello,
Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for
it.. ;)
No particular problem except my realization that with my settings
(unbound started manually) fw_update goes to fail (all the three
attempts) on each (unattended) upgrade. If fw_update happens to be a
Hello,
As I already stated before on my machine I'm using Unbound
local cache mechanism with its pros and cons.
One of the few cons that I mentioned to you lately was the prb,
sometimes occurring of faulty sites configuration that entering in the
Unbound cache lock me out during my subse
I noticed this in my logs (as well as noticing incorrect SERVFAIL
responses from time to time):
unbound: [12887:0] warning: setrlimit: Operation not permitted
unbound: [12887:0] warning: cannot increase max open fds from 512 to 4152
unbound: [12887:0] warning: continuing with less udp ports: 460
Zé Loff wrote:
> Use a local socket for unbound's remote control:
>
> remote-control:
> control-enable: yes
> control-interface: /var/run/unbound.sock
>
> or use unwind to force some domains to be resolved elsewhere,
> bypassing your caching resolver.
Thank you for hint,
On Sun, Feb 19, 2023 at 07:33:54AM +0100, Daniele Bonini wrote:
>
> Hello,
>
> I'm currently using Unbound in my own setup with a very basic
> and incomplete configuration that should serve myself mainly the local
> dns caching mechanism factor.
>
> Problem arising
Hello,
I'm currently using Unbound in my own setup with a very basic
and incomplete configuration that should serve myself mainly the local
dns caching mechanism factor.
Problem arising are two:
1) I'm not able to stop (or refresh) unbound via my own unload script as
unbound-
On 2023-01-27, Rodrigo Readi wrote:
> 2023-01-27 7:09 GMT, Otto Moerbeek :
>> On Fri, Jan 27, 2023 at 01:26:10AM +, Rodrigo Readi wrote:
>>
>>> It still happens. But when I kill unbound and start it again, then
>>> resolves domains that previously did not
2023-01-27 22:43 GMT, Zack Newman :
>> Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
>> route to host for 2001:4860:4802:36::a port 53 (len 28)
>> Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
>> route to host for 2001:4860:48
Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
route to host for 2001:4860:4802:36::a port 53 (len 28)
Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
route to host for 2001:4860:4802:32::a port 53 (len 28)
Jan 27 20:59:41 nc10 unbound: [72478:0] error
2023-01-27 7:09 GMT, Otto Moerbeek :
> On Fri, Jan 27, 2023 at 01:26:10AM +, Rodrigo Readi wrote:
>
>> It still happens. But when I kill unbound and start it again, then
>> resolves domains that previously did not resolve.
...
>
> Increase log level and look at the log
On 2023-01-27, Rodrigo Readi wrote:
> BTW, I am using Wifi with weak signal. Perhaps this plays a role?
If you have packet loss then possibly, yes. Unbound caches information
about hosts that it contacts ("infra-cache") and I'm not sure but this
might possibly temporarily stop
On Fri, Jan 27, 2023 at 01:26:10AM +, Rodrigo Readi wrote:
> It still happens. But when I kill unbound and start it again, then
> resolves domains that previously did not resolve.
>
> BTW, I am using Wifi with weak signal. Perhaps this plays a role?
>
> Rod.
>
>
It still happens. But when I kill unbound and start it again, then
resolves domains that previously did not resolve.
BTW, I am using Wifi with weak signal. Perhaps this plays a role?
Rod.
2023-01-11 20:06 GMT, Rodrigo Readi :
> I have unbound 1.16.3 on OpenBSD 7.2, all obtained by succes
The only logs I get in /var/log/messages:
Jan 11 21:14:27 nc10 unbound: [86313:0] notice: init module 0: validator
Jan 11 21:14:27 nc10 unbound: [86313:0] notice: init module 1: iterator
But now it is resolving normally. It seems sometimes fails to resolve,
sometimes do it.
2023-01-11 20:10
Am Mi., 11. Jan. 2023 um 21:06 Uhr schrieb Rodrigo Readi :
> It stopped to resolve some domains, for example qwant.com
All fine here.
> Any Idea what is happening?
Not without some logs.
Best
Martin
I have unbound 1.16.3 on OpenBSD 7.2, all obtained by succesive upadates
(no new installation).
It stopped to resolve some domains, for example qwant.com
Any Idea what is happening?
Thanks
Rodrigo
On 2022-11-15, Courtney wrote:
> I had a similar issue going from 7.1 -> 7.2 (though looking back, I
> think the issue is
> I made my config change and never rebooted until I upgraded to 7.1).
Different issue I think.
> However, my issue was not so much unbound waiting for an
I had a similar issue going from 7.1 -> 7.2 (though looking back, I
think the issue is
I made my config change and never rebooted until I upgraded to 7.1).
However, my issue was not so much unbound waiting for an interface, but
rather I wanted to allow listening on IPv6 and thus added
of the machine... :-(
>> >
>> > I've tried hard to get any log messages for this, but failed so far.
>> > Neither setting a log file for unbound nor "unbound_flags=-d -d"
>> > produced any output.
>>
>> If you use dnssec validation, it
get any log messages for this, but failed so far.
> > Neither setting a log file for unbound nor "unbound_flags=-d -d"
> > produced any output.
>
> If you use dnssec validation, it's probably the rc-script trying
> to fetch the anchor.
I do, so it's very possible. Any idea how to get logging from there
during bootup?
Best
Martin
On 2022-11-10, Jan Stary wrote:
> On Nov 10 00:39:59, mar...@oneiros.de wrote:
>> Am Do., 10. Nov. 2022 um 00:25 Uhr schrieb Jan Stary :
>> > With my current ISP, putting
>> >
>> > ifconfig pppoe0 down
>> >
>> > into rc.shutdown makes the subsequent boot faster with respect to pppoe.
>> >
On 2022-11-09, Martin Schröder wrote:
> Am Do., 10. Nov. 2022 um 00:02 Uhr schrieb Martin Schröder
> :
>> This happens only on bootup of the machine... :-(
>
> I've tried hard to get any log messages for this, but failed so far.
> Neither setting a log file for unboun
On Nov 10 00:39:59, mar...@oneiros.de wrote:
> Am Do., 10. Nov. 2022 um 00:25 Uhr schrieb Jan Stary :
> > With my current ISP, putting
> >
> > ifconfig pppoe0 down
> >
> > into rc.shutdown makes the subsequent boot faster with respect to pppoe.
> > I suspect it's waht you say: the session g
Am Do., 10. Nov. 2022 um 00:25 Uhr schrieb Jan Stary :
> With my current ISP, putting
>
> ifconfig pppoe0 down
>
> into rc.shutdown makes the subsequent boot faster with respect to pppoe.
> I suspect it's waht you say: the session gets "terminated properly"
> somehow; without it, it takes l
On Nov 09 22:51:08, stu.li...@spacehopper.org wrote:
> On 2022-11-09, Jonathan Thornburg wrote:
> > Hi,
> >
> >> I suspect that pppoe is a bit slow at startup, so unbound somehow times out
> >> but has no problems once the network setup/the machine is stable.
&
Am Do., 10. Nov. 2022 um 00:02 Uhr schrieb Martin Schröder :
> This happens only on bootup of the machine... :-(
I've tried hard to get any log messages for this, but failed so far.
Neither setting a log file for unbound nor "unbound_flags=-d -d"
produced any output.
Best
Martin
Am Mi., 9. Nov. 2022 um 23:51 Uhr schrieb Stuart Henderson
:
> On 2022-11-09, Jonathan Thornburg wrote:
> The only times I've seen ISPs take more than a few seconds to do pppoe
> (unless they're broken) are if they have an old session hanging around
> from a reboot or crash where the previous sess
On 2022-11-09, Jonathan Thornburg wrote:
> Hi,
>
>> I suspect that pppoe is a bit slow at startup, so unbound somehow times out
>> but has no problems once the network setup/the machine is stable.
The only times I've seen ISPs take more than a few seconds to do pppoe
(unl
Hi,
> I suspect that pppoe is a bit slow at startup, so unbound somehow times out
> but has no problems once the network setup/the machine is stable.
It's an ugly kludge, but what if you put a wrapper script around the
unbound binary which delays 30 or 60 seconds before executing
egin /etc/hostname.em1
up
-- end /etc/hostname.em1
And I have
-- begin /etc/resolv.conf.tail
lookup file bind
family inet6 inet4
-- end /etc/resolv.conf.tail
> Does the -d unbound flag give any useful output for you? More generally,
> how are you starting unbound, i.e., what (if any) flags are you pa
Hi,
> since upgrading my router to 7.1 unbound doesn't start up automatically
> anymore,
> instead it times out:
>
> starting early daemons: syslogd pflogd unbound(timeout) ntpd.
>
> It can be started successfully manually later. This setup worked with 7.0.
I have a
Hi,
since upgrading my router to 7.1 unbound doesn't start up automatically anymore,
instead it times out:
starting early daemons: syslogd pflogd unbound(timeout) ntpd.
It can be started successfully manually later. This setup worked with 7.0.
System is an apu acting as a firewall/router f
> This would usually suggest that the uid used by the daemon does not
> have permission to access to the log file or directory containing it
That's right, Stuart. I created the file as root and the user _unbound
could not access the file.
Thanks for the help!
On 2022-08-31, luci...@ctrl-c.club wrote:
> Hi,
> What is the proper way to use a logfile in unbound(8)? I tried adding
> the following lines in /var/unbound/etc/unbound.conf:
> # $OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $
>
> server:
> use-syslog:
W dniu 31.08.2022 o 12:39, luci...@ctrl-c.club pisze:
Hi,
What is the proper way to use a logfile in unbound(8)? I tried adding
the following lines in /var/unbound/etc/unbound.conf:
# $OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $
server:
use-syslog: no
logfile
Hi,
What is the proper way to use a logfile in unbound(8)? I tried adding
the following lines in /var/unbound/etc/unbound.conf:
# $OpenBSD: unbound.conf,v 1.21 2020/10/28 11:35:58 sthen Exp $
server:
use-syslog: no
logfile: log/unbound.log
Then touched /var/unbound/log
On Sun, Aug 28, 2022 at 10:46 PM Otto Moerbeek wrote:
>
> On Sun, Aug 28, 2022 at 12:26:25PM -0700, Amarendra Godbole wrote:
>
> > Hi,
> >
> > I am trying to troubleshoot an unbound error message that caused an
> > internet outage. My home network uses Xfini
On Sun, Aug 28, 2022, at 14:26, Amarendra Godbole wrote:
> I am trying to troubleshoot an unbound error message that caused an
> internet outage. My home network uses Xfinity internet - the cable
> modem router is hooked up to a pcengines firewall that runs OpenBSD
> and onward
Hi,
I am trying to troubleshoot an unbound error message that caused an
internet outage. My home network uses Xfinity internet - the cable
modem router is hooked up to a pcengines firewall that runs OpenBSD
and onward it goes to a Ruckus Wireless AP.
Couple of hours ago, my internet went down
penBSD 7.1 and copied my working
> Unbound configuration from a 7.0 install (attached).
> Unbound version on the new system is 1.15.0, on the old one it is 1.13.2.
>
> Upon starting it, I encounter this:
>
> opaon$ doas rcctl enable unbound
>
> opaon$ doas rcctl start unboun
Did you miss out
# unbound-control-setup
perhaps?
Allard wrote:
>>
>> Hello,
>>
>> Since I upgraded my DNS servers to 7.1 with unbound 1.15.0, I have a lot
>> of issues with DNS resolution (without changing anything in the config).
>> I randomly get SERVFAIL (or somethings NXDOMAIN) for a lot of names, or
On 2022-02-06, Laura Smith wrote:
> I have a local OpenBSD setup with NSD and Unbound.
>
> I'm seeing a weird problem where I am getting an NXDOMAIN (per below) on my
> internal "bar.corp" domain.
>
> My unbound config is as follows. If I do the same dig q
Hi Laura,
Hey, that's quite the advanced config, it's too advanced for me. Though I'd
do this setup a bit different. I program a program called delphinusdnsd and
it can do forwarding but is otherwise authoritative. I would put it on port 53
with a zone for bar.corp and a forwa
again, Really appreciate your
Tom Smyth
On Wed, 22 Dec 2021 at 11:26, Stuart Henderson
wrote:
> On 2021-12-22, Dirk Coetzee wrote:
> > Hi Tom,
> >
> > I would recommend debugging using "unbound-control stats_noreset" and
> referencing the unbound conf
On 2021-12-22, Dirk Coetzee wrote:
> Hi Tom,
>
> I would recommend debugging using "unbound-control stats_noreset" and
> referencing the unbound configuration documentation at
> https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/
Also check for "dropped
THanks Dirk Ill give that a go
Cheers,
Tom Smyth
On Wed, 22 Dec 2021 at 00:30, Dirk Coetzee wrote:
> Hi Tom,
>
> I would recommend debugging using "unbound-control stats_noreset" and
> referencing the unbound configuration documentation at
> https://www.nlnetlabs
Hi Tom,
I would recommend debugging using "unbound-control stats_noreset" and
referencing the unbound configuration documentation at
https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/
-Original Message-
From: owner-m...@openbsd.org On Behalf Of Tom Smyth
Sent:
Sorry forgot to say running OpenBSD on an amd64, and hosted in a KVM
environment,
Thanks
Tom Smyth
On Tue, 21 Dec 2021 at 21:15, Tom Smyth
wrote:
> Recommendations on Buffer Space for Busy Unbound Resolver Service for a
> network serving a 3000, customers
>
> Thanks
>
Recommendations on Buffer Space for Busy Unbound Resolver Service for a
network serving a 3000, customers
Thanks
--
Kindest regards,
Tom Smyth.
On 2021-08-31, Paul de Weerd wrote:
> 2. echo ::1 > /etc/resolv.conf
I think it is a good idea to list a second nameserver, in case unbound
dies or isn't running for some reason (for one, booting bsd.rd for an upgrade).
--
Please keep replies on the mailing list.
On Aug 31 16:32:23, we...@weirdnet.nl wrote:
> On Tue, Aug 31, 2021 at 03:31:18PM +0200, Jan Stary wrote:
> | The running resolvd recognizes if unwind is running,
> | and places 127.0.0.1 at the top of resolv.conf accordingly.
> |
> | Could we have the same for unbound please?
&g
On Tue, Aug 31, 2021 at 03:31:18PM +0200, Jan Stary wrote:
| The running resolvd recognizes if unwind is running,
| and places 127.0.0.1 at the top of resolv.conf accordingly.
|
| Could we have the same for unbound please?
| I run unbound insted of unwind to also serve some
| local names the
Sebastien Marie wrote:
> On Tue, Aug 31, 2021 at 03:31:18PM +0200, Jan Stary wrote:
> > The running resolvd recognizes if unwind is running,
> > and places 127.0.0.1 at the top of resolv.conf accordingly.
> >
> > Could we have the same for unbound please?
> >
On Tue, Aug 31, 2021 at 03:31:18PM +0200, Jan Stary wrote:
> The running resolvd recognizes if unwind is running,
> and places 127.0.0.1 at the top of resolv.conf accordingly.
>
> Could we have the same for unbound please?
> I run unbound insted of unwind to also serve some
&g
On Tue, 31 Aug 2021, Jan Stary wrote:
> The running resolvd recognizes if unwind is running,
> and places 127.0.0.1 at the top of resolv.conf accordingly.
>
> Could we have the same for unbound please?
> I run unbound insted of unwind to also serve some
> local names the m
The running resolvd recognizes if unwind is running,
and places 127.0.0.1 at the top of resolv.conf accordingly.
Could we have the same for unbound please?
I run unbound insted of unwind to also serve some
local names the machines around the office (beside resolution).
But resolvd only
I am using unbound DNS over TLS. I consistently get these error's but have
found little online about what they mean.
/var/log/messages
error: SSL_handshake syscall: Connection reset by peer
I'm probably looking in the wrong place.
Thanks.
1 - 100 of 456 matches
Mail list logo
