On 2025-01-15, Joel Carnat wrote:
> Hello,
>
> Playing with my local unbound(8) daemon regarding encrypted DNS queries,
> I could enable DoT (DNS-over-TLS) without issue. But when it came to DoH
> (DNS-over-HTTPS), it didn't work at all. To have DoH enabled, unbound(8)
> needs to be compiled with
On Sat, Nov 16, 2024 at 11:23:59PM +, ckeader wrote:
>
> > I guess you're using local zones for this - I would look into using RPZ
> > instead. I haven't tried it myself but hopefully this will get you started:
> >
> > https://blog.nlnetlabs.nl/response-policy-zones-in-unbound/
>
> Thanks,
> I guess you're using local zones for this - I would look into using RPZ
> instead. I haven't tried it myself but hopefully this will get you started:
>
> https://blog.nlnetlabs.nl/response-policy-zones-in-unbound/
Thanks, Stuart. I can see the advantage of this approach and it looks like
some
On 2024-11-16, ckeader wrote:
>
> Since the upgrade to 7.6, I have been unable to use unbound in the
> previous configuration.
>
> root@router ~ # rcctl -df start unbound
> doing _rc_parse_conf
> unbound_flags >-c /var/unbound/etc/unbound.conf<
> doing rc_check
> unbound
> doing rc_pre
> /var/unbo
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
> Am 20.09.2024 um 14:03 schrieb Stuart Henderson :
>
> On 2024-09-20, Stuart Henderson wrote:
>> On 2024-09-20, Mike Fischer wrote:
>>>
[snip]
>> Well that's interesting.
>>
>> Querying any of the auth servers directly with host or dig, I do get
>> what looks like a sensible response to
> Am 20.09.2024 um 13:56 schrieb Stuart Henderson :
>
> On 2024-09-20, 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 respond for A (rather than an empty NO
> 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
> Am 20.09.2024 um 13:08 schrieb Otto Moerbeek :
>
> On Fri, Sep 20, 2024 at 12:45:08PM +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 respond for
On 2024-09-20, Stuart Henderson wrote:
> On 2024-09-20, 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 respond for A (rather than an empty NOERROR
>>> response
On 2024-09-20, 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 respond for A (rather than an empty NOERROR
>> response).
>
> I agree, that is probably the root cause.
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 respond for A (rather than an empty NOERROR
:> response).
:
:I agree, t
On Fri, Sep 20, 2024 at 12:45:08PM +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 respond for A (rather than an empty NOERROR
> > response).
>
> I agree
> 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 respond for A (rather than an empty NOERROR
> response).
I agree, that is probably the root cause.
So that would cause host(1) to abort looki
>From what you've shown I can only assume the auth servers are broken
and probably refusing to respond for A (rather than an empty NOERROR
response).
-only is a somewhat rare case and IPv6 has only been supported in
DNS since 2008 or so, it takes time to get the bugs worked out
especially in c
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
They seem to be using extremely short-lived signatures, probably created
by an online-signer.
$ dig +short ns slack.com
ns-1493.awsdns-58.org.
ns-166.awsdns-20.com.
ns-1901.awsdns-45.co.uk.
ns-606.awsdns-11.net.
$ TZ=UTC dig @ns-1493.awsdns-58.org. +norec +dnssec +multiline +nocrypto
slack.com
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
Without seeing your unbound.conf, any of the following configurations may
be relevant.
I use nodefault in conjunction with a stub zone, but per Todd's reply,
transparent may be appropriate depending on your configuration:
local-zone: "10.in-addr.arpa." nodefault
If DNSSEC is not configured on yo
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-addr.arpa.' to our
> two i
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
> unbound manual page says:
>
> "roo
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 are two:
> 1) I'm not able to
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 resolve.
> ...
>>
>> Increase log leve
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:4802:32::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: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 logs? Otherwise it's just a
>
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 it from contacting
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.
>
>
> 2023-01-11 20:06 GMT, 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 succesive upa
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 GMT
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
On 2022-05-29, Georg Pfuetzenreuter wrote:
> This is a multi-part message in MIME format.
> --ixL2X1ILWFWJlrgqgqUkZvxl
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Hi,
>
> I just installed a fresh copy of OpenBSD 7.1 and copied my worki
Did you miss out
# unbound-control-setup
perhaps?
--- I said:
> Thinking that an absolutely empty unbound.conf file would be the
> simplest, I tried it. It doesn't work.
Nope. That is not true.
I don't know how it happened, but my box wound up without a default route.
An absolutely empty unbound.conf works just fine.
Thanks,
Ken
CONFID
I said:
> Thinking that an absolutely empty unbound.conf file
> would be the simplest, I tried it. It doesn't work.
However, unbound-checkconf likes it just fine.
$ unbound-checkconf /var/unbound/etc/unbound.conf
unbound-checkconf: no errors in /var/unbound/etc/unbound.conf
CONFIDENTIALIT
--- I asked:
> What I would like to do now is make the *simplest
> possible* unbound.conf file and get it working.
Thinking that an absolutely empty unbound.conf file
would be the simplest, I tried it. It doesn't work.
Can anybody help me with the simplest possible
unbound.conf file???
Thanks,
On Fri, 10 Jul 2020 21:29:02 +
wrote:
> --- I asked:
> > What I would like to do now is make the *simplest
> > possible* unbound.conf file and get it working.
>
> Thinking that an absolutely empty unbound.conf file
> would be the simplest, I tried it. It doesn't work.
>
> Can anybody hel
On Fri, 10 Jul 2020 21:21:00 +,
wrote:
> Can anybody help me out with the *simplest possible* unbound.conf
> file, just to get it working???
The default config should be fine.
Also posting to multiple mailing lists at the same time is considered a
bad practice.
Cheers,
Daniel
On 2020-07-10 14:29, ken.hendrick...@l3harris.com wrote:
--- I asked:
What I would like to do now is make the *simplest
possible* unbound.conf file and get it working.
Thinking that an absolutely empty unbound.conf file
would be the simplest, I tried it. It doesn't work.
Can anybody help m
Use these directives also in unbound (see the pattern and choose what you
need, like 24.172.IN-ADDR.ARPA, to cover your 172.24.* reverse.
local-zone: "168.192.IN-ADDR.ARPA" nodefault
local-zone: "16.172.IN-ADDR.ARPA" nodefault
local-zone: "17.172.IN-ADDR.ARPA" nodefault
local-zone: "18.172.IN-AD
Hi,
On 09/07/2020 20:44, ken.hendrick...@l3harris.com wrote:
> stub-zone:
> name: 30.24.172.in-addr.arpa.
good
> stub-addr: 127.0.0.1@53053
> stub-zone:
> name: 2.168.192.in-arpa.arpa.
t
I appreciate your help!
Either you solved the previous problem telling me to put $ORIGIN in my BIND
zone files,
or I had made a mistake with the 'set port=number' command in nslookup.
In either case NSD is now working properly in both directions.
But Unbound is only working correctly in the forw
please disregard this. as expected, if one mentions 'typo' it is
inevitable that one will embarrass themselves profoundly. as it happens
i read the config too quickly and entirely wrongly.
On Thu, 9 Jul 2020 15:21:27 -0400, Amelia A Lewis wrote:
> On Thu, 9 Jul 2020 17:44:48 +, ken.hendrick.
On Thu, 9 Jul 2020 17:44:48 +, ken.hendrick...@l3harris.com wrote:
> name: 2.168.192.in-arpa.arpa.
^
It's a mystery, as well, why you would set up nsd (an authoritative
sever) if you're not delegating to it in the recursive/caching server.
But if you'
I deployed two changes in my PF config.
(1) Bigger Queue
I rearranged some queues and gave the queue holding the DNS traffic more
bandwidth and a higher qlimit on the affected interface.
bnd_flows = "1024"
bnd_qlimit = "1024"
guest_local = "850M"
queue guest_local parent guest_root bandwidth $
sd.org On Behalf Of Stuart
Henderson
Sent: Friday, 17 April 2020 3:05 PM
To: misc@openbsd.org
Subject: Re: Unbound Notice: "sendto failed: No buffer space available"
On 2020-04-16, William Ahern wrote:
> I'm no network administrator, but a 3% failure rate would be very high
>
On 2020-04-16, William Ahern wrote:
> I'm no network administrator, but a 3% failure rate would be very high on a
> physical interface. vlan4 is presumably the interface your Apple device
> passes through, right? Investigate why all the dropped packets. Start with
> your queuing rules: examine/ena
On Thu, Apr 16, 2020 at 10:28:55AM +0200, Ben wrote:
> > AFAIU, ENOBUFS happens when the NIC transmit queue is full. Have you looked
> > at the interface statistics to see if there are many dropped packets? Try,
> > e.g.,
> >
> > $ netstat -ni
>
> NameMtu Network Address I
> AFAIU, ENOBUFS happens when the NIC transmit queue is full. Have you looked
> at the interface statistics to see if there are many dropped packets? Try,
> e.g.,
>
> $ netstat -ni
NameMtu Network Address Ipkts IfailOpkts
Ofail Colls
lo0 32768
On Wed, Apr 15, 2020 at 10:53:49PM +0200, Ben wrote:
> I have exactly one device - an Apple smartphone - within one of the
> subnets, that Unbound is not able to send "some" data. The log tells us
> "sendto failed: No buffer space available". Beside the error message,
> the device seems to work wi
Dear Jordan,
thanks for your email.
On 12.12.19 20:54, Jordan Geoghegan wrote:
>> OpenBSD is a guest VM on a debian buster host using virtual e1000
>> network card ("Intel 82540EM" driver in openbsd). No firewall
>> in between. The VM is a tor-exit node.
>
> I've heard others recommend using th
On 12 Dec at 20:54, Jordan Geoghegan wrote:
>
>
> On 2019-12-12 06:21, Winter Paulson wrote:
> > Hello,
> >
> > I'm also experiencing the "Host is down" problem:
> >
> > unbound: [85343:0] error: recvfrom 361 failed: Host is down
> >
> > Running openbsd 6.6 (GENERIC.MP), current syspatch,
> >
On 2019-12-12 06:21, Winter Paulson wrote:
Hello,
I'm also experiencing the "Host is down" problem:
unbound: [85343:0] error: recvfrom 361 failed: Host is down
Running openbsd 6.6 (GENERIC.MP), current syspatch,
native unbound as a full resolver, pf disabled.
OpenBSD is a guest VM on a deb
Hello,
I'm also experiencing the "Host is down" problem:
unbound: [85343:0] error: recvfrom 361 failed: Host is down
Running openbsd 6.6 (GENERIC.MP), current syspatch,
native unbound as a full resolver, pf disabled.
OpenBSD is a guest VM on a debian buster host using virtual e1000
network card
Replying to my own thread as it was pointed out that I neglected to add some
information.
OpenBSD 6.5 (GENERIC.MP) #7: Wed Nov 20 23:21:48 MST 2019
Native unbound (latest syspatch)
Bge interfaces running on an LACP trunk with IPv4 and IPv6 addresses.
NameMtu Network Address
Hi Joe,
The domain whatsapp.com doesn't guarantee integrity to you (they have dnssec
turned off, at least last I checked). It's possible that someone got in your
middle and inserted a bogus record. This being said I'M ignorant to the fact
that nlnetlabs have changed their internal database, so
Thanks, Andre
I reverted my change to rc.subr
I tried what you suggested and it seemed to work,
(believe it or not,
I tried somehting similar this morning but i must have had typo in my
syntax)
Thanks Tom Smyth
On Thu, 25 Oct 2018 at 13:53, Andre Stoebe wrote:
>
> Use "rcctl set unbound timeout 30
Use "rcctl set unbound timeout 300", which sets "unbound_timeout=300" in
rc.conf.local. The variables are documented in rc.d(8).
Regards
André
Hello,
to resolve the rcctl start unbound timeout issue,
I tried increasing daemon_timeout value in multiple files (and failing)
finally i edited line 300 of /etc/rc.d/rc.subr
- [ -z "${daemon_timeout}" ] && daemon_timeout=30
+ [ -z "${daemon_timeout}" ] && daemon_timeout=300
--
Hi Predrag,
Thanks for taking a look,
im running
OpenBSD fns1.ogmaconnect.com 6.4 GENERIC.MP#364 amd64
It would appear that the killed message was due to insufficient memory on
the
machine,
However the issue with rcctl start unbound still remains despite the
increase
of the ram on the vm
ok so
Tom Smyth wrote:
> Hello all,
> unbound-checkconf "Killed" when cheking a large local zone config file
> rcctl start unbound fails because of the above command failing
>
> background
>
> we were migrating our dns filtering from one platform to openbsd
> so we have a basic unbound configuration f
Hi Rupert,
On Thu, 22 Mar 2018 15:49:55 -0400 Rupert Gallagher wrote:
> Why reaching to /etc/unbound.conf when the binary was compiled
> for /var/unbound/etc/unbound.conf?
Yep;- it uses the default, so nothing needs setting. Removing the
config file from /etc/rc.conf* & /etc/rc.d/unbound works OK
On Thu, Mar 22, 2018 at 22:02, Edgar Pettijohn wrote:
> It is chroot'd to /var/unbound so it looks for /etc/unbound.conf from
that false root. At least that is my best guess. What is in
/etc/rc.conf.local?
> I have the following:
unbound_flags=-c /var/unbound/etc/unbound.conf
> I'm not sure why
On Mar 22, 2018 4:19 PM, "Todd C. Miller" wrote:
>
> On Thu, 22 Mar 2018 16:02:56 -0500, Edgar Pettijohn wrote:
>
> > It is chroot'd to /var/unbound so it looks for /etc/unbound.conf from
> > that false root. At least that is my best guess. What is in
> > /etc/rc.conf.local?
> >
> > I have the
On Thu, 22 Mar 2018 16:02:56 -0500, Edgar Pettijohn wrote:
> It is chroot'd to /var/unbound so it looks for /etc/unbound.conf from
> that false root. At least that is my best guess. What is in
> /etc/rc.conf.local?
>
> I have the following:
> unbound_flags=-c /var/unbound/etc/unbound.conf
>
> I
On 03/22/18 14:49, Rupert Gallagher wrote:
This happens on plain 6.1.
ls -l ls -l /var/unbound/etc/unbound.conf
-rw-r--r-- 1 root wheel 4309 Mar 21 13:06 /var/unbound/etc/unbound.conf
doas rcctl start unbound
unbound(ok)
(log)
Mar 22 20:29:34 unbound[71209:0] info: server stats for t
On Thu, 29 Sep 2016, Gregory Edigarov wrote:
> Hi,
>
> Need an advice.
>
> I have a bgp router with 3 interfaces:
>
> em0 (xxx.yyy,zzz.1/24),
> em1, em2 - looking at uplinks
>
> bgp is up and running, packets are forwarded just fine. also there is nsd,
> listening on both em1,em2 serving my re
after all, it revealed to be just fiber connection fucked up, and
causing the enormous packet drops. sorry for the noise
On 29.09.16 10:48, Gregory Edigarov wrote:
Hi,
Need an advice.
I have a bgp router with 3 interfaces:
em0 (xxx.yyy,zzz.1/24),
em1, em2 - looking at uplinks
bgp is up an
Hi Gregory,
On Thu, 29 Sep 2016 14:30:05 +0300 Gregory Edigarov wrote:
> $ dig openbsd.org @127.0.0.1
> ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> openbsd.org @127.0.0.1
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
Debian isn't OpenBSD..
This means unbound i
Hi Gregory,
On Thu, 29 Sep 2016 14:06:28 +0300 Gregory Edigarov wrote:
> I cannot use interfaces em1 and em2, it's where nsd is listening.
On OpenBSD, NSD listens on port 53,
and unbound sends queries out from various ports > 1023
On OpenBSD, there's no conflict.
An 'outgoing-interface: ' i
Tried to play around with ports nsd/unbound listens on?
//Мэксб
> On 29 sep. 2016, at 09:48, Gregory Edigarov wrote:
>
> Hi,
>
> Need an advice.
>
> I have a bgp router with 3 interfaces:
>
> em0 (xxx.yyy,zzz.1/24),
> em1, em2 - looking at uplinks
>
> bgp is up and running, packets are forwarded
Hi Craig,
On 29.09.16 13:28, Craig Skinner wrote:
Hi Gregory,
On Thu, 29 Sep 2016 10:48:37 +0300 Gregory Edigarov wrote:
em0 (xxx.yyy,zzz.1/24),
em1, em2 - looking at uplinks
...
outgoing-interface: 0.0.0.0
Removing the outgoing-interface line would probably resolve it.
Adding th
Hi Gregory,
On Thu, 29 Sep 2016 10:48:37 +0300 Gregory Edigarov wrote:
> em0 (xxx.yyy,zzz.1/24),
> em1, em2 - looking at uplinks
> ...
>
> outgoing-interface: 0.0.0.0
Removing the outgoing-interface line would probably resolve it.
Adding this private-addres line might help too:
priva
corrected unbound.conf snippet, just to be sure I am properly understood
On 29.09.16 10:48, Gregory Edigarov wrote:
Hi,
Need an advice.
I have a bgp router with 3 interfaces:
em0 (xxx.yyy,zzz.1/24),
em1, em2 - looking at uplinks
bgp is up and running, packets are forwarded just fine. also t
>This was removed because the version of dig(1) in base uses pledge(2)
>to make restrictions on system calls - in this case it only allows port
>53 connections.
>
>(Technically it could be changed to use a different pledge if -p
>is specified, I'm not sure if this is desirable though).
That can ce
On 2016-09-08, Martin Hanson wrote:
> Hi,
>
> Since I upgraded to OBSD 6.0 I have had some problems with Unbound and
> dnscrypt-proxy.
>
> Normally I would troubleshoot by using "dig" to request directly to
> dnscrypt-proxy, but for some reason (I don't know) the "-p" option has
> been removed and
09.09.2016, 06:14, "Lists" :
> Does unbound.conf have the following setting?
>
> do-not-query-localhost: no
Yes, it has the setting.
Does unbound.conf have the following setting?
do-not-query-localhost: no
Unbound will not query the local host without that set to no.
> On Sep 8, 2016, at 5:49 PM, Martin Hanson
wrote:
>
> Hi,
>
> Since I upgraded to OBSD 6.0 I have had some problems with Unbound and
dnscrypt-proxy.
>
> Normal
Sent from my iPhone
> On Sep 8, 2016, at 5:49 PM, Martin Hanson
wrote:
>
> Hi,
>
> Since I upgraded to OBSD 6.0 I have had some problems with Unbound and
dnscrypt-proxy.
>
> Normally I would troubleshoot by using "dig" to request directly to
dnscrypt-proxy, but for some reason (I don't know) the
On 11/03/16 04:15, Stuart Henderson wrote:
On 2016-03-08, Brian Conway wrote:
Are you using pf queues? I most frequently see that happen when there's no
space left in a queue. `pfctl -v -s queue`
This is the most likely cause.
Other than that, very busy unbound servers may also need
net.inet.
On 2016-03-08, Brian Conway wrote:
> Are you using pf queues? I most frequently see that happen when there's no
> space left in a queue. `pfctl -v -s queue`
This is the most likely cause.
Other than that, very busy unbound servers may also need
net.inet.udp.sendspace to be raised.
On 2016-03-08, Otto Moerbeek wrote:
> And do not forget to set the class of the user _unbound to unbound:
This has been done by default for installations since 5.7 but might be
missing on older installs.
On Wed, Mar 09, 2016 at 02:04:10PM +0100, Marko CupaÄ wrote:
> On Tue, 8 Mar 2016 12:24:59 +0100
> Otto Moerbeek wrote:
>
> > Give unbound more file descriptors; put in login.conf:
> It's already there, by default on 5.8.
>
> > And do not forget to set the class of the user _unbound to unbound:
>
On Tue, 8 Mar 2016 12:24:59 +0100
Otto Moerbeek wrote:
> Give unbound more file descriptors; put in login.conf:
It's already there, by default on 5.8.
> And do not forget to set the class of the user _unbound to unbound:
It's already set by default on 5.8.
On Tue, 8 Mar 2016 07:36:06 -0600
Bri
On Tue, Mar 08, 2016 at 08:38:13AM +0100, Marko Cupa?? wrote:
> Hi,
>
> I have 5.8 i386 box as my home network gateway, with unbound as a
> resolver for local LAN. I am getting these in my log:
>
> Mar 8 08:21:42 kerber unbound: [24074:0] notice: sendto failed: No
> buffer space available
> Mar
Are you using pf queues? I most frequently see that happen when there's no
space left in a queue. `pfctl -v -s queue`
Brian Conway
On Mar 8, 2016 1:52 AM, "Marko CupaÄ" wrote:
> Hi,
>
> I have 5.8 i386 box as my home network gateway, with unbound as a
> resolver for local LAN. I am getting th
Raf Czlonka wrote:
>How about simply disabling unbound at boot: [...]
>and then have something like this in your /etc/hostname.if:
Yes, I ended up disabling ntpd and un-enabling unbound in
/etc/rc.conf.local and then using:
/etc/rc.d/unbound -f start && /etc/rc.d/ntpd -f start
at the end of the
Setting 'verbosity: 0' in config will do it, but I don't think it
should be necessary. At the very least putting the 'remote address'
on the same line as the sendto notice would give syslog something of
a chance to reduce the number of lines.
Could you ask for suggestions on unbound-users please?
On 1/14/2016 2:26 AM, Philippe Meunier wrote:
>[snip]
> The problem is that unbound(8) generates such a pair of messages up to
> 20 times for each root server! That's 2 lines * 20 times * 13 root
> servers = 520 lines that end up going to syslog. Then 15 seconds
> later ntpd(8) tries again and yo
On Thu, Jan 14, 2016 at 07:26:32AM GMT, Philippe Meunier wrote:
> Hello,
>
> I have a laptop computer configured to use unbound(8) and ntpd(8) but
> which does not have any network interface configured by default
> (except lo0, obviously) since which interface needs to be configured
> and how depe
> I solved this by commenting out the file in /etc/changelist.
Thanks, I will do that.
>> I'm running a DNS resolver using Unbound (OpenBSD 5.8-stable AMD64) with
>> the auto-trust-anchor-file option set. This results in daily updates of
the
>> /var/unbound/db/root.key file (only comments are ch
>> I'm running a DNS resolver using Unbound (OpenBSD 5.8-stable AMD64) with
>> the auto-trust-anchor-file option set. This results in daily updates of
the
>> /var/unbound/db/root.key file (only comments are changed). Unfortunately
>> this file is also checked via the security(8) script, which resul
1 - 100 of 211 matches
Mail list logo
