Welcome to Tech Mastery, your expert source for insights into technology and digital strategy. Explore topics like Adobe Experience Manager, AWS, Azure, generative AI, and advanced marketing strategies. Delve into MACH architecture, Jamstack, modern software practices, DevOps, and SEO. Our blog is ideal for tech professionals and enthusiasts eager to stay ahead in digital innovations, from Content Management to Digital Asset Management and beyond.
In some cases, you may have a requirement to deploy the changes to a platform through a single repository/branch, e.g., AEM Cloud manager; AEM cloud manager supports a single repository and a branch to deploy the code changes to a specific environment — the containers are rebuilt on every deployment, so the complete code needs to be deployed on every deployment.
This can create restrictions while multiple teams working on different projects that all need to be deployed into the same platform; one approach is keeping all the project codes in a single repository, and all the teams can work on the same code repository, but sometimes this can lead into conflicts and dependencies between projects team.
Git submodules:
Git submodules can help to handle this scenario; Git submodules allow to merge of the content of multiple branches across repositories at build time. Git submodules help maintain complex projects by allowing independent repositories to exist as subdirectories within a wider project repository.
I have two maven projects in two different repositories; both repositories are enabled with the main branch
Update the Submodules in the main repository - git submodule update --remote
Update Specific Project - git submodule update --remote project2
Verify the status of the submodules - git submodule status
Show commit summary - git submodule summary
Run an arbitrary shell command in each checked-out submodule - git submodule foreache.g git submodule foreach 'echo $sm_path `git rev-parse HEAD`'
One of the concerns here is whenever the files from the Submodules (Project1 or Project2) are modified, the auto build through CI/CD pipeline will not be triggered as the build pipeline is configured to the main repository. The main repository will not be aware of the changes on the submodules.
This can be addressed by updating the submodules in the main repository with every change in the submodules (Project1 or Project2)
Execute the below commands on the main repository whenever there is a change on individual submodules, e.g., Project1, Project2 through a repository or external pipeline.git submodule update --remote git add . git commit -m "Sub Module Updated." git push
To enable this in AEM Cloud Manager, create project-specific repositories in the Cloud Manager Program and create a main repository with the required submodules configurations. Enable the main repository to the pipelines so that all the required submodules will be deployed. You make the same repository structure in your source code management tool and enable the pipelines to sync the repository between your code repositories and Cloud Manager Repositories. Refer to https://betterprogramming.pub/a-bitbucket-ci-cd-pipeline-to-sync-branches-with-github-1c885cefe202 for details on syncing repositories.
Most of the time, web developers struggle to understand the basics of DNS management, leading to confusion in their day-to-day operations. In this post, I want to discuss the DNS management basics that help Web Developers understand the DNS management process and help them in their daily operations. The screenshots and some of the steps captured here are based on the Cloudflare DNS manager.
What is DNS?
DNS stands for Domain Name System. The domain name system (DNS) is a naming database in which internet domain names are located and translated into Internet Protocol (IP) addresses. The domain name system maps the name people use to find a website to the IP address that a computer uses to locate that website.
For example, the DNS translates a web address like “www.albinsblog.com" into the physical IP address — such as”10.20.100.20" — of the computer hosting that site (in this case, www.albinsblog.com home page).
There are multiple Domain types( e.g., Generic Top-Level Domains (gTLD), Country Code Top-Level Domains (ccTLD) — not going to explain here), but as a web developer, we should be aware of the root/naked domain and the subdomains. When you register a domain name, you register what is known as the root domain, also called the naked domain, e.g., albinsblog.com is a root domain, you can register multiple subdomains under the root domain, e.g., www.albinsblog.com — here www is the subdomain on albinsblog.com root domain.
Domain Registrar:
A domain registrar is a business that sells domain names and handles the business of registering them, e.g., GoDaddy, Google, etc. All domain name registrars are accredited by ICANN (Internet Corporation for Assigned Names and Numbers), a non-profit organization responsible for managing domain names.
The domain registrar promptly updates and populates WHOIS(WHOIS is a database of information that allows users to look up domain and IP owner information and check out dozens of other statistics about the domain name) data to ensure the accuracy of the data.
DNS management:
DNS management is administering and managing the Domain Name System (DNS) for a particular domain or set of domains. It can include creating and editing DNS records, managing DNS zones, adding or deleting nameservers, and more.
What are Nameservers?
A nameserver is a server in the DNS management that translates domain names into IP addresses. Nameservers store and organize DNS records, each of which pairs a domain with one or more IP addresses.
Most Domain registrars will provide the default nameservers when registering a domain name. However, you can also use custom nameservers to manage the DNS records. Custom nameservers give you more control over your DNS settings and can be used to improve performance or security.
To use custom nameservers, you will need to set the “nameservers” for your domain to the DNS servers you want to use via your domain registrar’s control panel. Either use the registrar’s default name servers to manage the DNS records or point to custom nameservers through the registrar control panel so that the DNS records can be managed externally.
The DNS manager point to the default names servers, e.g., Cloudflare points to the default Cloudflare Nameservers; if required, the domain can point to the custom Nameservers.
While pointing the existing DNS to a custom nameserver, the current DNS records can be exported as a Zone file, and the same can be imported to the custom name server.
A zone file is a primary location where all the DNS records are stored for the domain. Whenever someone performs a DNS query, the servers pull information from zone files to answer it.
The exported Zone file is a simple text file with all the configured DNS record details
example.com.txt
;; ;; Domain: example.com. ;; Exported: 2022-09-28 23:47:34 ;; ;; This file is intended for use for informational and archival ;; purposes ONLY and MUST be edited before use on a production ;; DNS server. In particular, you must: ;; -- update the SOA record with the correct authoritative name server ;; -- update the SOA record with the contact e-mail address information ;; -- update the NS record(s) with the authoritative name servers for this domain. ;; ;; For further information, please consult the BIND documentation ;; located on the following website: ;; ;; http://www.isc.org/ ;; ;; And RFC 1035: ;; ;; http://www.ietf.org/rfc/rfc1035.txt ;; ;; Please note that we do NOT offer technical support for any use ;; of this zone data, the BIND name server, or any other third-party ;; DNS software. ;; ;; Use at your own risk. ;; SOA Record example.com 3600 IN SOA example.com root.example.com xxxxxxx xxxx xxxx xxxxx xxxx;; A Records example.com. 1 IN A 10.20.100.20;; CNAME Records www.example.com. 1 IN CNAME test.cdn.com.;; MX Records example.com. 3600 IN MX 5 gmr-smtp-in.l.google.com.;; TXT Records example.com. 1 IN TXT "v=spf1 include:_spf.google.com ~all" www.example.com. 1 IN TXT "yandex-verification: xxxxxxxxxxxxx"
DNS Records:
DNS records are instructions created and stored in a Zone File on DNS servers. These records provide essential and relevant details about domains and hostnames. These records also contain various commands on how DNS servers must handle DNS requests.
The DNS Manager provides the portal to manage the DNS records for a Domain.
DNS Record Types commonly used:
A-Record — Most commonly used to map a fully qualified domain name (FQDN) to an IPv4 address and acts as a translator by converting domain names(e.g., www.albinsblog.com) to IP addresses(e.g., 10.20.100.20).
The mapping can be enabled for the root domain (e.g., albinsblog.com — referred to as @) or different subdomains(e.g., www.albinsblog.com, test.albinsblog.com)
AAAA — AAAA records resolve a domain name corresponding to an IPv6 address.
CNAME — CNAME records can be used to alias one name to another. CNAME stands for Canonical Name.
For example, albinsblog.com and www.albinsblog.com point to the same application and are hosted by the same server. To avoid maintaining two different A-Records records, it’s common to create:
An A record for albinsblog.com pointing to the server IP address
A CNAME record for www.albinsblog.com pointing to albinsblog.com
Another case is; if the subdomain needs to point to a server that is enabled with dynamic IPs or multiple IPs, e.g., CDNs; in this case, it makes sense to enable a CNAME record pointing to a domain that intern points to the required IPs.
A CNAME record cannot co-exist with another record for the same name. It’s impossible to have a CNAME and TXT record for www.albinsblog.com.
The default behavior is the Top/Root domains, e.g., albinsblog.com can’t be pointed to the CNAME record but only to A-record.
While you are hosting a website through an external CDN that requires CNAME pointing — the main website will be hosted on a subdomain, e.g., www.albinsblog.com(www CNAME pointing to the CDN Domain), and the Top Domain should point to a server/service through A-Record (IP Address). The server/service can redirect the top domain to the subdomain(albinsblog.com to www.albinsblog.com); most of the time, the DNS manager provides the Forwarding service to redirect the root or specific subdomain to a specific target URL.
The recent concept — of CNAME flattening is supported by some of the DNS managers, e.g., Cloudflare allows us to enable the CNAME record for top/root domains.
Also, another nonstandard record type, ANAME(also called ALIAS, Virtual record type),supported by some of the DNS providers, e.g., GoDaddy, Google Domain, etc., provides CNAME-like behavior for apex (root) domains — point to the root domain to a DNS.
TXT Record- TXT records are a type of DNS record containing text information for sources outside your domain. The TXT records can be used for various purposes, e.g., Verify domain ownership for SSL cert Generation, Verify domain ownership for Google Analytics, Verify domain ownership for SEO tools, etc.
The SPF(Sender Policy Framework) records are a type of DNS TXT record commonly used for email authentication. SPF records include a list of IP addresses and domains authorized to send emails from that domain.
SOA — The DNS ‘start of authority (SOA) record stores essential information about a domain or zone, such as the administrator’s email address, when the domain was last updated, and how long the server should wait between refreshes. All DNS zones need an SOA record to conform to IETF standards. The DNS manager, by default, enables the SOA record for the domain.
MX — A DNS ‘mail exchange’ (MX) record directs email to a mail server. The MX record indicates how the Simple Mail Transfer Protocol should route email messages. Like CNAME records, an MX record must always point to another domain. You can define multiple MX records for a Domain; the priority number indicates the preference.
DNS Propagation:
DNS propagation is the time period in which it takes updates to DNS records to be in full effect across all servers on the web. Changes aren’t instantaneous because nameservers store domain record information in their cache for a certain amount of time before they refresh.
Typically DNS propagates within a few hours, though it can take as long as 72. The timeframe for propagation depends on several factors, including your internet service provider (ISP), your domain’s registry, and the TTL(Time to Live) values of your DNS records.
High TTL values are typically used for records that rarely change, such as MX or TXT. A high TTL provides faster responses for more static resources by storing the information locally before retrieving it again.
The Records that need frequent updates require a low TTL value. Low TTLs are recommended for critical records and are changed frequently. A good range would range from 30 to 300 seconds (5 minutes).
While modifying the critical DNS records, proper planning may require to avoid the downtimes for the end users — if the record is already enabled with high TTL better to change the TTL to a low value as a first step ahead of actual change; some users will still be served a cached version of your site until all servers have propagated.
You can use any DNS checker tool, e.g., DNS Checker — DNS Check Propagation Tool, DNS Checker — DNS Check Propagation Tool, to verify the DNS propagation status across different locations.
DNS Transfer to New Registrar:
Sometimes we may need to transfer our domains to a different registrar; domain transfer is switching your domain name from one registrar to another. To be eligible for a transfer, you must have been with your current registrar for at least 60 days since ICANN enforces a 60-day Change of Registrant lock.
Once you finalize the transfer, the domain should be unlocked from the current registrar to initiate the transfer — the DNS manager supports this configuration through the portal; generate the transfer AUTH token from the current registrar. The new registrar can initiate the transfer through the AUTH token.
The DNS records from the existing registrar will be migrated to the new registrar; may need to pay special attention if the Domain is using the default name server enabled by the current registrar — the names server pointing should be changed to a new registrar default names servers post transfer. Additionally, ensure the new registrar supports the special services(e.g., domain forwarding) supported by the current registrar.
DNS Security:
Enabling the required DNS security helps to protect the DNS from security attacks, e.g., DNS spoofing/Cache Poisoning, DNS Hijacking
DNS Over HTTPS(TLS) — DNS queries are sent in plaintext, which means anyone can read them. DNS over HTTPS and DNS over TLS encrypts DNS queries and responses to keep user browsing secure and private. For more details, refer to DNS over TLS vs. DNS over HTTPS | Secure DNS | Cloudflare DNS over TLS vs. DNS over HTTPS | Secure DNS | Cloudflare for more information.
DNSSEC — The DNS system is not initially built considering the security; DNSSEC strengthens authentication in DNS using digital signatures based on public key cryptography. With DNSSEC, it’s not DNS queries and responses that are cryptographically signed; instead, the data owner signs DNS data itself. This is critical to protect the important domains through DNSSEC to avoid security attacks. Refer to How DNSSEC Works | Cloudflare for more details on DNSSEC.
Domain Lock — As discussed earlier. domain lock will prevent any unauthorized transfers from occurring
Tools:
Some of the tools that will help us while working with DNS
nslookup/dig — command-line tools for querying the Domain Name System (DNS) to obtain the mapping between a domain name and IP address or other DNS records.