CGHMN DNS Information

About this page

This page exists to document information about the DNS of CGHMN, and some of the complexities that comes with a DNS infrastructure made of up varying platforms across decades of the protocol's evolution. See CGHMN-Demo-Network for detailed information about the underlying infrastructure

DNS Configuration Guide

Getting Started

Pointing to the right DNS server

CGHMN has several DNS servers in use for differing purposes. The correct default DNS server you should be pointing at while getting started is 172.23.0.1 from the core network, or 100.89.128.0 from the Wireguard tunnel. This is the router, which then forwards the requests to the actual DNS.

What the different DNS servers are (or, is this thing on?)

CGHMN's DNS is configured such that there are three core servers that perform response modifications to allow the recreation of long defunct services, perform lookups, and act as the root name server for the network, which has two internal TLD (top level domain, like .com or .net) on it.

172.23.4.101 - ns1.cghmn

This is the root name server for the .retro and .cghmn TLDs, as well as the 23.172.in-addr.arpa and 96.100.in-addr.arpa reverse lookup zones. This server exists to delegate domains to members of CGHMN, and serve as the name server for the internal network. This server is useful to perform a dig or nslookup against if you want to see if a subdomain has been delegated, for example:

dig ns example.retro. @172.23.4.101

or

nslookup

> server 172.23.4.101

> set type=ns

> example.retro.

This server does not perform lookups. It is currently running BIND.

172.23.4.105

This is the recursive lookup server for the network. It is configured to recursively look up all requests for CGHMN domains, starting with ns1.cghmn, and then moving up based on delegations to member servers. Regular lookups still take place against real TLDs, if something needs to be pulled off the internet. This server is currently running BIND. This server is useful to use dig or nslookup against if you wish to see if your domain is resolving on the network after it has been delegated to you.

dig a test.example.retro. @172.23.4.105

or

nslookup

> server 172.23.4.105

> set type=a

> test.example.retro.

172.23.4.104 - legacydns.cghmhn

This is a dnsmasq server that is currently being used to perform modifications to DNS answers, by pulling from a list of servers that need to be faked in order to make old software, such as AIM, work correctly. This server overrides the DNS answer with these responses, so all relevant DNS records need to be added. The rationale for this is that instead of a user modifying their hosts file (which can be dozens of different DNS addresses long) we can simply return addresses that correspond within the network. Please ask if there is a service you would like added to the network that requires this kind of override. Otherwise, it just forwards the questions to the recursive lookup server 172.23.4.105. This server is useful to test against if you are having trouble connecting to a legacy service that utilizes hard coded DNS.

dig cname login.oscar.aol.com.

or

nslookup

> server 172.23.4.104

> set type=cname

> login.oscar.aol.com.

172.23.0.1

This is the core router for the network, which also serves as a DNS forwarding. It is currently forwarding all traffic to legacydns.cghmn, and performs no additional lookups or translation. This server is useful to test against for any purpose.

Hosting Your Own DNS Name Server

About self-hosting

CGHMN can host member DNS zones on its nameserver, however it is welcome and even encouraged for them to explore setting up their own DNS name server for their subnet. This can be done with most DNS server software, provided they can be recursively looked up against by BIND. Please note that if you intend to run old Microsoft DNS, you will need to let us know that you are running it, as exceptions to the lookup procedure need to be added to the 172.23.4.105 server.

You will need to reach out to CGHMN and let us know you want to host your domain, and give us the domain, NS record, A record, and IP address of the DNS server.

What you need

A server

You will need a computer connected to CGHMN, running a DNS server software that is able to act as an authoritative name server. It will need to have UDP port 53 and TCP port 53 allowed in its firewall. You do not need a lot of power, but it should be fairly reliable as everything will depend on it to find your servers and services.

A SOA record

You will need a SOA (Start of Authority) record, this is the record that tells other DNS servers "I am in charge of this domain and here is the information about it". This record will need to be pointed to an NS (Name Server) record.

A NS record

You will need a NS record, this is the record that says "this is where you ask about this domain". This record should point at an A record.

An A record

You will need an A record, this is the record that maps the name of the DNS server to an IP address. This should be the FQDN (Fully Qualified Domain Name) of the DNS server, and the IP address it is listening to.

Summary

Your server will need to be configured as an authoritative name server. To do this, it must run a DNS name server software, which should have a zone containing an the SOA, which points at the NS, which points at the A.

DNS Quirks

Windows DNS

Old Windows DNS servers will misbehave when BIND's recursive lookup server attempts to do a lookup against them, and will end in failure. The way around this is to disable edns lookups against this particular server in the BIND configuration. Bind is supposed to attempt again with edns disabled but it seems with Windows DNS specifically to fail.

DNS manipulation with multiple RR types

If a record is being looked up, and this record was once an A record, but still exists and is now a CNAME record, you will have an issue where the lookup will work with tools, but fail with actual lookups. This is because the CNAME record being returned from the real DNS server will take precedent over the fake A record. To resolve this issue, you have to fake both the CNAME and the A record.