I'm on 7.2 and I'm having a recurring DNS problem. If the link changes for some reason, mostly due to the ISP shuffling addresses around, DNS stops working. I can add opendns's servers to resolv.conf, and this fixes local resolution on the server but doesn't help the LAN clients.
Basically it's the 192.168.0.1:53 listener that gets stuffed up. Random twiddling used to fix it, but by the time I got it working I could never figure out what I did that worked.
Random twiddling that you can't accurately specify makes it more difficult for us to help you for sure.
Now I'm at a point where a reboot works for the first 5 to 15 minutes, then it dies again.
You say above that the problem co-incides with changes in the ISP link. Here you suggest that it dies 5 to 15 minutes after reboot without any ISP link changes. Only one of those must be true.
You ask "where to begin". The place to begin is to understand what is not working
before trying to fix it. Random fiddling just confuses you, and possibly makes things worse. If anything doesn't "just work", report via the bug tracker.
The think is, I'm actually an experienced admin but I'm a lot more comfortable with the traditional /etc/init.d model, all this runsv business freaks me out.
Don't let it freak you out. Stay calm, and do a little reading on supervise and runit (very similar programs). It'll be worth it in the long run.
Here's a good backgrounder:
http://thedjbway.org/daemontools.htmlWhat I'd like from the other forum people then is either
1) Some kind of "repair" system that will revert all the necessary DNS pieces to a known good config (Get 7.3 maybe?), or
config delete dnscache
config delete dnscache.forwarder
signal-event post-upgrade ; signal-event reboot
2) A basic breakdown of the architecture and what all the different bits are supposed to be doing
/etc/resolv.conf should direct all DNS queries to dnscache running on $LocalIP. That dnscache will forward all queries to another dnscache instance running on 127.0.0.2. That dnscache will forward queries for local names to tinydns on 127.0.0.1, or will resolve by asking the root name servers, and following delegation responses.
Can anyone help me with this? Has anyone else encountered similar problems?
The limited information you've provided suggests that the dnscache instance running on 127.0.0.2 isn't sending replies, except for 5 to 15 minutes after a reboot. That might happen if it was unable to log.
Reset the configuration as instructed, and open a bug report if you still experience problems. It would be a good idea for you to upgrade to 7.3 while you are at it.