Thanks For the feedback! I submitted the 2 patches last Monday if you feel like having a look. After some internal discussions turns out we'll probably end up using the simple reverse for our use case; as all the map population will be automated, we won't really mind the less optimal readability, so no sense in paying the extra cost. Plus it brought some discussion about UX, and whether to include things like trailing dots, etc. Anyway I've sent both!
Manu ________________________________________ From: Willy Tarreau <[email protected]> Sent: 22 April 2026 14:48 To: Manu Nicolas Cc: [email protected] Subject: Re: Feedback wanted on a possible new reverse FQDN converter Hi Manu, On Wed, Apr 22, 2026 at 12:31:22PM +0000, Manu Nicolas wrote: > Hi list, > > I'd like to get some feedback about a possible small addition to the sample > converter set. > > The idea would be a string converter tentatively called "reverse_fqdn". Its > purpose would be to transform an FQDN-like string into a reversed dotted form > so that domain-suffix matching can be expressed as a prefix lookup. > > Examples: > > "google.com" -> "com.google." > "mail.google.com" -> "com.google.mail." > "google.com." -> "com.google." > > The use case behind this is to express a rule as a domain name and have it > cover both the exact hostname and its subdomains, while still remaining strict > on label boundaries. In other words, one generally wants: > > - "google.com" to match "google.com" > - "google.com" to match "mail.google.com" > - "google.com" not to match "evilgoogle.com" > - "google.com" not to match "google.com.evil" > > The reason I find this interesting is that today this naturally looks like a > suffix-matching problem, thus something to solve with "end". But "end" is > list-based, so larger rule sets remain linear scans even if the cache helps in > practice for hot lookups. It also looks less attractive when the destination > set has a high cardinality or when the rules are updated often enough for the > cache to be of limited help. On the opposite, "beg" benefits from the > tree-based lookup path. > > Reversing the labels turns the suffix problem into a prefix problem: > > - "google.com" becomes "com.google." > - "mail.google.com" becomes "com.google.mail." > > With the trailing dot, the label boundary remains explicit, so a prefix lookup > can naturally distinguish "com.google." from "com.evilgoogle.". It's very interesting because last week we discussed with Baptiste about implementing a "reverse" converter that would entirely reverse a string to achieve the same thing. My goal there was to append a dot at the end and have the same format in maps/acls for exact the same purpose (longest match via a tree). I.e, with: hdr(host),reverse,concat(.) the "google.com" string would become "moc.elgoog." and we could do the same and remove the ambiguity between your two examples as well. Your approach looks cleaner however, and easier to deal with for admins, so I actually prefer it over mine. I'm pretty sure there's still some value in reverse() alone so if you're interested in going down this one at the same time, you'd be very much welcome :-) By the way, given that we already use the suffix "dom" at a few places that place boundaries around dots in domain names (map_dom, hdr_dom, -m dom etc), I think it would be easier to find your function if it was called "reverse_dom" than "reverse_fqdn". (...) > Would such a converter look acceptable in principle ? > > If yes, I can work on a concrete patch. I'm all for it! And it should be so simple (in the sense of harmless) that we could even envision a backport if that helps! thanks! Willy
