DNS, A , ALIAS, CNAME

 

ifferences Among A, CNAME, ALIAS, and URL records

https://support.dnsimple.com/articles/differences-between-a-cname-alias-url/

A, CNAME, ALIAS, and URL records are all possible solutions to point a host name (“name”) to your site. However, they have small differences that affect how the client reaches your site.

A and CNAME records are standard DNS records. ALIAS and URL records are custom DNS records provided by DNSimple’s DNS hosting. Both of them are translated internally into A records to ensure compatibility with the DNS protocol.

Understanding the differences

These are the main differences:

• The A record maps a name to one or more IP addresses when the IP are known and stable.
• The CNAME record maps a name to another name. It should only be used when there are no other records on that name.
• The ALIAS record maps a name to another name, but can coexist with other records on that name.
• The URL record redirects the name to the target name using the HTTP 301 status code.

Important rules:

• The A, CNAME, and ALIAS records cause a name to resolve to an IP. Conversely, the URL record redirects the name to a destination. The URL record is a simple and effective way to apply a redirect for one name to another name, for example redirecting www.example.com to example.com.
• The A name must resolve to an IP. The CNAME and ALIAS records must point to a name.

Which one to use

Understanding the difference between A name and CNAME records will help you decide.

General rules:

• Use an A record if you manage which IP addresses are assigned to a particular machine, or if the IP are fixed (this is the most common case).
• Use a CNAME record if you want to alias one name to another name, and you don’t need other records (such as MX records for emails) for the same name.
• Use an ALIAS record if you’re trying to alias the root domain (apex zone), or if you need other records for the same name.
• Use the URL record if you want the name to redirect (change address) instead of resolving to a destination.

ubuntu linux dns defauilt set up, docker-compose default set up

 ubuntu default DNS set up:

https://askubuntu.com/questions/1292650/resolv-conf-no-dns-servers-known

Ubuntu 20.04 uses /etc/netplan to set DNS. Do you have nameservers section in your /etc/netplan/?.yaml file?

yaml-file should have a section similar like this:

            nameservers:
                addresses:
                - 8.8.8.8
                - 2001:4860:4860::8888

resolve.conf is generated from netplan during boot and should should look like this.

nameserver 127.0.0.53
options edns0 trust-ad
search example.com

#edns 0 is https://www.daemon-systems.org/man/resolv.conf.5.html, 

attach OPT pseudo-RR for ENDS0 extension specified in RFC 2671, to inform DNS server of our receive buffer size. The option will allow DNS servers to take advantage of non-default receive buffer size, and to send larger replies. DNS query packets with EDNS0 extension is not compatible with non-EDNS0 DNS servers. The option must be used only when all the DNS servers listed in nameserver lines are able to handle EDNS0 extension.

# trust-ad is trust active directory

ls -l /etc/resolv.conf is usually a sim link to 

/run/systemd/resolve/stub-resolv.conf

which is network set up by systemd:

https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53#:~:text=conf%20tells%20DNS%20client%20libraries,%2Fsystemd%2Fresolve%2Fresolv.

systemd-resolved generates two configuration files on the fly, for optional use by DNS client libraries (such as the BIND DNS client library in C libraries):
/run/systemd/resolve/stub-resolv.conf tells DNS client libraries to send their queries to 127.0.0.53. This is where the systemd-resolved process listens for DNS queries, which it then forwards on. (In here 127.0.0.53 will forward dns request to /etc/netplan/xxx.yml
/run/systemd/resolve/resolv.conf tells DNS client libraries to send their queries to IP addresses that systemd-resolved has obtained on the fly from its configuration files and DNS server information contained in DHCP leases. Effectively, this bypasses the systemd-resolved forwarding step, at the expense of also bypassing all of systemd-resolved's logic for making complex decisions about what to actually forward to, for any given transaction.
..............

/etc/host vs /etc/resolv.conf

/etc/host is hostname and IP mapping
/etc/resolv.conf is dns name server IP list

https://www.looklinux.com/etchosts-vs-etcresolv-conf-in-linux/



Doceker-compose DNS default set up for containers:

https://stackoverflow.com/questions/39400886/docker-cannot-resolve-dns-on-private-network

https://www.reddit.com/r/selfhosted/comments/rwwtc0/docker_container_dns_servers/

Docker populates /etc/resolv.conf by copying the host's /etc/resolv.conf, and filtering out any local nameservers such as 127.0.1.1. If there are no nameservers left after that, Docker will add Google's public DNS servers (8.8.8.8 and 8.8.4.4).
According to the Docker documentation:
Note: If you need access to a host’s localhost resolver, you must modify your DNS service on the host to listen on a non-localhost address that is reachable from within the container.

Inside docker container, you will find /etc/resolv.conf which contains your /etc/resolv.conf 
with 127.X removed

To change this :
1) use /etc/dameon.json and specify DNS: [xxxx,xxxx], this will autmoatically apply to all contianers, 
it will look up using first, if not found using second. Note this will only override
container's /etc/resolv.conf as its for DNS nameservers, but not /etc/hosts as for domain Ip mapping

2) in docker-compose.yml , each service, you can use "dns"  keyword to manually specify DNS name servers for this container,
this will be added to container's /etc/resolv.conf
you can also register domain to IP mapping in each service using key word 'extra_host' 
this will add host IP mappings to container's /etc/hosts