Category: Linux Server

Step by step:

1. Download the Android apps “Bitwarden Password Manager” and for apple “Bitwarden Password Manager”
2. Open Bitwarden password app
3. Login in on → self-hosted
4. Server URL is Https://bitwarden.richardapplegate.io
5. Login to your account. If you don’t have one, ask Richard Applegate to open a registration. I have to close the register to be more secure and stay away from bots.

Building a Dockerfile on Windows 11 is a common workflow for containerized development. Here’s how you can do it—step by step:

---

1. Install Docker Desktop for Windows

• Go to the Docker Desktop download page.
• Download the Windows installer and run it.
• Follow the prompts (ensure “WSL2” support is selected, if available).
• NOTE: Windows 11 works best with WSL2.

---

2. Write Your Dockerfile

• Use a code editor (e.g., VS Code, Notepad++).
• Save your Dockerfile as simply named: Dockerfile (no extension).
• Example (Python app):

FROM python:3.11-slim
WORKDIR /app
COPY . .
RUN pip install -r requirements.txt
CMD ["python", "app.py"]

---

3. Open a Terminal

• On Windows, you can use:
• Windows Terminal (wt command)
• Command Prompt (cmd)
• PowerShell
• WSL2 Terminal (Recommended)

---

4. Navigate to the Dockerfile Location

Use the cd command to go to your project directory:

cd path\to\your\project

---

5. Build the Docker Image

Use the docker build command. For example:

docker build -t my-app:latest .

• -t my-app:latest gives your image a name and tag (latest).
• The final . means “use the Dockerfile in the current directory”.

---

6. Run the Docker Container (Optional)

Test your image:

docker run --rm -it my-app:latest

---

7. Troubleshooting

• If Docker commands aren’t recognized, make sure Docker Desktop is running.
• Check Windows Terminal settings if using WSL2, and ensure file sharing is set up for your code folders.

---

Summary Table

Step	Command/Action
Install Docker	Download & install Docker Desktop
Write Dockerfile	Use text editor, save as Dockerfile
Open Terminal	PowerShell, CMD, WSL or Windows Terminal
Go to directory	cd path\to\project
Build image	docker build -t my-app:latest .
Run container	docker run --rm -it my-app:latest

---

Tip: You can use Docker Desktop’s GUI to see your images and containers as well!

What a wild ride! As someone who cares deeply about keeping ads and trackers away, I run not one, not two, but three Adguard Home DNS servers for my network and my work and a few trusted friends. Things were smooth…until today’s wake-up call.

When 3 DNS Servers All Go Down

Early this morning, my phone lit up with monitoring alerts: All three Adguard Home DNS servers were timing out. At first, I figured it was typical network flakiness, but when I logged in and checked the stats—yikes! Each DNS server was being bombarded with requests. Log entries were flying by like a slot machine, and CPU loads were through the roof.

I quickly realized: this was a full-blown DDoS attack. Someone (or something) had decided today was the day to flood all my DNS instances and bring them to their knees.

Port 53 is Love, Port 53 is Pain

If you run a DNS server, you know traffic flows through port 53. It’s the default, it’s widely known, and unfortunately, it makes you a target. Even with basic security and firewall rules, a determined attacker can throw a gigantic amount of junk queries your way. The more public your DNS, the more likely it is to end up on a botnet’s hit list.

I tried to mitigate: blocking IPs, tweaking Adguard’s query limits, but the traffic just kept coming—botnets can scale, after all.

The Fix: Hello, DNS-over-TLS (853)!

Desperate for relief, I remembered what sets modern DNS apart: encryption. Both DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) remove reliance on the open port 53, using encrypted connections to a different port.

• DoT uses port 853.

So, I did something radical (for my setup):

• I closed public access to port 53 on all three servers.
• I configured Adguard Home to only accept DNS-over-TLS traffic on port 853.
• I made sure my clients (phones, computers, routers) were using DoT (port 853) instead of plain DNS.

Like flipping a switch, the attack ended. No more flood, no more timeouts—just blissfully fast, secure DNS again.

Why This Works

Open port 53 is universally scanned—by researchers and attackers—for DNS servers to abuse. By limiting access and switching to encrypted DNS-over-TLS, you:

• Hide your DNS from general internet scanning.
• Require authentication (sort of; at least a valid TLS handshake).
• Dramatically reduce DDoS exposure, since randomized bot attacks target port 53 by default.

Lessons Learned

• Don’t run a public port 53 DNS unless you must. Always lock it down or require VPN/TLS/DNSCrypt.
• Encourage clients to use DoT or DoH—they get privacy AND you get peace of mind.
• Know your tools: Adguard Home makes it surprisingly easy to deploy DNS-over-TLS.
• If you rely on DNS, have a mitigation plan—DDoS can strike anyone, anytime.

Next steps? I’ll keep a close eye on logs, make sure clients are all set up with DoT, and might even look into DNS-over-HTTPS as a backup.

How about you? Have you had to defend your home DNS from attacks? Share your story below!

---

Stay safe, and happy (private) browsing!

My DNS query results confirm that all our DNS servers are secured with DNS over TLS encryption.