Re: unbound resolving 10.in-addr.arpa

[John Clendenen]

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 your local domains:

domain-insecure: "10.in-addr.arpa."

To allow queries from localhost (regardless of using 127.0.0.1 or not):

do-not-query-localhost: no

On Thu, Dec 14, 2023 at 3:19 PM Todd C. Miller  wrote:

> 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 internal nameservers that are authoritative for the 10.in-addr.arpa
> > zone.
>
> You haven't said what you have tried so far, but unbound will ignore
> RFC 1918 PTR queries by default.  You need to use things like:
>
> local-zone: "1.1.10.in-addr.arpa." transparent
>
> See the description of "transparent" in the unbound.conf manual for
> more info.
>
>  - todd
>
>

Re: unbound resolving 10.in-addr.arpa

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

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

Re: unbound resolving 10.in-addr.arpa

[Todd C . Miller]

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 internal nameservers that are authoritative for the 10.in-addr.arpa
> zone.

You haven't said what you have tried so far, but unbound will ignore
RFC 1918 PTR queries by default.  You need to use things like:

local-zone: "1.1.10.in-addr.arpa." transparent

See the description of "transparent" in the unbound.conf manual for
more info.

 - todd

unbound resolving 10.in-addr.arpa

[Lyndon Nerenberg (VE7TFX/VE6BBM)]

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 authoritative for the 10.in-addr.arpa
zone.

Someone, *please*, show me the light.

And no, static zone files are not an option at this point.  I need
unbound to forward the requests as described.  I really don't want
to have to install named just to get this functionality.

Thanks!

--lyndon

Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map

[Laurent CARON]

Hi Wouter,

Please keep in mind the storage controler (Perc H755) is _not_ yet 
supported by OpenBSD.


Cheers,

Laurent

Le 14/12/2023 à 15:43, Wouter Prins a écrit :

Thank you Laurent and Claudio,

We have an identical setup (hardware specs), i am sure we need this in 
the near future. :)


/Wouter

On Thu, Dec 14, 2023 at 3:08 PM Claudio Jeker 
 wrote:


On Tue, Nov 28, 2023 at 05:55:03PM +0100, Laurent CARON wrote:
>
> Le 28/11/2023 à 17:46, Claudio Jeker a écrit :
> > The problem is that the symbol nkmempages moved into .bss and
is therefor
> > no longer modifiable by config(8). I think you can still use
ukc via
> > boot -c to alter it (but that is not sticky).
> >
> > The alternative is to set "option NKMEMPAGES=131072" in your
GENERIC
> > config file (or option NKMEMPAGES_MAX=131072). See also
options(4).
> >
> > Long term is the fix this proper. All of this was built when
computers had
> > 100MB of memory not 100GB.
> >
>
> Got it. Thanks.
>
> It means I'll stick with this kernel for now and see if it helps
(it seems
> promising for now).
>
> Is there a way you can submit this patch (option
NKMEMPAGES=131072) to the
> current branch ?

A better calculation logic for nkmempages was added to -current.
On most 64bit archs nkmempages now scales to much larger values.

See https://marc.info/?l=openbsd-cvs=170255507530513=2
 for more
details.

-- 
:wq Claudio




--
Wouter Prins
w...@null0.nl

Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map

[Wouter Prins]

Thank you Laurent and Claudio,

We have an identical setup (hardware specs), i am sure we need this in the
near future. :)

/Wouter

On Thu, Dec 14, 2023 at 3:08 PM Claudio Jeker 
wrote:

> On Tue, Nov 28, 2023 at 05:55:03PM +0100, Laurent CARON wrote:
> >
> > Le 28/11/2023 à 17:46, Claudio Jeker a écrit :
> > > The problem is that the symbol nkmempages moved into .bss and is
> therefor
> > > no longer modifiable by config(8). I think you can still use ukc via
> > > boot -c to alter it (but that is not sticky).
> > >
> > > The alternative is to set "option NKMEMPAGES=131072" in your GENERIC
> > > config file (or option NKMEMPAGES_MAX=131072). See also options(4).
> > >
> > > Long term is the fix this proper. All of this was built when computers
> had
> > > 100MB of memory not 100GB.
> > >
> >
> > Got it. Thanks.
> >
> > It means I'll stick with this kernel for now and see if it helps (it
> seems
> > promising for now).
> >
> > Is there a way you can submit this patch (option NKMEMPAGES=131072) to
> the
> > current branch ?
>
> A better calculation logic for nkmempages was added to -current.
> On most 64bit archs nkmempages now scales to much larger values.
>
> See https://marc.info/?l=openbsd-cvs=170255507530513=2 for more
> details.
>
> --
> :wq Claudio
>
>

-- 
Wouter Prins
w...@null0.nl

Re: OpenBSD SMP - BGPd - send_rtmsg: action 1, prefix A.B.C.D/24: No buffer space available - panic: malloc: out of space in kmem_map

[Claudio Jeker]

On Tue, Nov 28, 2023 at 05:55:03PM +0100, Laurent CARON wrote:
> 
> Le 28/11/2023 à 17:46, Claudio Jeker a écrit :
> > The problem is that the symbol nkmempages moved into .bss and is therefor
> > no longer modifiable by config(8). I think you can still use ukc via
> > boot -c to alter it (but that is not sticky).
> > 
> > The alternative is to set "option NKMEMPAGES=131072" in your GENERIC
> > config file (or option NKMEMPAGES_MAX=131072). See also options(4).
> > 
> > Long term is the fix this proper. All of this was built when computers had
> > 100MB of memory not 100GB.
> > 
> 
> Got it. Thanks.
> 
> It means I'll stick with this kernel for now and see if it helps (it seems
> promising for now).
> 
> Is there a way you can submit this patch (option NKMEMPAGES=131072) to the
> current branch ?

A better calculation logic for nkmempages was added to -current.
On most 64bit archs nkmempages now scales to much larger values.

See https://marc.info/?l=openbsd-cvs=170255507530513=2 for more
details.

-- 
:wq Claudio