CoreDNS is still without first-class NSEC3 DNSSEC support right ? Last time I looked it needed a third-party community plugin. Not a good look. On Friday, 8 August 2025 at 18:51, Endre Szabo via NANOG <nanog@lists.nanog.org> wrote:

Hi,

I only can recommend CoreDNS for this use-case. Its plugin system is very easy to work with. I had a lot of fun times fiddling with wild ideas. But it’s written in Go, so ymmv.

—Endre

...

On 08.08.2025, at 19:19, William Herrin via NANOG nanog@lists.nanog.org wrote:

Can anyone recommend software for an authoritative DNS server where the open source code is clean and well documented? I have an anycast-related experiment I'd like to put together and I want to be able to quickly shoehorn it into existing code.

I looked at the source for ISC Bind but the code complexity is far beyond anything I'd want to touch for a casual experiment. Please don't use macros (#defines) to construct your C function definitions. I realize C allows it but it turns your code into a meta-language that no one else knows.

Regards, Bill Herrin

-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/RG5JZ5LG...

_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/ZQQF3WMP...

Subject: Re: Speaking of DNS server software... Date: Tue, Aug 12, 2025 at 10:55:00AM +0200 Quoting Endre Szabo via NANOG (nanog@lists.nanog.org):

Yes, and for a reason: https://github.com/coredns/coredns/issues/4565#issuecomment-816463715

...

On 11.08.2025, at 17:37, Smith via NANOG <nanog@lists.nanog.org> wrote:

CoreDNS is still without first-class NSEC3 DNSSEC support right ? Last time I looked it needed a third-party community plugin. Not a good look.

Tangentially, I must say I'm in agreement with Miek (who wrote the "nope" in the link above). NSEC3 is a solution in search of a problem, and at significant complexity cost. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR +46 705 989668 I know things about TROY DONAHUE that can't even be PRINTED!!

On Sat, Aug 9, 2025 at 3:50 AM Mike Simpson via NANOG <nanog@lists.nanog.org> wrote:

It’s authoritative only and won’t do recursion but NSD on OpenBSD should be much more readable.

Thank you everyone for the suggestions. I'll take a closer look at NSD. PowerDNS is interesting but I actually need the inverse of the "remote" backend: I plan to do funky things with packets and then pass the query to the DNS server software for resolution. The remote backend lets PowerDNS do the opposite: manage all the packets and then use a unix domain socket to send a query to custom software for resolution. CoreDNS is also interesting but it's been a few years since I've worked with Golang and I didn't like using it for low-level packet manipulation. When the libraries produced incorrect packets, I found it abnormally challenging to debug and figure out why. The APIs were too abstracted from the bytewise structure of the packets. Python is, well, Python. It makes as much sense to me to write a DNS server in Perl or Javascript, which is to say: not much. Anyway, thanks again for the pointers. Warm Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

On Aug 10, 2025, at 03:40, Etienne-Victor Depasquale via NANOG <nanog@lists.nanog.org> wrote:

...

Python is, well, Python. It makes as much sense to me to write a DNS server in Perl or Javascript, which is to say: not much.

I don't follow. What's the objection?

I’d consider two off the top of my head - 1. Performance delta, but that’s likely anywhere near the issue with python than it is with earlier scripting runtimes. While it’s been a while since I’ve done a side-by-side comparison, I’d argue that once code is compiled, cpython runtime performance is far more akin to Java than perl or JS. Still not as performant as C or Go runtimes, though; bytecode is still bytecode. 2. Python-based DNS servers aren’t nearly as ubiquitous as others, and as such lack the kind of battle testing that, say, BIND, PowerDNS, or commercial servers have been through. This makes sense from a security perspective, but the solution is to make bugs shallower, not to avoid entirely. Understandably, no one wants to go first. -Chris

This is not necessarily true anymore. As of Python 3.13 the GIL is now optional, though it defaults to enabled. They are slowly working towards flipping that. https://peps.python.org/pep-0703/ Regards, Ryan -------- Original Message -------- On 2025-08-10 10:40, Michael Crute via NANOG <nanog@lists.nanog.org> wrote:

On Aug 10, 2025, at 07:43, Chris Woodfield via NANOG <nanog@lists.nanog.org> wrote:

...

...

...

On Aug 10, 2025, at 03:40, Etienne-Victor Depasquale via NANOG <nanog@lists.nanog.org> wrote:

Python is, well, Python. It makes as much sense to me to write a DNS server in Perl or Javascript, which is to say: not much.

I don't follow. What's the objection?

I’d consider two off the top of my head -

1. Performance delta, but that’s likely anywhere near the issue with python than it is with earlier scripting runtimes. While it’s been a while since I’ve done a side-by-side comparison, I’d argue that once code is compiled, cpython runtime performance is far more akin to Java than perl or JS. Still not as performant as C or Go runtimes, though; bytecode is still bytecode.

The CPython interpreter does still have a global interpreter lock as well which causes thread synchronization on data access. You can mitigate this somewhat by running multiple instances of a server or asynchronous programming techniques but it still has a pretty substantial performance impact on highly concurrent systems. This is why most people scaling Python do so horizontally. I'd personally avoid something like Python for DNS or at least load test it very carefully before using it in production.

~mike _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/MBUKLDNV...

If it's just an experiment

No one ever suggested writing a brand new, production ready DNS server from scratch. Regards, Ryan -------- Original Message -------- On 2025-08-10 20:13, Mike Crute <mike@crute.us> wrote:

On Mon, Aug 11, 2025 at 02:34:56AM +0000, Ryan Kozak wrote:

...

...

On 2025-08-10 10:40, Michael Crute via NANOG <nanog@lists.nanog.org> wrote:

The CPython interpreter does still have a global interpreter lock as well which causes thread synchronization on data access. You can mitigate this somewhat by running multiple instances of a server or asynchronous programming techniques but it still has a pretty substantial performance impact on highly concurrent systems. This is why most people scaling Python do so horizontally. I'd personally avoid something like Python for DNS or at least load test it very carefully before using it in production.

This is not necessarily true anymore. As of Python 3.13 the GIL is now optional, though it defaults to enabled. They are slowly working towards flipping that.

While they're definitely working towards a lock-free world it's still very early and experimental. It's in a rather recently (Oct 2024) release of Python, default disabled and hidden behind a flag (--disable-gil). Also, to quote the 3.13 docs "expect some bugs and a substantial single-threaded performance hit". I would also venture a guess that DNS software written in Python will probably also need to be updated to break its GIL-based assumptions.

Not saying you can't run production DNS on a Python server stack but you definitely should understand how to effectively scale Python apps and load test it carefully otherwise you're in for some uncomfortable surprises. You should also probably not run it in GIL-free mode just yet.

~mike

On Sun, Aug 10, 2025 at 3:41 AM Etienne-Victor Depasquale <edepa@ieee.org> wrote:

...

Python is, well, Python. It makes as much sense to me to write a DNS server in Perl or Javascript, which is to say: not much.

I don't follow. What's the objection?

Howdy, On the way in, DNS takes a data buffer delivered from the network stack and imposes a strange and complex order on the bytes. On the way back out, it takes complex data and arranges it back into the same precise structure before passing a simple array of bytes down into the network stack. Some languages are well suited to this sort of task. In C, for example, you mostly just "cast" a well designed data structure from the pointer to the buffer of bytes. You haven't moved or interpreted or copied around the data in the buffer, but viola - you can now directly access the bits and bytes by mnemonic reference. C has adapted itself to your precise data structure with minimal fuss. Python doesn't work this way. Its memory management is abstracted away from the programmer and the programmer does not control its precise structure. For Python to access a DNS packet, the programmer must pack and unpack an array of bytes using complex software of their own devising. You can't just tell Python, "This is the complex data structure these bytes contain, let me access the data without unpacking it." This makes Python code for network handling more complex and much slower than comparable code for C needs to be. That's not a knock against Python. Most high-level languages abstract away the exact handling of data in memory so that programmers can focus on what their data contains instead of how it's stored. For many programming tasks that makes programming easier. But not for handling network packets which differ from the language's internal structure. Let me leave you with an example to make things more clear. Consider the following data structures for accessing an IPv4 or IPv6 header in C: https://github.com/CAIDA/mrt-tools/blob/main/src/addresses.h With these data structures you can: header = (struct ipv4_header*) byte_buffer; printf ("Don't fragment bit is: %s\n", header->dont_fragment?"set":"unset"); Not only is that code simple, the amount of work the CPU has to do to execute that code is trivial. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/

Not only is there struct, but also scapy which can craft any packet with ease. A quick Google search shows DNS examples, https://thepacketgeek.com/scapy/building-network-tools/part-09/. Combining asyncio with uvloop also provides very good performance. Ryan Hamel ________________________________ From: John Levine via NANOG <nanog@lists.nanog.org> Sent: Sunday, August 10, 2025 5:56 PM To: nanog@lists.nanog.org <nanog@lists.nanog.org> Cc: John Levine <johnl@iecc.com> Subject: Re: Speaking of DNS server software... Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. It appears that William Herrin via NANOG <nanog@lists.nanog.org> said:

Python doesn't work this way. Its memory management is abstracted away from the programmer and the programmer does not control its precise structure. For Python to access a DNS packet, the programmer must pack and unpack an array of bytes using complex software of their own devising. You can't just tell Python, "This is the complex data structure these bytes contain, let me access the data without unpacking it."

The python struct module is pretty fast, since it's written in C. I recently rewrote the abuse.net DNS server in python doing white lies on the fly DNSSEC signing. It's fast enough. R's, John _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FBGFDLG24XEHD47QE77ST6LY4OXUMHIKS%2F&data=05%7C02%7Cryan%40rkhtech.org%7C7acd43e68c4640cba83208ddd87271ce%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638904708244791010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VjAtZulg33OR7sZwZBVoRhMmndVN6Lzzm2TISqmU5xM%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/BGFDLG24XEHD47QE77ST6LY4OXUMHIKS/>

For Python to access a DNS packet, the programmer must pack and unpack an array of bytes using complex software of their own devising. You can't just tell Python, "This is the complex data structure these bytes contain, let me access the data without unpacking it."

Yes you can. https://docs.python.org/3/library/socket.html With these data structures you can:

header = (struct ipv4_header*) byte_buffer; printf ("Don't fragment bit is: %s\n", header->dont_fragment?"set":"unset");

Not only is that code simple, the amount of work the CPU has to do to execute that code is trivial.

df_status = s.getsockopt(socket.IPPROTO_IP, socket.IP_DONTFRAG) print(f"Don't Fragment flag status: {df_status}") On Sun, Aug 10, 2025 at 9:31 PM William Herrin via NANOG < nanog@lists.nanog.org> wrote:

On Sun, Aug 10, 2025 at 5:56 PM John Levine <johnl@iecc.com> wrote:

...

It appears that William Herrin via NANOG <nanog@lists.nanog.org> said:

...

Python doesn't work this way. Its memory management is abstracted away from the programmer and the programmer does not control its precise structure. For Python to access a DNS packet, the programmer must pack and unpack an array of bytes using complex software of their own devising. You can't just tell Python, "This is the complex data structure these bytes contain, let me access the data without unpacking it."

The python struct module is pretty fast, since it's written in C.

Hi John,

That's the difference. In Python you have a complex software library which can shuttle data back and forth between Python's internal data management process and an arbitrary byte-oriented data structure. In C, that arbitrary data structure is a first class citizen in the core language and no translation is needed.

You could pull apart a DNS packet in a Bash shell script if you really wanted to. The code complexity would be out of sight and it would run orders of magnitude slower than Python or C, but it can be done. Just because a thing can be done doesn't mean the language is an optimal choice for the task.

Regards, Bill Herrin

-- William Herrin bill@herrin.us https://bill.herrin.us/ _______________________________________________ NANOG mailing list

https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/LVNUTOYA...

On 8/10/25 6:30 PM, William Herrin via NANOG wrote:

On Sun, Aug 10, 2025 at 5:56 PM John Levine <johnl@iecc.com> wrote:

...

It appears that William Herrin via NANOG <nanog@lists.nanog.org> said:

...

Python doesn't work this way. Its memory management is abstracted away from the programmer and the programmer does not control its precise structure. For Python to access a DNS packet, the programmer must pack and unpack an array of bytes using complex software of their own devising. You can't just tell Python, "This is the complex data structure these bytes contain, let me access the data without unpacking it." The python struct module is pretty fast, since it's written in C. Hi John,

That's the difference. In Python you have a complex software library which can shuttle data back and forth between Python's internal data management process and an arbitrary byte-oriented data structure. In C, that arbitrary data structure is a first class citizen in the core language and no translation is needed.

You could pull apart a DNS packet in a Bash shell script if you really wanted to. The code complexity would be out of sight and it would run orders of magnitude slower than Python or C, but it can be done. Just because a thing can be done doesn't mean the language is an optimal choice for the task.

This is where native libraries come in. It's certainly not as good as fully native code, but they are honestly not that hard to write. As always, time to deployment is a consideration too. Raw compute cycles are pretty cheap these days. Throwing hardware at the problem is relatively easy, even if it causes ops guys eyes to roll. Mike

On Sat, Aug 09, 2025 at 09:52:34PM -0300, Rubens Kuhl via NANOG wrote:

You should take a look at https://nlnetlabs.nl/projects/domain/about/

. Some of the code for the experiments is already available, while some parts (like nameshed) will be released shortly.

I'm a big fan of NSD as others have commented, but there's some interesting oddities in the way it handles certain events at scale which aren't really something you can easily change, so much depends on what you are trying to do. I've also found/experienced a lot of bugs in various dns server software where you may want to be more specific in what you are trying to do, be it XoT or something else. I would as on the dns-operations list as that will get you a far more topical answer. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

There's also knot-dns (https://www.knot-dns.cz<https://www.knot-dns.cz/>) and knot-resolver (https://www.knot-resolver.cz<https://www.knot-resolver.cz/>). For BGP anycast, a simple health check script and ExaBGP go a long way. Ryan Hamel ________________________________ From: Rubens Kuhl via NANOG <nanog@lists.nanog.org> Sent: Sunday, August 10, 2025 5:31 PM To: Jared Mauch <jared@puck.nether.net> Cc: North American Network Operators Group <nanog@lists.nanog.org>; Rubens Kuhl <rubensk@gmail.com> Subject: Re: Speaking of DNS server software... Caution: This is an external email and may be malicious. Please take care when clicking links or opening attachments. On Sun, Aug 10, 2025 at 6:44 PM Jared Mauch <jared@puck.nether.net> wrote:

On Sat, Aug 09, 2025 at 09:52:34PM -0300, Rubens Kuhl via NANOG wrote:

...

You should take a look at https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnlnetlabs.nl%2Fprojects%2Fdomain%2Fabout%2F&data=05%7C02%7Cryan%40rkhtech.org%7C4b8ab69e93f749b8620808ddd86ea1bf%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638904691874305586%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VtcMI2RVhR%2BqJRNmw%2B14qXXdsDctaPvTOTPYXxmE5mY%3D&reserved=0<https://nlnetlabs.nl/projects/domain/about/>

. Some of the code for the experiments is already available, while some parts (like nameshed) will be released shortly.

I'm a big fan of NSD as others have commented, but there's some interesting oddities in the way it handles certain events at scale which aren't really something you can easily change, so much depends on what you are trying to do.

While NSD, Unbound and Domain are all from NLNetLabs, they are different codebases AFAIK. Rubens _______________________________________________ NANOG mailing list https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nanog.org%2Farchives%2Flist%2Fnanog%40lists.nanog.org%2Fmessage%2FW6MOXTS2FZAGZYQOHEYLYRS3OELKU6SY%2F&data=05%7C02%7Cryan%40rkhtech.org%7C4b8ab69e93f749b8620808ddd86ea1bf%7C81c24bb4f9ec4739ba4d25c42594d996%7C0%7C0%7C638904691874331752%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Xvee6xgDbU%2FHZZNwsCe8vY57f%2BvLp4OjxNZLTybeX%2FY%3D&reserved=0<https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/W6MOXTS2FZAGZYQOHEYLYRS3OELKU6SY/>