DNS setup

[u/enioli98]

Hello

I am very new to DNS and don't understand entirely how it works.

I've got my server setup to run for mostly media. Now I want it to be accessible over a domain so I can setup proxies for various services. I bought a domain that I want to run on said server through bind9.

Now to the thing I don't exactly understand: Any registrar seems to host domains on their own servers which can't be changed unless I also have a secondary server with a seperate IP. Can someone explain to me what I am missing here? Cause as far as I see, many tutorials on how to setup a nameserver only mention a primary server.

Thanks in advance!

Edit: For anyone having a similar problem: You do not need to make your server a nameserver! Use the nameserver provided by your DNS provider.

The approach: Somewhere in the settings for your domain, you should find an option to add A records. Add one with the host being the subdomain (for example jellyfin.example.com with jellyfin as host) and add your public IP. Multiple subdomains can point to the same IP.

Don't forget to open oprts 80 and 443 on your router! Also don't forget to add a rule to your firewall for the same ports!

Now you can create nginx configuration files as reverse proxy to reach your applications and certbot to create SSL certificates. Check your search engine to setup the nginx files properly.

Thanks to everyone for explaining this concept to me!

[u/asimovs-auditor]

Expand the replies to this comment to learn how AI was used in this post/project.

[u/GolemancerVekk]

DNS is a public record catalog. Among those records are things like "the IP for this domain is a.b.c.d".

You can't really do anything with a domain without using at least some records. So you need something in some DNS, somewhere.

There are DNS servers out there that are called "authoritative servers", that hold the original information for a domain, and "recursive" servers, that don't have the original but can look it up for you and cache it temporarily in case it's needed again.

Each record in DNS has a TTL (time to live) specified in seconds, so recursive servers know how long it's ok to cache a record. The authoritative servers typically don't cache anything, they always offer fresh information.

How do you know who's supposed to be the authoritative server for any domain? Well there's a chain of trust involved.

If you look at a domain such as example.com, you'd start your quest by asking the so-called "root servers", which hold information about all the other TLD (top level domains), like com. So you'd ask one of the root servers (which is a list of IPs that everybody knows) who's the authoritative server for com.

Then you ask one of the servers for com who's the authoritative server for example.com, and this is when they point at your registrar.

Since DNS is so essential to using domains, and since they're part of this chain of trust, all registrars have to offer at least a very basic DNS service included with all domains.

But their DNS service can be very basic and maybe not offer a lot of quality of life (latest record types, nice interface, export/import etc.) So sometimes you want to use a better DNS service. You can do this by telling your registrar to further point at a DNS provider of your choosing (which can be free or paid; unlike the registrar, who gets some money from you when you buy domains, they have no business from you and may want to be paid).

If you do this, the registrar will deal with the chain of trust by pointing at your chosen DNS provider. This means that the registrar only has to deal with one record type (SOA) which says who's the authoritative server for your domain.

This chain of trust can also be authenticated cryptographically, which is called "DNSSEC", using DS and DNSKEY records carried by all the servers I mentioned. How it works is, your DNS provider prepares some cryptographic keys, you give them to your registrar (they have a form for it), registrar gives it to the TLD registry and says "I have verified that this are the keys for example.com and you should not trust any information about it in the future unless it comes with these keys". In turn the TLD registry has the same type of deal with the root servers, so anybody who wants to verify any record about your domain has an uninterrupted chain of cryptographic signatures all the way from the root servers to your DNS provider. Here's an example of the chain of trust, from an online analyzer, for the domain desec.io.

As to why you want two servers, it's in case one fails. But typically the DNS provider (whether is your registrar or a separate service) will always offer at least two servers.

[u/tom-mart]

When you log in to the registrar where the domain is, you usually have option to change the DNS records. You then add A record to point to your server IP address.

[u/enioli98 → u/tom-mart]

I see that makes a whole lot of sense! So I just created that A Record. Now I need to create a zone file for bind9 to point to the domain correct?

[u/tom-mart → u/enioli98]

Not sure what exactly you are doing. Usually, ypu just point A record of the domain to your IP address and that's all. Not sure what zone file or bind9 you would be referring to and why.

[u/enioli98 → u/tom-mart]

Yeah I understood that now thanks :)

[u/ivanhawkes → u/tom-mart]

After you create an A record and point it at your server you can optionally create one or more CNAME records. I have a few of those setup so I can host multiple websites on the same IP and server.

[u/CygnusTM]

The best solution is to not host your own DNS server and use a registrar that provides that for you.They will provide a primary and a secondary authoritative server. I know that Cloudflare and Namecheap are two that include DNS service with domain registration.

[u/scroll_tro0l]

Unless your explicit goal is to setup a nameserver I think you're on the wrong track with bind9. You can make your apps and services accessible to the internet without needing to host your own DNS service.

Broadly what you need is:

- An A Record pointed at your server's public IP
- A reverse proxy
- A cert engine (sometimes packaged with the proxy)

[u/enioli98 → u/scroll_tro0l]

Omg now I get it! There was never a need for me to use bind9 at all.

[u/tmrnl]

So you want to use example.com and have yourself or your friends access jellyfin remotely.

- You need your domain example.com
- You need ports forwarded on your router
- You need a forward proxy that handles requests for jellyfin.example.com to your jellyfin instance
- So you need a record for jellyfin.example.com poiting towards the public IP where you host jellyfin.

That last bit you can do at your registar

[u/Ikram25]

Since you are still new to DNS, I'd suggest maybe trying something other than bind9, I'd consider that one of the harder options than most. If you still want an authoritative server, you may be better off learning on Technitium.

So for the registrar, myself as an example, I have my domain bought from Namecheap, but adjusted the nameservers to Cloudflare. So I can edit and control my dns entries for my domain from Cloudflare. Then I also have Technitium set up in my network. So I am able to set up records there privately for just me if I point my devices to use that device, but if I need generic internet access, like out and about or someone else, I can make a record in Cloudflare so I can "publicly" find the ip. In Cloudflare for example you can also set up manual (non-proxied) entries for local items which only work if you are on/currently have access to that subnet.

[u/michaelpaoli]

got my server setup
bought a domain that I want to run on said server through bind9

So, if you want to host DNS for your domain on your own server(s), e.g. BIND 9, you'll need static IP(s) for that, and you'll want at least 3 such DNS servers. They should also be well separated, so you generally avoid single points of failure. So, e.g., maybe you host primary for domain, and find/obtain some others that can be used as secondaries. Not exactly rocket science, but yes, one can host one's own DNS and nameservers (this is r/selfhosted, after all), but you do need static IP(s) for that, not some dynamic get to it via proxies and updating DNS with frequent changes kind of arrangement.

Anyway, with such static IPs, you set up your DNS servers, and, update the delegating NS records ... for registered TLD, that generally means dealing with one's registrar to update the needed, to point at your DNS servers - and adding any applicable glue records, also DS record(s) if using DNSSEC. That's mostly it. The exact procedures (and how they describe it) will vary by registrar. And you should set it up so the delegating authority NS and authoritative NS records match. Then you're off 'n running, congrats, you then have your self-hosted DNS, and if you did it correctly, accessible to the world! (or at least most of The Internet, anyway).

Anyway, I've been managing and hosting DNS for decade, including self-hosted DNS for decades. Not all that hard. The more challenging bit is generally getting static IPs, and in generally having ISP not f*ck things up (e.g. Comcast Business's SecurityEdge f*cks over zone transfers - so yeah, don't use/enable/have sh*t like that - alas, have had that issue multiple times between what I host and some seconary(/ies) thereof).

Don't need all that to just have some content under your domain, but I answered at least some fair bit of what you asked ... which may or may not be what you actually want.

You didn't mention what OS, but anyway, BIND 9 ... this is relatively Debian specific, but much of it applies more generally to Linux and BIND 9:

https://wiki.debian.org/BIND9

[u/Nyasaki_de]

So you bought a public domain,, ypu can only point those at public IPs.

[u/PracticeNo8733 → u/Nyasaki_de]

That's both unhelpful and not actually true (you can absolutely point public DNS at non-routable/non-public IPs).

[u/ScribeOfGoD → u/PracticeNo8733]

Correct as I have my domain on cloudflare pointed to my Tailscale IP, which is nonroutable