Hacker News Reader

Comment by quesera | Hacker News Reader

This is a good summary.

I run both authoritative (nsd) and resolving (unbound) nameservers. They require literally zero maintenance. Before nsd, I ran djbdns, which also required zero maintenance. I've run BIND, back in the dark ages. Rumor has it that BIND doesn't suck any more, but I've seen no reason to confirm.

If you are able keep sshd up and running on your hosted or colo'ed server, you have the skills required to run a nameserver reliably. It's that easy. I recommend nsd and/or unbound.

If the article does not persuade you that you want to do so, then don't bother. But if you do want to, don't be dissuaded by assuming it will be difficult.

View on HN

I was hacked one single time in my entire 25 year long career. Someone hacked a bind server I was running and installed some sort of bot node. That was in the 90’ies.

The pi-hole I was running on Raspberry Pi got hacked. I only noticed the traffic when something unusual showed up on my node app console

Was the Pi running public facing services? How did this occur?

No it was internal facing behind cable router. There must have been some vulnerability in the pinhole or os. They breached the router

That feels weird somehow. I highly doubt PiHole is the culprit. If you're only using it internal to your LAN for DNS there is no way someone from outside can touch it. You most likely have other, bigger problems with your network (perhaps the WiFi password was discovered by someone, or you're exposing other vulnerable services to the web directly).

Accually there's several ways, XSS for example.

But I agree that there's something other that's not ok. Compromised client (probably a computer) or a compromised router is my guesses.

Agreed, I managed to achieve this by port forwarding port 53 in my router settings. This allows hackers to enlist you in their DNS amplification attacks so please never do this.

Yikes. As much as I want to look into PiVPN, things like this give me pause.

Wireguard is the only service that I bother to expose.

It's stealth and has mitigations for DOS attacks.

Do you have a good guide for this? I sort of grok that the Pi (server) setup is different from the devices (clients) that will use it, but it’s always good to check assumptions.

I already run PiHole, but I might run this on a different box just to keep things simple.

Also, last I checked - port 51820 is reasonably well known, is it safe to use this default when forwarding traffic?

To be fair, that was probably due to something else than the DNS stack. For example, i assume the web interface downloads countless dependencies from a 3rd party repo (such as npmjs), any of which could have been victim of a hostile takeover.

DNS is nowadays very robust and secure, and if you have unattended-upgrades configured there's literally zero reason to be frightened by DNS.

To be fair, that pretty much describes every daemon from the 90s, and the linux kernel itself.

What version of unbound are you running? With our traffic load we restart unbound 1.13.x daily to "fix" a memory leak.

I've run relatively loaded unbound in the past - I would suggest to use minimum num-threads with which a single thread uses less than 50% CPU at peaks. And set number of slab to the same value (if it is power of 2) or lower. High number of slabs increases memory usage (may be it can grow over long time because of fragmentation, but I've not noticed this). Unbound Howto Optimize [1] suggests to set num-threads equal to number of cores but IMHO it makes sense only if: server runs no other software except Unbound (even in this case some cores will be utilized by the kernel so better give to Unbound less than total core count) and it has more than enough RAM so possible memory fragmentation is not a concern.

[1] https://www.nlnetlabs.nl/documentation/unbound/howto-optimis...

unbound-1.14.0 (newest).

But I should have qualified -- I run a caching resolver for use by half a dozen users (so about 20 devices). Load is negligible, but it works perfectly! YMMV.

As an added benefit, my unbound instance is also faster than 1.1.1.1, 8.8.8.8, or my ISP's resolver farm.

It is a good summary. My first reaction was "for pain and suffering". If you are hosting a server in some cloud provider, you probably still want to have your primary DNS not on that server. Yes, there are caveats.

I've been running my own DNS servers for 25+ years (BIND, though I did mess around with nsd and unbound for a bit locally.) It is basically painless, set-and-forget, other than the usual OS/package updates.

How much difficulty is added by DNSSEC?

I don't know how difficult it is to set up DNSSEC, but I do know I had to disable it on my internal BIND DNS server because it wasn't resolving google.com ("query failed (broken trust chain) for www.google.com/IN/A at query.c"):

I had to modify my default BIND options to disable DNSSEC:

options {

  dnssec-enable no;

  dnssec-validation no;

If you want DNSSEC to work, be sure you set up NTP and that it's working properly.

Also, NAT64 breaks DNSSEC (by design), so some exclusion rules are needed.

In late 2019 I scanned Fortune 500 for DNSSEC on their top domain, exactly one entity was using it. At the time azures stance on dnssec support was that https certs should suffice.

I think it’s a dead tech.

You haven't lived, until you cannot update the time via ntp, because no dns, because dnssec records aren't valid, because the time is wrong....

This dnssec/ntp dependency loop is absurd, and it is incomprehensible that ntp/dns can break this way.

Could you fix that? I've had mixed results trying to resolve such NTP related issues.

I think using IPs for NTP servers, or disabling dnssec are your only options.

Both show how silly it all is, IMO.

Quick, easy project! I did it just now (finding a list of F500 domains was the hardest part), and 9% of the Fortune 500 is signed.

Not at all … nowadays.

In fact, I run my own private Internet complete with DNSSEC for my white lab.

I used Bind v9.16+ and wrote some bash tools to generate in a flexible manner the named configuration files.

Can generate private root servers, private TLD, split-horizon, bastion, and hidden-master.

link to generate named configuration files.

https://github.com/egberts/easy-admin/tree/main/500-dns

adding DNSSEC validation isn't hard (a few options), but as others has commented one have to be a bit aware that dnssec validation might then fail from time to time. Validating other peoples security setup mean occasionally that people mess up and validation fails. I have been running with validation on 10-20 years, and maybe once a year I notice a service that is down because failing validation. It is a bit like expired certificates on https back in the days before most sites started to use automation for renewing.

Adding DNSSEC to a domain name is more work. You need a registrar that support it, and then depending on what DNS server program you are running you might need to install a signer, a key storage, monitoring and scripts that talks between the different parts of the chain. I have heard that the latest version of bind might now ship with all the required parts built in, but I have yet to test it. It a bit far yet from simply uncommenting an option, and the protocols for talking with registrars is being actively discussed and worked on during technical conferences.

Not much but you should have a good grasp first, and the implications (easy to add, tougher to remove)

There are tools to automate resigning, but personally I just do it manually once a year for fun.

Less than the amount of difficulty added to driving a car that can only be adjusted by poking at a TV mounted some place where you aren't looking at the road.

Sure, fixing that squeaky door is "easy," but have you ever heard the adage that every home project involves three trips to the hardware store? There may be technical aspects that few of us can implement from scratch and on the first try, but at the same time I also don't know how to build a good broom. These concerns are not insurmountable, especially with the network effects of people being in the same boat. How easy is it to find a good handyman without asking anybody? You don't have to.

The question was about DNSSEC.

It's work, but it's not difficult. Documentation is good and some daemons like BIND take care of key rollovers automatically.

reason: offer users of your website the option of per packet encrypted DNS

CurveDNS is also not difficult to set up, so if you run your own authoritative DNS for your website, you can provide optional per packet encrypted DNS. There are very few websites that offer this option.^1 If every website provided this option, users would have a better alternative than DoT or DoH.^2 Neither DoT, DoH nor DNSSEC provide per packet encryption and they focus on DNS caches run by third parties, not authoritative servers.

1. One example is https://ianix.com

2. Users could query the authoritative servers directly using stub resolvers and/or recursive resolvers that support dnscurve protocol, such as dq and dqcache, respectively.

> Before nsd, I ran djbdns

Curious to know what made you switch (I still run djbdns).

No technical reason, djbdns is great and I wouldn't hesitate to run it again.

I did tire of building my own djbdns and daemontools packages. When I switched from qmail to Postfix, the others were collateral damage.

Ah, yeah, I was never a fan of daemontools either.

I actually run djbdns (both cache and authoritative) under systemd (not my fave thing, but the thing my OS comes equipped with) and it works fine.

The lack of native support for some record types (eg. IPV6) is a little bit of a pain, but it's manageable.

I still run djbdns as well, as both an authoritative server and a caching resolver.

The biggest downside to djbdns, to me, is its lack of DNSSEC support. There are patches available for that, but my distro doesn't package them and I haven't gotten around to making my own package to include them.

The next biggest is related: djbdns lacks direct support for some newer Resource Records (like type 257 CAA) in its data file. However, the data file does allow you to encode arbitrary records directly, it's just a hassle to do it and to verify correctness.

I also used to run bind back in the time, but now reading this article I just got up a container with powerdns seems quite easy to maintain

even just cashed is useful for normal users.

Reply on news.ycombinator.com