A VPS (Virtual Private Server) behaves as if it were a physical server under your control, but is likely some form of virtualized server (such as VMWare, Xen, etc.) that (likely) limits the blast radius of any damage you might do.
You can create a virtual host in your web server before you put entries in DNS. A partial list of methods you can use to test if the virtual host is working include setting a browser's proxy settings to use the virtual host's IP, or connecting directly to TCP port 80 or 443 (for HTTP or HTTPS, respectively) via telnet (for HTTP) or openssl (for HTTPS) or another appropriate program. (Connecting directly requires you to understand a little more about what happens under the hood of a web browser (although this can be learned by browsing through "Web Client Programming with Perl", available through the O'Reilly Open Books Project, or the appropriate RFCs).)
Regarding DNS, each record type has a particular meaning, and some of those are not necessary. Most people, in fact, probably only deal with SOA, NS, A/AAAA, MX, and possibly TXT, CNAME and CAA. (The last is actually new for me, since the time I last did DNS administration in a professional capacity.) (If you want to get deeply into DNS, I strongly recommend whatever the current version of "DNS and BIND" (sometimes referred to as the "Grasshopper" book) is from O'Reilly. And no, they don't pay me to advertise. :) )
Here is a sample zone file in BIND syntax for example.com:
$ORIGIN example.com. ; All unqualified names relative to this domai
+n.
$TTL 86400 ; default time to live
@ IN SOA ns.icann.org. noc.dns.icann.org. (
2020091009 ; Serial - 2020-09-10, change 9
7200 ; Refresh - 2 hours (7_200s)
3600 ; Retry - 1 hour (3_600s)
1209600 ; Expire - 14 days (1_209_600s)
3600 ; Minimum TTL - 1 hour (3_600s)
)
; Could also be written as a single line with no parens.
IN NS a.iana-servers.net.
IN NS b.iana-servers.net.
IN MX 0 .
IN A 93.184.216.34
IN AAAA 2606:2800:220:1:248:1893:25c8:1946
; Three CAA examples from RFC6844.
IN CAA 0 issue "ca.example.net; account=230123"
IN CAA 0 iodef "mailto:security@example.com"
IN CAA 0 iodef "http://iodef.example.com/"
bar IN CNAME foo
foo IN TXT "Hello, world."
www IN A 93.184.216.34
www.example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946
SOA (start or source of authority) records define the domain name, a mailbox for a person responsible for the domain (with the '@' replaced with a '.' (I can't recall having actually had someone contact me using that, but it is required by the spec), a serial number to determine if the domain has been updated, and time values (in seconds) for refresh, retry, and expire and minimum TTLs (times-to-live). Your confusion regarding the serial number is because there are basically three camps when it comes to serial numbers: 1) those who use a YYYYMMDDnn value, as was the recommendation in "DNS and Bind", 2) those who use epoch seconds (a.k.a. *nix timestamp), and 3) those who start at 1 and increment with each change. Personally, I don't think it matters which you use for now, as long as you stick with whichever scheme you select. Changing from one to another is a bit of a process) The refresh, retry, expire, and minimums are used by well-behaved DNS resolvers to determine how long to keep information (although a resolver can override those values in some cases).
A few quick notes. '@' refers to the zone name. An entry ending in a period ('.') is considered an absolute name (such as 'www.example.com.'), whereas an entry not ending with a period is relative to the zone or last $ORIGIN directive (thus 'www' is 'www.example.com.'). Anything following semicolons (';') is considered a comment (unless in a quoted string, as in the first CAA record in the example above). The $ORIGIN directive sets the domain name for unqualified records. The $TTL directive sets the default TTL (time-to-live) for records. BIND now allows times to be written in formats using combinations of 'w' (605_800s), 'd' (86_400s), 'h' (3_600s), 'm' (60s), and 's' (1s), so one could write a time of '1w2d3h4m5s' instead of 788_645 seconds (if desired). Entries that begin with a blank apply to the previous named host.
Next are the NS (name server) record(s) declare which DNS servers should be considered as authoritative for a particular domain. Those should include at a minimum the DNS server(s) listed with the registrar, but can include others for redundancy. (Also, those servers should actually hold DNS information for your domain, or know to retrieve and serve such.)
A and AAAA are address records. A records associate an IPv4 address to a name; AAAA records an IPv6 address. You can have multiple A and/or AAAA records associated with a name (which means any one of them can receive traffic for that name), and you can have multiple names associated with a single IP (v4 or v6) address (meaning any one of the names will try to reach that address). (Multiple names resolving to an address is where virtual hosting on a web server comes into play.)
MX (mail exchange) records indicate the hosts that can receive mail for the domain. These records also include a priority, with the preference to the lower priority value. The intention is that hosts with a higher priority value can accept the mail, then attempt delivery to the host(s) with a lower priority.
CNAME (canonical name) records are, in effect, aliases. In the example above, a lookup for 'bar.example.com.' will return the record for 'foo.example.com.' CNAMEs have limitations. They can only point to host or domain name. If a CNAME is present for a name, there can be no other records for that name to ensure canonical and alias values do not differ. (Apparently there is an exception for DNSSEC-related records, but that is outside the scope of this text.) MX and NS records and domains used in SMTP MAIL and RCPT commands must never point to a CNAME alias. CNAMEs should not point to other CNAMEs, as this can result in excessive lookups and even unresolvable loops. Because of these limitations, it is generally best to avoid the use of CNAMEs unless you understand why they are appropriate.
CAA (certification authority authorization) records specify the certificate authorities (CAs) that are authorized to issue digital certificates for a particular domain name. This came about following several incidents from 2001 onward where a certificates were obtained through a CA by unauthorized parties. CAA records are one of several mechanisms developed to limit mis-issuance by CAs. If CAA records exist for a domain, a CA is to check if they are permitted to issue certificates for that domain. ("issue" permits the holder of the domain in the property value to issue certificates for this domain. "iodef" refers to methods of reporting invalid certificate requests using the Incident Object Description Exchange Format.)
TXT (text) records allow for arbitrary text to be associated with a host. This can be used for notes, or some services (such as SPF, DKIM, and DMARC policies, among others).
Hope that information was helpful. (And please let me know if there are any errors.) |