Mastodawn

Laurent Bercot May 26

Got a bug-report about DNS wildcard handling in shibari.

I think I understand what is happening (and while studying it, I found and fixed an unrelated bug, yay). But man, are wildcards a completely ad-hoc thing stapled onto the regular DNS logic, and wildcard support accounts for more than half of my record lookup code. This is really ugly.

Of course it's ugly, you will say: it's DNS. But no, regular DNS ugliness is about the protocol and the way it uses the network. Wildcards introduce ugliness in the way you process pure DNS data stored in your data bank, which normally should be pretty straightforward and elegant with a cdb.

It's ugliness all the way down.

An additional fun factor is that wildcards in #djbdns by design don't work like wildcards in BIND. The difference was much discussed a quarter of a century ago.

So any bug reports that assume that wildcards in djbdns databases are supposed to behave like they do in BIND's 'zone' files need to be checked for proper foundation.

And with RFC 4592 an even greater divergence then happened.

#djbwares #DNS #shibari

Laurent Bercot May 26

@JdeBP No, wildcards really didn't work in shibari 😅
But that's just why I wrote it: maintainability. I was able to fix it without too much pain, and it should now be compliant with RFC 4592.

I hope not, if working like #djbdns is the goal.

RFC4592 has a tree-structure model of domain name existence that prevents wildcards from working in some cases in a way that the djbdns table-structure model does not prevent.

Using the RFC4592 example:

When one does an MX lookup for _telnet._tcp.example. or ghost.*.example. it returns a non-empty record set because of the @ wildcard at *.example. .

In the RFC4592 model, the *.example. wildcard does not get applied.

#DomainNameSystem

Laurent Bercot May 26

@JdeBP Real talk: shibari working like #djbdns is not the goal. It has never been the goal. It will never be the goal. And I am getting increasingly annoyed at the djbware community who tends to believe that the original djbware is the be-all end-all of software design. djbware was excellent 30 years ago and is sometimes still serviceable; this does not mean it cannot be improved upon. Pretending otherwise is being in a cult.

In fact, the reason why I wrote shibari was twofold:

axfrdns is not RFC-compliant, and at some point BIND became more conservative in what it accepted, so one of my secondaries stopped working.
djbdns does not implement dns-0x20, so at some point some resolvers stopped working and my site became inaccessible.

(Also, of course, IPv6, but this was not the deciding factor.)

Did I try patching djbdns in order to solve my issues? Yes, I did. And it soon became apparent that although the djbdns design is stellar, the code is less than, and finding out where and how to patch it in order to change what I wanted was seriously threatening the few hairs I have left. I found it easier to write an entirely different DNS server from the ground up than to actually patch djbdns. That's how unmaintainable the code is.

So no, shibari's goal isn't to work like djbdns. It is to be a replacement that is, you know, actually compliant with the specifications, because that is what most people expect from their software. And also, a replacement that is actually maintainable and maintained, as proven by the fact that it only took me a few hours to fix the wildcard bug in shibari and make it RFC-compliant, whereas you seem to be saying it would be more or less impossible with djbdns - which I'm fully willing to believe.

It probably would be possible, but it was genuinely a design decision by Bernstein to make wildcards work that way. There were several mailing list discussions.

https://marc.info/?l=djbdns&m=104636747625737&w=2

In this case, working like #djbdns means taking unmodified cdb files and providing the same responses from those data; which is what your WWW page currently says is the #shibari goal.

If taking unmodified data files and giving non-tinydns behaviour instead is the goal, then that WWW page misleads.

'Re: tinydns and wildcards' - MARC

Anyway, who the Hell is this community that thinks that the original #djbdns is the be-all and end-all?

Let me know, and I'll show them #djbwares, where I've got a whole long list of things that have been improved, from IPv6 support through a non-hexdump way of doing SRV records to not letting ANY queries be amplification attack puppets.

http://jdebp.info/Softwares/djbwares/guide/changes.html

Changes from the original Bernstein softwares

Laurent Bercot May 26

@JdeBP "providing the same responses" does not mean bug-for-bug compatibility. They serve the same data, but when djbdns is noncompliant, shibari serves compliant data instead. This isn't a stretch.

At some point though, shibari will come with its own db format, because the tinydns format is far from optimal. Then I will stop misleading the 3 people who are stuck in 1998. 😛

That rather depends from the claim that something that was deliberately designed, and is documented as working that way, even *is* a bug. Bernstein did design to make things less suprisingly odd than 'zone' files.

Because this was and is unintuitive. I was one of the people who sometimes explained to users that there were implied interior nodes that stopped wildcards from working. As well as the other ways that BIND wildcarding didn't work like MaraDNS, Microsoft DNS, and #djbdns.

Laurent Bercot May 26

@JdeBP You're mixing two different things.

Yes, djbdns was designed to make things simpler than manipulating BIND zone files, and in that, it succeeded. tinydns-data was a wonderful idea, the format is nice (though sugar for AAAA records would be nice to have in 2026, something else that my own format should support) and automatable, and all in all it is clearly superior to most DNS software out there that is still tied to zone files.
Wildcards, however, are not part of what make zone files unintuitive. They may have been confusing back in 2001, but RFC 4592 came out in 2006, which is 20 years ago, and it seems to clarify wildcard semantics enough that no updates were deemed necessary. In that, djbdns refusing to align with the RFC is just as guilty of Microsoft DNS Server and MaraDNS. There's a new spec, the spec's behaviour is not blatantly inferior to your interpretation, the correct decision for a maintainer is to implement the spec. djb didn't do that because by 2006 djbware was already abandonware; that does not mean djbdns wildcards are correct. It means they're obsolete. There would have been an argument for bug-for-bug compatibility in 2007 or 2008; in 20fucking26, there is none.

By upgrading to shibari, you risk making your wildcards behave according to the specification. Oh no!

(Edit: typo)

Sugar for AAAA records was done in 2025 by me. Felix von Leitner did it differently 25 years earlier, but I didn't like that it required two parallel toolsets and sets of record types. My way, it's just an IPv6 address in the same '+' records.

That's been available for a *long* time.

#djbdns #djbwares

Laurent Bercot May 26

@JdeBP I was waiting for you to make that point, because it exemplifies another one of my gripes with djbware and its community perfectly:

Using unmaintained software that you have to patch to the high heavens to get a basic modicum of functionality is fun when you're learning, as I was back then, or when you're an amateur with too much time on your hands and a high tolerance for software that is hard to build.

I am 50 and doing all I can to keep package management simple. Stuff like qmail or djbdns, that has no central maintainer, that instead has websites full of patches that may or may not mesh well together, that you have to pick and choose, that make it difficult to audit the whole thing... ain't nobody got time for that.

I am spending ungodly amounts of time making sure my packages build and work out of the box on as many godawful OSes as I can, and that they only rely on having a C compiler, a standard set of Unix utilities, and GNU make - and I even get pushback by some people who would like me to stick to POSIX make instead (and I understand their points, but, no). I want to make sure building and installing my software is easy. And despite that, it has but a fraction of the adoption that I want it to have.

And you're still pretending that taking software that hasn't been maintained in 25 years and applying various patches to it is an acceptable way of doing things?

No, man, I'm done with that. You cannot expect people to have to look at whatever site to get the correct patch to include AAAA support in tinydns-data, that's more nuts than your average squirrel diet. If it's not in the main repository (or, like, in the main tarball), it doesn't exist.

djb isn't a Unix programmer. He's a cryptographer, who happened to write some kickass software a long time ago. Those of us who have chosen to become Unix programmers, well, it would be quite a shame if we were unable to do better with 25 more years of experience, now, wouldn't it?

Well you should be done with that. It's about time. (-:

It's been a long time since the world was *anything like* that.

I've been actively maintaining #djbwares for 13 years. Erwin Hoffmann has been maintaining #djbdnscurve6 for I think 8 years.

We both provide source in one go, zero patching involved. I've provided Debian and FreeBSD binaries packages for years, too. djbdnscurve6 has been in pkgsrc since 2019.

Hell, even the kids just fork ndjbdns entirely now. Patches⁈ (-:

Laurent Bercot May 27

@JdeBP djbwares, you mean the thing where I have to choose between 3 different source tarballs to start with, and if I have a non-Debian Linux or a Solaris I don't know which one I should download? Then I realize that it's not enough and I also need redo? Then I realize that I cannot cross-build? What if I need a staging area?

djbdnscurve6, you mean the thing I could never get to work reliably? That either crashed or busyloop every single time I tried to use it, despite being quite lenient and patient with it?

I'm sorry, these are not good examples. I'm willing to believe your tarballs work, as opposed to Erwin's, but as a normie user, they don't even get to the point where I actually run them - I have already given up three times. And that's from someone who is himself being heavily criticized (rightly or wrongly) for the lack of usability and user-friendliness of his software.

We don't have the same objectives and ambitions and that is fine. You are free to package things the way you want if it's working for you. But personally, the things I'm done with also include stuff like djbwares and djbdnscurve6.

Actually, it's the same source tree just compressed differently, and multiply-redundant copies across the repository sites. There's only one set of source for everything.

It would actually be the same compression if everyone's pax supported bzip2. (-:

There's also a simple bypass mechanism if the GCC or clang desired aren't the ones found in PATH, for cross-compiling and whatnot. Someone here asked for it.

Scarily, Bing's bloody LLM seems to know exactly what the mechanism is 9 months after I put it in.

How the Hell has it found that out? I haven't even put it in the Guide. I did the search to see if I'd ever mentioned it.

Here's the Guide, which does tell you that you need redo.

http://jdebp.info/Softwares/djbwares/guide/building-from-source.html

And here's the mechanism. Perhaps Bing somehow matched the name of the variable.

https://github.com/jdebp/djbwares/blob/trunk/source/cc.do#L8

Building the toolset from source

No, I'm not mixing things. I was there. I was there when the wildcard draft was made, trying to point out various problems in it, 2 years before publication. I was also there doing the user support, and I can tell you from a lot of actual experience with end users and this stuff that you are quite wrong.

Wildcards were one of the things that users asked about, over and over. BIND wasn't intuitive. Indeed people are still saying so on StackExchage 20 years later.

#DomainNameSystem

Don't fall into the trap of treating RFC4592 as a spec.

It's still a proposed standard, and there's a *lot* of stuff in the DNS RFC world that seems like a spec, until one hits the real world and finds that it's a decade-or-more wild goose chase that the RFCs don't tell you has failed to take off.

https://news.ycombinator.com/item?id=44320497

The reality is that RFC4592 didn't take off, either. *No-one* has adopted it that wasn't the implementation that it sought to ossify.

#DomainNameSystem

Why do we need DNSSEC? | Hacker News

Laurent Bercot May 26

@JdeBP You may be right, you certainly know the exact history more than I do. Despite that, RFC 4592 is all we have from an outsider perspective; if I want to make a standards-compliant DNS server, that is what I should follow. If you think that it's something I should document on the website, for people coming from tinydns and who might have different expectations, that's reasonable and I can do that.

In any case, should the specification change, should RFC 4592 be updated with something describing a different behaviour, it will be easy for me to modify shibari to follow the new spec. Which is the whole point. 😉

Peter van Dijk May 29

@JdeBP @ska DNS implementer here. Basically everybody has adopted 4592. I don't know why you would claim otherwise.

Because I'm a DNS implementor too.

The main people to have adopted that are the people who were already doing things its way.

Microsoft didn't back then, & still does not now. #djbdns, likewise. MaraDNS, likewise.

Of the 3, MaraDNS is the one that specifically calls out that there is a difference in its doco, although the other 2 document the different ways that they do wildcards.

I was pointing this out when it was still a draft.

https://groups.google.com/g/comp.protocols.dns.bind/c/yfgFVyU95rA/m/Fy69mSzL1j0J

@ska
#DomainNameSystem

Bind 9, Wildcard Records and Road Runner

Peter van Dijk May 29

> The main people to have adopted that are the people who were already doing things its way.

plus everybody who built a DNSSEC zone signer, which is why 4592 is the prevailing wildcard interpretation now. I knew about djbdns (of course). I didn't know MaraDNS deviated (but I am not surprised). I'm surprised about MS DNS, as I believe they support DNSSEC now.

Peter van Dijk May 29

@JdeBP @ska it should also be noted that djbdns, maradns, and presumably MS DNS, then in fact also don't implement wildcards as specified in 1034. 4592 is not a complete rewrite of the workings of wildcards.

And I'm not saying any of that is wrong; I'm saying that 4592 is not really the problem here, and (rephrasing myself better) the prevalent implementations on the Internet honour 1034/4592 - with or without DNSSEC.

Peter van Dijk May 30

@JdeBP as an extra fun fact, I just noticed that https://www.tinydnssec.org/ says "The interpretation of wildcard records now matches the description in RFC-1034"

DNSSEC for TinyDNS