Skip to main content

DNS - Domain Name System

Introduction​

The Domain Name System (DNS) is a hierarchical system that translates human-readable domain names into the IP addresses that computers use to locate and connect to websites on the internet. It eliminates the need for humans to memorize IP addresses.

Introduction to DNS

Here's how DNS works:​

  • When you type a domain name into your browser, your computer sends a DNS request to find the corresponding IP address.
  • The DNS request is directed to a recursive resolver, which initiates a sequence of queries to translate the URL into an IP address.
  • The recursive resolver queries a root nameserver, which directs it to the nameserver for the top-level domain (e.g., .com).
  • The top-level domain nameserver then directs the query to the authoritative nameserver for the specific domain (e.g., google.com).
  • The authoritative nameserver provides the IP address associated with the domain.
  • The recursive resolver returns the IP address to your computer, and your browser can then use that IP address to load the website.
  • Your computer and browser store a catalog of recently looked-up addresses, which allows them to bypass asking all the nameservers the next time you visit the website.
  • DNS data is often cached at various locations, including in the browser, operating system, and ISP's recursive resolver, to improve performance and reduce latency.

Domain vs subdomain​

A domain is the main address of a website (e.g. essity.com), while a subdomain is a subsection of that main address (e.g. www.essity.com). A domain is a unique name that identifies a website. Subdomains direct users to a specific section of a website and act as a smaller version/section of the main website, hosting different content without needing a new domain. Indeed, thanks to DNS, these subdomains are often hosted on different platforms e.g. brand site on platform A, shop on platform B etc.

Choose Carefully

Consider carefully if you need a domain or a subdomain. Domains are more expensive to acquire, set up and maintain... and sharing the experience across domains is harder than across subdomains

Engagement​

Submit a ticket in ServEss under the queue DNS Request

Standards and Conventions​

Domain Acquisition​

Essity already owns several thousand domains, so before requesting a new one, consider existing ones.

Essity can acquire further domains due to many reasons including

  • business or product acquisition
  • presence in a new market
  • avoidance of 'cybersquatting'

So if a new domain is required, the starting point is to reach out to the Trademarks Team, who consider an online domain part of the intellectual property of the company in a manner similar to other brand elements.

Conventions, Architecture and Design​

Language​

Language used for domains and subdomains should adhere to all prevailing business and ethical standards.

Formal English and local language is permitted.

Avoid

  • any terms which could be considered casual, slang or open to double meanings etc.
  • any terms which "plays" on words e.g. tissu.es or snee.se
  • any use of characters, deliberate or otherwise, which could be mis-typed e.g. O0Il1.com (big-o, zero, big-i, small-l, one).com
  • anything which fails to meet Essity's prevailing business and ethical standards.

Whilst tempting, also avoid acronyms and abbreviations.

Some exceptions are permissible subject to justification e.g.

  • misspellings to preserve brand and customer experience, and avoid cybersquatting, phishing etc. e.g. esity.com

Top Level Domains (TLDs)​

Essity's online business should be carried out under the .com top-level domain e.g. www.essity.com

Local market activities, especially for consumer activities, may be carried out under the appropriate country TLD e.g. www.essity.se or www.essity.co.uk.

International and enterprise customer activities are preferred under .com, e.g. torkglobal.com

Business use of other TLDs are normally not permitted, but may be acquired to a) prevent cybersquatting and b) to redirect traffic to the .com or country TLD site.

Domains​

Domains should only be acquired for long-term, business needs.

Short-term domain use is not permitted. This is firstly on the basis of ongoing cost and effort to manage, and secondly on the basis of building and maintaining trust and reputation.

Instead, a subdomain is a preferrable option e.g.

  • essitycampaign.com ❌
  • campaign.essity.com ✅
advice

Overall, domain owners, both business and technical, should create and maintain a domain strategy specific to their domain which meets their business needs. It should be take a long-term view, be flexible and extensible

Subdomains​

The following is an accepted set of good practices

  • designate one primary business domain, and separate activities under different subdomains e.g. www.example.com, shop.example.com, developer.example.com

  • if needed (and if not better served by the path), use subdomains to indicate locale e.g. uk.example.com, se.example.com rather than country TLDs (top level domains like example.co.uk and example.se)

  • follow the same general considerations for subdomain as well as domains e.g. language, clarity etc.

  • follow a consistent naming strategy for produciton and related non-production environments. The recommendations are

    • prefix each production hostname with the identifier for the lower environment e.g
    • "prod" is expected to be omitted especially for customer facing sites
    • avoid as far as possible variations outside of conventional norms e.g. do not create a "dev2.www.example.com". It leads to broken integrations, forgotten records etc.

  • recognise the need to include and align dns entries for different parts of the architecture e.g.

  • try to avoid using technology terms users will not understand

    • https.example.com ❌ (for http)
    • ws.iot.example.com ❌ (for websockets)
    • m.example.com ❌ (for mobile which has largely fallen out of fashion)
warning

People generally appreciate the business value of a domain, but there are major security considerations too with respect to subdomains including

  • cookies can be shared across subdomains
  • "dangling" subdomains can be (and are often) hijacked

Periodically check all your subdomains!

Business and Organisational Considerations​

Often there is discussion around what is suitable for the external market, which team should be responsible for what etc.

To address this, it is vital to have a flexible enough convention to allow business/organisational segregation.

Summarizing​

A good working convention is to use

  • [environment].[application(optional)].[solution].[business-area].[brand-term].[TLD]

So examples of this would be

  •                        www.example.com
  •            blog.support.example.com
  • dev.newsletter.shop.example.com

Some will raise concern over the "." separator, as technically it is a hierarchy separator for DNS zone/nameservers and can lead to a slower DNS resolution time. In most cases it is not an issue, but it would be acceptable to replace the left-most dot, with a "dash" e.g. dev-newsletter.shop.example.com - but only between [environment]-[application(optional)] .

warning

It is important to have this blueprint/convention establised early on. Trying to retro-fit/migrate to a convention later on is much harder e.g. once users are familar with existing hostnames, e.g. once systems have the endpoints configured

Implementation​

Domain Registration​

All domains used for Essity business must be registered through formal engagement with the Trademarks team - NO EXCEPTION

Nameservers​

All domains must use Essity IT approved name servers.

Zone Files​

A domain is normally expected to to be maintained in a single zone file.

Delegation is only permissible subject to clear justification and Essity IT agreement. Such justifications will only be considered based on clear organisational or volume needs

DNS Records​

There are many DNS record types and those requesting and maintaining are expected to have a strong understanding of good practice. The following are initial examples of good practice

  • all customer-facing hostnames are expected to be owned by Essity directly, and not be owned by 3rd parties e.g. www.example.com
  • all important, related object hostnames are expected to be owned by Essity directly, and not be owned by 3rd parties e.g. assets.example.com and not example.assets-hosting.com
  • all customer-facing hostnames are expected to be maintained in DNS as CNAMEs (A-records to even static IP addresses are not recommendeed)
  • all customer-facing hostnames are expected to be monitored/maintained/understood along the whole DNS resolution chain
  • all changes are subject to
    • review and approval
    • execution in a controlled manner e.g. authorized admins only, "reduction of TTL ahead of any change > change > review/confirmation post-change > final increase to original TTL"

Review and Approval​

DNS is very sensitive for many reasons, and the following is not the exhaustive list of considerations before any change

  • the proposed resolution/destination must be operationally suitable for use e.g. security, resilience, brand compliance etc.
  • the proposed resolution/destination must be ready for use i.e. it has passed all tests to ensure it meets the expected levels of security, resilience, brand compliance etc.
  • the change request must come with an implementation (and rollback) plan to ensure minimal disruption
  • evidence of broad stakeholder agreement must also be provided. i.e. the requestor should not be acting without buy-in
  • all requests should be requested/approved by Essity employees. Delegation, reliance etc. on 3rd parties is not permitted

Operations and Support​

opinion

More fact than opinion

  • The fastest way to take a site offline is to break its DNS
  • The fastest way to send your customers to a malicious site is to lose control of your DNS resolution

It is very important to continue to monitoring directly and indirectly the health of your DNS resolution. Hence it is strongly recommended

  • For Production usage
    • carry out regular DNS resolution checks along the entire DNS chain
    • align with HTTP checks to ensure the website/api is actually the one you expect to respond
  • For Non-Production usage
    • carry out periodic DNS resolution checks along the entire DNS chain
    • align with HTTP checks to ensure the website/api is actually the one you expect to respond