Dnsmasq - wildcard subdomains on localhost

-

I' m writing a multi-tenant web application where admin users create subdomains for each client. Subdomain is how the app knows which client to use for branding. But how the hell can I test something like this locally on a Mac?

If you’re in the same boat or just tired of polluting your /etc/hosts file, it’s time to setup Dnsmasq.

In this article, we’ll setup your Mac to answer all requests for a single top-level domain (TLD), in this case, .test.  So myproject.test and any domain ending in .test will all be directed to your local machine.

Keep in mind this process is valid as of macOS 12.0.1 Monterey.

First, make sure you have Homebrew installed.  That process is well documented so I won’t go into it here.  I will, however, remind you brew veterans to update your installation and packages.

Now, install Dnsmasq.

Now modify the config file at /usr/local/etc/dnsmasq.conf and append the following to the bottom of the file:

Now, create a /etc/resolver/ directory if it doesn’t already exist (requires sudo or root privileges). 

Next, create a file called /etc/resolver/test with the following content:

You can create additional files in this directory with file names that reflect the TLDs you want to add with the same content.

Now, start the dns service.

You’ll get a message about root taking ownership of files. That’s completely normal.

Don’t freak out, this is okay.

This only has to be done once since the service persists through reboots.

Now you can ping any domain ending in .test and it will resolve to your localhost at 127.0.0.1.

myproject.test now points to 127.0.0.1

Special Note For .local Domains

Recently, macOS is handling this TLD since it is technically supposed to refer to LAN traffic.  I stumbled across a workaround. If you need to support legacy projects with *.local domains, you’ll need one more step. In System Preferences -> Network -> Advanced -> DNS, add local to Search Domains. Now your system will handle *.local domains.

Comments

Post a Comment

Popular posts from this blog

Installing the Certbot Let’s Encrypt Client for NGINX on Amazon Linux 2

-
Image
Installing the Certbot Let’s Encrypt Client The certbot package is not available through the package manager by default. You will need to enable the  EPEL  repository to install Certbot. sudo yum install epel-release sudo yum install certbot-nginx Set Up NGINX certbot  can automatically configure  NGINX  for SSL/TLS. It looks for and modifies the server block in your  NGINX  configuration that contains a server_name directive with the domain name you’re requesting a certificate for. In our example, the domain is  www.mydomain.com . Assuming you’re starting with a fresh NGINX install, use a text editor to create a file in the  /etc/nginx/conf.d  directory named  domain_name.conf  (so in our example, www.mydomain.com.conf). Specify your domain name (and variants, if any) with the  server_name  directive: server { listen 80 default_server; listen [::]:80 default_server; root /var/www/html; server_name myd...
Read more

Deploy Nuxt.js app using Apache 2

-
  Deploy your dynamic Nuxt.js app Nuxt.js is an amazing server side rendering application framework for Vue.js. In this article we will see how to deploy Nuxt.js application to AWS instance in universal app mode. Where in Nuxt.js you can choose between Universal, Static Generated or Single Page application. Before we start deploying our dynamic app, if you want just to deploy a static website, you can run this command: npm run generate and it will generate the files and put them in  dist  folder which you can upload to any server you want. But this will not work for universal apps. 1. Build your app To build a ssr app you need to run the following command: npm run build The generated files will not be in the  dist  folder as for the static app, but you can find all generated files in  .nuxt  folder which will be the entry point. 2. Upload to the server There are two ways to do this upload your whole application with the source code or just upload the n...
Read more

Automate PostgreSql Backup with Cron

-
  Create The  Postgres Password File The file  .pgpass  in a user’s home directory can contain passwords to be used if the connection requires a password (and no password has been specified otherwise). On Microsoft Windows the file is named  %APPDATA%\postgresql\pgpass.conf  (where  %APPDATA%  refers to the Application Data subdirectory in the user’s profile). Alternatively, the password file to use can be specified using the connection parameter passfile or the environment variable  PGPASSFILE . Let’s see if the  postgres user  already has a password: sudo -u postgres psql select * from pg_authid; If  rolpassword  is empty, set the password: ALTER USER postgres PASSWORD 'mypassword'; \q Create  .pgpass vim ~/.pgpass # Add the following line # hostname:port:database:username:password localhost:*:*:postgres:[password] Add Environment variable  PGPASSFILE export PGPASSFILE= '/root/.pgpass' vim /etc/environment ...
Read more