CoreDNS Docker Deployment & systemd-resolved configuration for port 53

Recently, I'm so much into Docker & Kubernetes world. Coming from a purely "Microsoft" background, I have to tell you, I'm having a lot of fun. Because, to learn Kubernetes, you need to first learn Docker. You don't have to but if you want to understand well Docker, you need to understand Linux and it's runtime environments, in some cases, same goes for Windows as well. And when you start learning Linux, well... you get the idea, I don't have to keep this going. It's challenging, yet fun. I built a couple of VMs for practicing and using like my "staging" environment for my tests and experiments.

I also bought 3 X Raspberry PI 4 and loaded them with Ubuntu & configured a MicroK8S cluster. MicroK8S is a Ubuntu project and it's a supported version of Kubernetes for smaller environments. It basically supports all kubectl commands.

One of the biggest issues was, when I tried to install a simple DNS server on my network using Docker (not kubernetes yet) I had an issue with the local systemd-resolved process which was already listening on the port 53 (DNS).

 


I found a couple of methods to fix this issue. The most popular one is to completely disalbe the local systemd-resolved process and it stops listening on the port 53 which allows us to run the container and expose this port.

Another more eficient way I found is to change the DNSStubListener value to No in the /etc/systemd/resolved.conf file on my host.

 Follow these steps;

  1. Stop "systemd-resolved"
    sudo systemctl stop systemd-resolved
  2.  edit /etc/systemd/resolved.conf like this

  3. Run the following command for the symlink creation;
    sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

 

And that's it. You should be able to run any DNS server on your docker host natively listening on port 53. 

 


Comments

Post a Comment

Popular posts from this blog

System.Messaging.MessageQueueException (0x80004005): A workgroup installation computer does not support the operation (Public Queue create issue)

This is a weird issue that I don't fully understand why it would happen. But the symptoms are very persistent as we're able to reproduce these behavior easily. Issue: The MSMQ (Microsoft Message Queuing) fails to create Public Queues and throws  "the System.Messaging.MessageQueueException (0x80004005): A workgroup installation computer does not support the operation" exception.
Read more

Veeam Backup Error : Failed to prepare guest for hot backup. Error: VSSControl

Image
Problem Description; I had this issue on one of my backup jobs recently and I was able to fix the issue with the solution explained below. After a quick google search, I realized that I'm not the only one and neither you are :) Full Error Description; Failed to prepare guest for hot backup. Error: VSSControl: Failed to prepare guest for freeze, wait tim eout 9 00 sec Error: VSSControl: Failed to prepare guest for freeze, wait timeout 900 sec
Read more

warning: Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead - Chef Development Kit Update

Today, I needed to do some tests with a newer version of the Chef Client and test my cookbooks. To version 14.12.9-1 to be precise. I also upgraded my ChefDK on my workstation to the 4.2.0 version. I believe that upgrades Ruby version as well and now I have ruby version 2.6.3p62 Right after the upgrade, I tried with a basic knife node list command to see if I needed to reboot or anything was broke... Everything seems to be working fine, except I get this annoying "warning" message. As it's just a warning, I don't really care about it as it just seems to annonce something that is deprecated... Problem; You receive "warning: Win32API is deprecated after Ruby 1.9.1; use fiddle directly instead" warning when using ruby or chef knife commands. Solution; You need to comment out that warning message in Ruby lib scripts.
Read more