Egregoros · Phoenix Framework

Post

Remote status

feld

@dvl was just setting up a fresh nsnotifyd and noticed that the nsnotify2git requires dig but the package doesn't depend on bind-tools

edit: and maybe I guess it should depend on git, idk...

Replies

feld

@feld@friedcheese.us remote

@dvl @dch I used to have a custom script for committing to a Fossil repo

anyway, I've found a bug in nsnotifyd. Very annoying. Running in debug mode I see this happen when a NOTIFY comes through:

nsnotifyd 37606 - - feld.me IN SOA ? Host name lookup failure

Host name lookup failure? What the heck????

running under truss so I can see what it's doing:

2765: socket(PF_INET,SOCK_DGRAM|SOCK_CLOEXEC,0) = 5 (0x5)
2765: connect(5,{ AF_INET 127.0.0.1:53 },16) = 0 (0x0)
2765: sendto(5,"|\M-]\0\0\0\^A\0\0\0\0\0\^A\^Eet"...,38,0,NULL,0) = 38 (0x26)
2765: poll({ 5/POLLRDNORM },1,3000) = 1 (0x1)
2765: recvfrom(5,0x8210e31f0,512,0,0x8210e2720,0x8210e271c) ERR#61 'Connection refused'
2765: close(5) = 0 (0x0)

Why is it trying to connect to 127.0.0.1:53 ? There's nothing running there. (but the NOTIFY does come from 127.0.0.1 because I'm listening with nsnotifyd on 127.0.0.1)

my powerdns is not listening on 127.0.0.1 intentionally as there was a local_unbound on there

even if I pass -s to specify the server that should be used for SOA refresh checks, doesn't change behavior...

I must be the only person that has ever tried to use it in this specific type of configuration.

Replying to @feld@friedcheese.us

feld

@feld@friedcheese.us remote

@dvl @dch yeah confirmed in the code, it's "correct" by some definitions of correct :)

* In response to a notify: Make a non-recursive query using the * server that notified us. RFC 1996 paragraph 3.11.

feld

@feld@friedcheese.us remote

@dvl @dch when nsnotifyd gets a NOTIFY, it tries to query the server that notified it to check the SOA of the domain it was notified about

But if you put nsnotifyd on localhost, and your DNS server is on the same host but is *not* listening on localhost, the NOTIFY appears to come from localhost... so it queries 127.0.0.1:53 and fails, then doesn't do an AXFR

feld

@feld@friedcheese.us remote

@dvl @dch a missed NOTIFY could be bad depending on your use case for this, but if you also give it a list of domains instead of using wildcard mode it will automatically check to see if the serial in the SOA changed as a secondary mechanism

feld

@feld@friedcheese.us remote

@dvl @dch yeah I will reach out

feld

@feld@friedcheese.us remote

@dvl @dch I considered it but a different jail seemed heavy for such a tiny program. Especially as we can now start using service-jails. I really need to start investigating what is required to make the rc scripts Do The Right Thing so I can have these "service-jails" for lightweight apps which I'm not afraid to run on the host itself. Or just toss them all in a single jail and allow nested jails.

feld

@feld@friedcheese.us remote

@dvl @dch Personally I think everything should be in a service jail by default which essentially gets us the same experience as "cgroups" on Linux where we can be certain that when you stop a service all of its related PIDs (children, forks, etc) are correctly cleaned up as the jail is torn down. Simplifies a lot and we don't even need systemd.