Re: nsd listening on localhost is zone transfer possible transfer ?

2023-08-05 Thread Paul de Weerd
On Fri, Aug 04, 2023 at 06:23:48PM +0100, Shadrock Uhuru wrote:
| hi everyone
| i have unbound setup on port 53
| and nsd listening on localhost port 53530
| i have set up another dns server as a secondary
| am i correct to assume that i can't zone transfer because
| as the nsd's are listening on localhost
| the primary can't reach the secondary ?
| 
| i have these errors on the primary
| error: xfrd: zone 1.10.10.in-addr.arpa: max notify send count reached, 
10.10.1.5 unreachable
| error: xfrd: zone forwardzone: max notify send count reached, 10.10.1.5 
unreachable

Your question isn't quite clear .. where is this other dns server
located?  Is it on the same network?

If you have NSD only listening on localhost, I'm not sure by which
logic you concluded that a secondary nameserver would be able to talk
to it at all, let alone do zone transfers?

At any rate, IP addresses in the 10/8 range are free - you can use
more than one without incurring a cost.  Then configure your NSD to
listen to the additional address and transfer from there.  If you have
IPv6, this will probably even apply to globally routable addresses.

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
 http://www.weirdnet.nl/ 



Re: Mouse does not work

2023-08-05 Thread Chris Bennett
On Fri, Aug 04, 2023 at 05:33:48PM +0200, Karel Lucas wrote:
> dmesg:
> ...
> uhub5 at uhub0 port 1 configuration 1 interface 0 "NEC hub" rev 2.00/1.00
> addr 2
> uhidev0 at uhub5 port 1 configuration 1 interface 0 "Logitech HID compliant
> keyboard" rev 1.10/1.80 addr 3
> uhidev0: iclass 3/1
> ukbd0 at uhidev0: 8 variable keys, 6 key codes
> wskbd0 at ukbd0: console keyboard
> uhidev1 at uhub5 port 1 configuration 1 interface 1 "Logitech HID compliant
> keyboard" rev 1.10/1.80 addr 3
> uhidev1: iclass 3/0, 2 report ids
> ...
> uhub6 at uhub5 port 4 configuration 1 interface 0 "ATEN International
> product 0x8021" rev 1.10/1.00 addr 4
> uhidev2 at uhub6 port 1 configuration 1 interface 0 "Logitech USB Receiver"
> rev 2.00/12.11 addr 5
> uhidev2: iclass 3/1
> ukbd1 at uhidev2: 8 variable keys, 6 key codes
> wskbd2 at ukbd1 mux 1
> uhidev3 at uhub6 port 1 configuration 1 interface 1 "Logitech USB Receiver"
> rev 2.00/12.11 addr 5
> uhidev3: iclass 3/1, 8 report ids
> ums0 at uhidev3 reportid 2: 16 buttons, Z and W dir
> wsmouse0 at ums0 mux 0
> ...
> 
  ^
This is not a dmesg.

People are helping you. People want to help you. People are busy.
People might stop wanting to help you. Don't let that happen.

Please do the following, without delay.
Read the entire FAQ page on the website.

man afterboot
man intro. It also suggests additional intro pages.
If you don't know how to access those or otherwise need to `man man`
Read all of those.
Look through all of the default installed directories `man hier`
See which ones you know, which ones you don't 

Every entry on the dmesg refers to a driver (remove the number at the
end) run man on each of those too. Don't worry if you don't understand
everything right now.

Search for existing answers at marc.info. It has many mailing lists for
many OS's. It is traditional to refer to existing previous mailing-list
posts using that URL for that message from marc.info

Etc.

When you get a response here: RTFM
It means you have not done your homework first.

If you don't like reading plain text for manual pages, you can convert
those to many different outputs. HTML, pdf, etc. I leave that for you to
discover how either through the manual pages or from searching the
mailing lists.

Subscribe to all of the mailing lists ports@, misc@, tech@.
Read tech@. Do not post there until you understand what it is for.

Personality and mood come through strong here.
Sometimes dogs ignore you, bark happily at you, bark menacingly 
at you, slobber all over you or bite you with the whole pack.

These mailing lists reflect real life and real people.
IMHO, I think that that is a good thing.

OK I just woke up. Coffee will help greatly.
Then I myself have many manpages to read and cogitate.
Enjoy.

-- 
Chris Bennett



improve wireguard logging, please?

2023-08-05 Thread Harald Dunkel

Hi folks,

would it be possible to improve wireguard logging in OpenBSD?
A message like

Receiving handshake initiation from peer 17

in /var/log/messages of 2 weeks ago isn't really helpful. Who
the heck was peer 17?

For forensic measures in case of an incident I need the peers
public key at that time. The first 16 or 10 chars should do. The
current contents of /etc/hostname.wg0 or some internal numbering
in the kernel is insufficient.


Regards
Harri