I’ve decided to start a series of short tips on this blog for software and coding stuff that I discover here and there. I sometimes stumble across a little quirk or a detail that I really want to talk about, but these things usually aren’t deserving of deep dives or even moderately-long posts. This series will help me remember these things, and it might help someone else who’s searching around for similar stuff. Win-win!
Today’s tip relates to Node.js or, more precisely, its package managers npm and yarn. I thought this one was noteworthy enough because of how little fanfare the documentation for npm gave it.
Disclaimer: I am not a lawyer, and nothing here is legal advice.
If you’re writing a closed source or proprietary package (they do exist!), you can put the word UNLICENSED in the license field in your package.json file. This is an officially supported feature in both npm and yarn, and it makes it clear (for machines) that the codebase for the package does not have a typical open source or free software license.
Here is an example use case with some irrelevant details omitted.
"description": "This is what my package does",
Warning: You need to be very careful when typing this out and especially if you’re just passing along this info to other people. The correct keyword is UNLICENSED. This is, however, annoyingly similar to Unlicense, the SPDX short identifier for the Unlicense, which is a public domain dedication document. That’s probably the polar opposite of what you want!
This is a post about a really niche problem that I ran into a few days ago. It looks like the Cloudflare DNS app does not like it when your subdomains are named too similarly to your apex. It’s very possible this is a user-friendliness measure and they’re trying to protect you from making a mistake, but I had to work around it.
Let’s be a bit more concrete here.
Consider the name tylerfilla.com, and assume it is on Cloudflare.
Now let’s go to the DNS app for the site.
A Contrived Example
Let’s make blog.tylerfilla.com point to some IPv4 address, say 192.168.1.1. (This is a reserved IP address meant for local networks, but that’s not a DNS concern. This would potentially resolve to a device on the visitor’s own home network or something.)
Now here is the list of records:
Aside: We can see that the Cloudflare web UI is not super concerned with consistency in the name column: blog and tylerfilla.com are hierarchical, yet they are presented flatly. In my opinion, either blog should be presented as blog.tylerfilla.com, or tylerfilla.com should be presented as the special symbol @ which is frequently used to represent the apex.
But what happens if we want to map the name tylerfilla.com.tylerfilla.com to some resource on the internet? You know, for science?
Now that is not something I expected to happen. Cloudflare detects that the name field compares equal to the apex name, and then they assume you meant the apex. (For the record, they also accept the symbol @ for the apex, so this is not a technically necessary behavior.)
This is a contrived example, so let’s un-contrive it a bit.
An Uncontrived Example
Let’s say I have created a GitHub organization called tylerfilla-com that I can use to hold some repositories for my personal website.
Let’s add the website URL to the organization.
Now let’s go get a sweet “verified” badge for it.
GitHub tells me to add a TXT record called _github-challenge-tylerfilla-com.tylerfilla.com. to the DNS with the value a9f432e7cb. (We can ignore the dot at the end of the record name, as that’s just a DNS formalism.)
That should be easy! What say you, Cloudflare?
Cloudflare refuses to accept _github-challenge-tylerfilla-com.tylerfilla.com and autocorrects it to _github-challenge.tylerfilla.com.
It turns out that this is just a UI limitation on the website, and I worked around the issue using the Cloudflare API, so let’s check that out. The relevant API endpoint is specified under the section called DNS Records for a Zone.
That’s pretty simple. I grabbed an API token from my Cloudflare account settings and the zone identifier from the landing page for my site on the Cloudflare web app. With all of that info, I ran the following command in a Linux shell:
I’m Tyler, and I am a software and hardware hobbyist in the greater St. Louis area. I have decided to keep a blog as a notebook for my personal projects.
Some time in December 2019, I decided that I wanted to start jotting stuff down when I’m doing something like wrangling with a tech problem or when tearing down a device or when writing a fun little app or even when soldering a tiny thing to a circuit board. These notes would be little more than something upon which I could look back from time to time, and I planned to start jotting immediately. That did not happen.
Fast-forward to March 2020, and I’ve refreshed all of my prior experience with web development (not much) trying to plan and build my ideal website. Initially, I dove head-first into the frontend realm with React, and, after three months, I can say that I’ve learned way more about SPAs, virtual DOMs, static site generation, and the Jamstack than I even knew existed. I’ve deployed to both Netlify and ZEIT Now, and I’ve followed guides for GatsbyJS and Next.js (both React frameworks) as well as for Sapper, which is a Svelte framework. This space is mind-bogglingly huge, and I’ve only scratched the surface. I come from the systems programming realm where the most exciting thing is complaining about the new bloatfeatures added to C++ every few years. (I kid of course!)
I realized pretty early on that I wanted something custom. I’ve made physical caveman drawings of how I want the site to look since I’m too stubborn to accept any of the prior art I’ve seen for themes. Crucially, however, I realized that I want to jot stuff down about the designing and building processes, as the website will probably never be finished per se (what is, really?). So, in a refreshing bout of getting things done, I used what I knew and set up a LAMP stack on an Amazon virtual machine (t2.micro free tier 😎). I also got an auto-renewing TLS certificate from Let’s Encrypt with the EFF’s certbot tool, and then I just set up WordPress on it. It works for now, and I’ll migrate my content later instead of trying to play both user and developer on a new project.
This blog is, admittedly, selfish to the extent that it’s merely my notebook and not a place for projected advice or in-depth tutorials. However, I am publishing in the hope that someone finds use for something I’ve created like a piece of code that I’ve written or like an Arduino project I’ve wired up or even something like an idea I’ve hinted at that got amplified by the search engines for the one person who needs it.
I don’t know what the future holds. I don’t know what, if anything, on this site will see greater use. But, at least for now, it’s Googlebot and I. And Robert Graham’s masscan.