Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: KittenDNS – Easy to setup, rule engine, LetsEncrypt compatible
107 points by cyansmoker on May 15, 2022 | hide | past | favorite | 31 comments
My goal was to create a DNS server as simple as the LDAP server I've been contributing to (glauth) and here it is: https://github.com/fusion/kittendns

A few things to know about it: - It is easy to configure using a Toml file - I am using it to bail my coredns/etcd instances when under attack - (yes, it also works as a service location server) - It comes with a simple, plain English, rule engine that doesn't do much at this point - It can be used with LetsEncrypt. I use it to retrieve certificates for my home servers. - RFC: all the nice ones :)

Anyway, feedback is welcome.




As I expected, HN delivers :)

I am going to try to address the input I've received so far:

# Licensing

Arg. How could I forget? The project is now licensed under Apache 2, which is compatible with the BSD licenses that @d_meeze listed. I've used it in many previous projects, including RootTools, and some projects were included in multiple commercial projects.

# Data in the configuration file

@drdaeman yes this is definitely with simplicity in mind. Right now, the updates the server accepts are limited to RFC2136 for LetsEncrypt's ephemeral TXT fields. If this becomes a necessary feature, I may do the same as with Glauth and introduce database plugins (SQLite would remain a light, but not as simple approach)

# Toml

Controversial as always. @dhzhzjsbevs, I found that if I provide an amply documented template file, folks find it easy to use. Is this a great configuration option? No, not it is not. I personally dislike all of them.

# Record reuse

@drdaeman making another valid point. It's going to be an easy fix, which is good.

# Split horizon DNS

And then we get to @jchw and one of my unstated goals. Right now, I am using the rule engine to alter responses. Obviously, a nice demo of what it can do, but a bad idea overall. Can anyone think of a way to implement split DNS other than filtering based on which interface the query came through? I do extract the query source's IP address, but this only tells me which server is recursing.


> Can anyone think of a way to implement split DNS other than filtering based on which interface the query came through?

https://en.m.wikipedia.org/wiki/EDNS_Client_Subnet


I hate you.

Or more accurately, I should hate you. Thanks for the reference, I am going to look into it as it's definitely something I would like to make work.


Are you talking about 'Views' which is common in BIND DNS configurations.

Serving different data on the same zone based in subnets of clients.


Looks helpful - have you chosen a license to release your parts under? So far it seems to build on BSD (GO) and some completely copyrighted extensions from (github.com/miekg/dns).

I have a work project this would help with, but at this point using it commercially feels a little shaky.


I still don't understand why people use toml. It's like someone said, man, yaml is great but it could be better and toml is the result.

Only yaml isn't great and toml is so much worse.

Sorry sounds off topic but the way you say it's "easy to configure" and include toml in the same sentence just gave me flashbacks to traefik.

Complicated toml is unreadable, if yaml isn't enough, you probably need json, not toml.


Toml is not much more than a standardization of how to represent trees with INI. INI has been in use since at least the 90's and it persists because it is easy to read and edit, and supports comments.

I actually find traefik quite nice to configure vs. the old conf disaster of apache. I've configured it by hand and also generated config by scripts with ease.

If you want to complain about a design on HN the better way is to suggest a design you think is superior.


I thought I did? https://json5.org/

Parsing json as a human is unambiguous and simple.

Parsing yaml and toml is full of ambiguity and readability problems depending on where you're reading it.

The only people who think json is a bad format are the type of people that think semicolons are the problem. They're just not.


As someone who has negative feelings about YAML: I like TOML.

This is however besides the point. I hate any format if it is misused. TOML is great for config files up to a certain complexity. It is not great for configuration files that should be code. If you feel your configuration file could use a configuration file, you might be doing it wrong.

TOML to me is an successor to INI, with support for lists and other things that can be useful for typical configurations. I have never had any configuration-syntax related issue with any tool that used TOML for configuration — YAML on the other hand...


I'll take YAML/TOML over JSON any day.

shrug


People who chose JSON for configuration are not to be trusted.


Official, meaningful tooling for yaml also doesn't exist. Parsing and emitting yaml does nothing for anyone until you can actually extract structures from the format.

The full yaml standard is also full of features no one ever actually uses in practice, but if you don't implement it, you are thusly not compliant with the specification.

If you read it, you'd go, "Wow, you can do that?" and "That's bad that you can do that."


There is a parser and producer for yaml in all the major languages. I mean, even

    perl -MYAML -E 'say YAML::LoadFile("filename.yaml")->{foo}{bar}'
what level of tooling do you mean?


And by YAML, some libraries implement YAML 1.1, some others implement YAML 1.2, and by YAML 1.2 they actually mean YAML 1.2 core schema. And often they implement that poorly.

So it doesn't help that:

* there is YAML 1.1 and YAML 1.2, and you need to know which one you want to use

* there is this thing called "core schema" and it's possible to use other schemas, but nobody seems to care

* the spec itself is complex, and hard to implement well


https://github.com/mikefarah/yq


Traefik supports all three of those interchangeably.


So does Caddy (and more!) https://caddyserver.com/docs/config-adapters


Caddy is awesome. You are awesome and Matt is awesome. The community is awesome.

This is one of the greatest piece of software I ever used.


I could be wrong, but one issue I see is that zone data seems to be a part of configuration (there is some indirection with `flattenRecords`, but still). I realize it's probably intentional in the name of simplicity, but this would prevent you from e.g. persisting received updates. I suppose I'm not the only weirdo out there who manages my DNS records with plain `nsupdate(8)`... Unless this contradicts your goals, I would say zone data should be independent from server configuration.

Also, I could be wrong about the design again, but on a quick glance it looks that because `app.Records` map is keyed only by the record name it seems that it's not possible (or at least not trivial) to have multiple different types of records for the same DNS name. For example, most of my zones have at least SOA, NS, A, AAAA, MX and TXT (and DNSSEC stuff if the TLD supports it) at their root. I suspect the idea is that `config.Record` is an universal record that tries to encompass all possible data into one superstructure (e.g. it seems that it can represent and A and AAAA simultaneously), but I don't think this would scale well. And TXT records can be particularly messy - there could be a real need to have more than one for the same DNS name (e.g. SPF record AND "google-site-verification" record).

All of this is based only on a Sunday evening quick cursory glance of an interesting project - so please forgive me if I got something wrong.


No actual comments about the software, but related to its goals I have been trying to figure out how to best handle a split horizon home lab type setup. I’m halfway in on using Tailscale and halfway in on using DNS.

Makes me sorta wonder if it would be a good idea to try to split the horizon 3 ways, by responding to DNS requests differently based on whether the DNS server is contacted via a local IP, a tailscale CG NAT IP, or another IP from the internet. I guess that implies your system DNS server would go over Tailscale in the happy case—maybe not a great idea?—but it would be useful in some situations, like ensuring my local Jellyfin server is efficient when used by even other people’s devices when they are on my WiFi network, but still allowing me to tunnel to everything in a uniform way, not needing to go through the gate that clients from the internet must.

I wonder… does anyone have thoughts on that?


BIND out of the box supports split horizon DNS as many ways as you want, I do 3 way split horizon with BIND.

I've never tried pairing it with Tailscale(I don't use it), but I pair it with Consul.

The config and docs aren't the prettiest, but it works fine. Most DNS software can't handle this use-case well.


What condition do you use for determine split horizon? Client IP?


Right, for internal networks, we use source IP(well network, but same diff).

For instance, we might have diff. source networks based on their department or building or whatever. We can then give them DNS information based on where they are coming from. It's not foolproof obviously, even if we control the internal network, it doesn't mean a bad actor isn't around wreaking havoc, so it's defence in depth, not the sole line of defence.

But it allows us to control DNS from 1 spot, and give this group of servers names for themselves, and that group of servers and this group of clients access to this group of servers, etc.


I suppose this is something you could do if you are in a local network and configuring all clients to use the DNS directly. In any other scenario, this will fail.


Using pivpn with Wireguard instead of Tailscale and pihole. With on-demand split VPN on the phone with DNS pointed to pihole it resolve the remote IP set in /etc/pivpn/hosts.wireguard while on VPN otherwise just the local IP while on the home network.


a DNS guide on how to get Linux itself to use the DNS server would be immense. for the life of my I cannot get systemd-resolvd to use itself as a DNS server.

How can dynamic DNS entries be added by dhcp servers to kitten? I feel like self addressing is something you want for home iot.


If the dhcp server supports RFC2136, you can use that (isc-dhcp does). You could also run dnsmasq with dhcp+dns then put DHCP clients in their own zone and configure kittendns with that zone (NS dhcp.my.domain -> dnsmasq-ip)


Questions

Is this meant to be recursive or authoritative DNS?

Is there an equivalent of query logging?

Are there plans to make this full featured liked BIND, or definitely not because your goal is to keep it "no fat, light"?


Authoritative first but it is also recursive if you specify a parent.

Query logging can be easily implemented.

I don't expect to ever make this as full featured as BIND. Then again, this also was true of Glauth, and correctness-as-a-goal ends up forcing us to roll lots of functionality in the software.


For those of us not dns experts-- are you planning to add more details on how to get started?


Good idea. Yes.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: