FlyingFish
FlyingFish on GitHub
  • FlyingFish
    • About the project
    • Screenshots
    • Installation
      • Quick Setup
      • Quick Update
      • Create Backup
      • Long setup
        • Env
        • Docker compose
          • Ports
          • Network
      • Storage management
      • FAQ
    • Configurations
      • Which user type am I
      • Listen
        • Port forwarding
        • Proxy protocol
        • IP Access
        • Gateway identifiers
        • UPnP Nat
      • Domains
        • DynDns Clients
        • Own DNS Server
        • Discussions Subdomains
        • DynDns Server
      • Routes
    • Examples
      • SSH hidden on HTTPS
      • FlyingFish to other reverse proxy
      • Backup Server, SSH to Nas
      • Own DynDNS Server - Fritzbox
      • Inventree - Route
    • Developer
      • Ideas, requests and bugs
      • Project structure
        • Under the hood
        • Service structure
        • Schema
        • Object name rules
      • Image build
      • Plugins
    • Contribution
Powered by GitBook
On this page
  • Theory
  • Practice
  • Test your DNS Server
Edit on GitHub
  1. FlyingFish
  2. Configurations
  3. Domains

Own DNS Server

The own DNS server combines the Dyn DNS client.

PreviousDynDns ClientsNextDiscussions Subdomains

Last updated 3 months ago

Theory

The FlyingFish DNS server will never be an official root DNS server. He could only do that if the router or PC directly enters the IP from the DNS server. For example, the DHCP could distribute the DNS IP.

But here I will describe how the DNS server can officially manage a sub DNS server for online query subdomains.

If you have received your domain from the DNS administrator, you can manage the records yourself in the provider's portal.

Example if you own the example.com domain, you can manage the subdomains for this domain in FlyingFish, e.g. sub1.example.com.

A domain example.com gets an NS (name server) record from the provider. These records can only point to domain names. In addition, we create a subdomain dyn.example.com who's A record gets the IP from our DynDNS client/or fixed IP. DNS servers are backwards resolving. That means if a sub1.example.com is called but not found, example.com is called. However, this does not return an A record, only the NS record. Now the client knows he must request a DNS server under the domain dyn.example.com. With its IP resolution it gets the IP from the FlyingFish DNS server. Then the client asks this DNS server again and gets sub1.example.com an A record.

In the diagram you can see how the flow works:

  1. The DynDNS client delivers the IP and writes it to dyn.example.com A Record.

  2. The domain example.com points to an NS record on domain dyn.example.com.

  3. The dyn.example.com record now sends the DNS client to our FlyingFish DNS server.

From now on we can manage all sub domains and example.com ourselves with our own records.

Practice

I myself use the provider "Selfhost" which I can recommend for this setup.

Test your DNS Server

First you should check whether the server is accessible in the network. According to the standard installation, the DNS port is 5333. This is simply specified in the app.

dig @<host-ip-flyingfish> -p5333 <mydomain>

If everything is set up as above with the "NS" record and port forwarding from the router is set up, we can start the query without IP and port:

dig <mydomain>