AWS has taken steps to boost resilience weeks after a major outage, rolling out a business continuity feature targeting DNS records.

Last month, an outage at the hyperscaler knocked an array of popular services offline – from Signal and Slack to Zoom and even Amazon itself – taking several hours to fully resolve.

The outage stemmed from DNS resolution issues and took place in what AWS calls US-EAST-1 Region, better known as northern Virginia, where plenty of massive data centers are located.

A month on, AWS has announced a new tool to help mitigate future incidents, helping to get systems back online within an hour after DNS issues, specifically in that often troublesome US-EAST-1 Region.

"Today, we’re announcing Amazon Route 53 Accelerated recovery for managing public DNS records, a new Domain Name Service (DNS) business continuity feature that is designed to provide a 60-minute recovery time objective (RTO) during service disruptions in the US East (N. Virginia) AWS Region," said Micah Walter, senior solutions architect, in a post on the AWS blog.

"This enhancement ensures that customers can continue making DNS changes and provisioning infrastructure even during regional outages, providing greater predictability and resilience for mission-critical applications."

AWS touts new tools

Walter explained that the tool targets DNS changes that customers can make within 60 minutes of a service disruption in that region.

"Customers running applications that require business continuity have told us they need additional DNS resilience capabilities to meet their business continuity requirements and regulatory compliance obligations," he said.

When services are disrupted, the new tool offers several benefits. "The feature maintains access to essential Route 53 API operations, ensuring that DNS management remains available when it’s needed most," Walter added.

"Organizations can continue to make critical DNS changes, provision new infrastructure, and redirect traffic flows without waiting for full service restoration."

However, the company also stressed that wasn't a sign of an issue at AWS, but pinned the need for the tool on demand from customers in sensitive industries.

"While AWS maintains exceptional availability across our global infrastructure, organizations in regulated industries like banking, FinTech, and SaaS want the confidence that they will be able to make DNS changes even during unexpected regional disruptions, allowing them to quickly provision standby cloud resources or redirect traffic when needed," Walter noted.

How the new tools work

The system works with existing setups and customers can continue using their existing Route 53 API endpoint without changes to apps or scripts.

"The implementation is designed for simplicity and reliability,” he said. This means customers won’t need to “learn new APIs or modify existing automation scripts”.

"The same Route 53 endpoints and API calls continue to work, providing a seamless experience during both normal operations and failover scenarios."

In the post, AWS noted that accelerated recovery isn't enabled by default, but switching it on for a new or existing hosted zone simply involves switching it on.

"You can enable this feature through the AWS Management Console, AWS Command Line Interface (AWS CLI), AWS Software Development Kit (AWS SDKs), or infrastructure as code tools like AWS CloudFormation and AWS Cloud Development Kit (AWS CDK)," he said.

Accelerated recovery is available now for Amazon Route 53 public hosted zones and is free.

MORE FROM ITPRO

• The Microsoft Azure outage explained
• Inside a cloud outage
• The Cloudflare outage explained

An HTTP Error 400, often referred to as the "Bad Request" error, occurs when a website server is unable to process a request due to issues such as an incorrect URL or invalid request data. Unlike server-side errors like HTTP 502 or 503, a 400 error typically originates from the user’s end. This means the fix is often straightforward, such as correcting a URL or clearing out old cookies.

Depending on the browser you are using, an HTTP Error 400 can result in a blank page, or a page showing a more generic, user-friendly message, as is the case with Opera and Chrome.

However, there are a bunch of other messages you might encounter that all signal an HTTP Error 400, including:

• Bad Request - Invalid URL
• Bad Request: Error 400
• HTTP Error 400 - Bad Request
• HTTP Error 400. The request hostname is invalid
• Bad Request. Your browser sent a request that this server could not understand

Website owners are able to customise the page that an HTTP Error 400 will display to visitors. An example of this is when web servers run Microsoft Internet Information Services (IIS), which results in a page breaking down the error in more detail, such as “400.3: Invalid If Header”, “400.2: Invalid Depth Header”, “400.1: Invalid Destination Header”, and more.

What causes an HTTP Error 400?

Several issues can trigger an HTTP Error 400, which generally stem from user input or browser data. Here are five of the most common causes:

1. Bad URL Syntax

The most frequent reason for an HTTP Error 400 is a misformatted URL. This could be the result of typing errors, such as including special characters that aren’t allowed in URLs (e.g., using a backslash instead of a forward slash). 

You can trigger an HTTP Error 400 manually, usually by typing "/%" after the URL.

For example, the following URL will send you to a valid page, the page to sign up to our daily newsletter:

'https://www.itpro.com/newsletter-signup'

However, if you were to type this URL in manually and type "/%" at the end of the URL, the request will result in an HTTP Error 400 page - as the server has received a 'Bad Request'.

2. Invalid Cookies

Sometimes, outdated or corrupt cookies can trigger an HTTP 400 error. Cookies store website data, including authentication information, but if they become invalid (e.g., due to session expiration), they can cause the server to reject your request.

3. Incorrect file size

In certain cases, an HTTP Error 400 may occur if the file you're trying to upload exceeds the server's size limit. Many web servers impose restrictions on file uploads to ensure performance, and if your file is too large, the request will fail with a 400 error. For example, WordPress sites often limit upload sizes to between 4MB and 128MB.

4. Unsynchronized DNS Cache

A 400 error may result from outdated or mismatched DNS information stored locally in your system's cache. DNS caches store IP address data associated with domain names, but if this information becomes out of sync, your browser may send incorrect data to the server, leading to a bad request error.

5. Server error

While rare, an HTTP Error 400 can also occur due to issues on the server's end. Server misconfigurations or system overloads may result in the server misinterpreting requests as invalid. If you're seeing the error across multiple browsers and devices, this could be the case.

How to fix a 400 Bad Request

Despite being frustrating, resolving a 400 error usually takes just a few simple steps. Here are some common fixes to get your browsing back on track:

When the Problem is Server-Side

If you’ve followed all the steps and the HTTP Error 400 persists, the issue may be on the website’s server. Unfortunately, in such cases, there’s little you can do other than wait for the site administrators to fix the problem. Reporting the issue to the website owner can help speed up the resolution, and websites like Down Detector can provide information on any widespread outages affecting the site.

Although 400 errors can be perplexing, they often have simple causes like a mistyped URL or outdated browser data. By following these troubleshooting steps, you should be able to quickly identify and resolve the issue in most cases.

How to Prevent Future HTTP 400 Errors

While HTTP 400 errors are often easy to fix, you can take proactive steps to reduce the likelihood of encountering them in the future. Here are some practical tips to help keep your browsing experience smooth:

While humans can be identified by names, social security numbers, and biometrics of varying lengths and formats, internet hosts are identified by fixed-format IP addresses. Depending upon the version, IP addresses can either be 32-bit numbers in four decimal blocks or 128-bit characters in eight hexadecimal blocks. For example, an IPv4 address might look like 192.168.1.1, whereas an IPv6 address looks like 2001:0db8:85a3:0000:0000:8a2e:0370:7334.

It’s nearly impossible for humans to remember such multiple long strings of numbers – even remembering a phone number takes more conscious effort than a name or mnemonic phrase does. This is where the Domain Name System (DNS) comes in; it enables humans to locate Internet hosts by a recognizable name.

DNS defined

DNS is an application-layer protocol that translates human-readable host names into IP addresses. 

Often referred to as the "phonebook of the internet", DNS allows websites to stick to memorable and understandable addresses such as www.itpro.com, rather than requiring users to enter the IP address.

Host names cannot fully specify the host location. For example, .uk suggests the host site is in the UK. But where in the UK? It doesn’t provide a specific location. DNS maps host names to IP addresses to specify host location within the network of networks. 

What is a DNS server?

DNS runs in a client-server model and works on UDP/TCP on port 53. A port is a numbered channel that enables a device to handle multiple types of network traffic at once. It’s like a numbered door that leads to a specific service. Port 53 is a dedicated channel reserved for DNS traffic.

A DNS server is a machine that holds all the records of hostnames-to-IP addresses, which are known as DNS mapping. In practice, most DNS servers run on UNIX/LINUX systems using Berkeley Internet Name Domain (BIND) – a purpose-built software suite with industry-wide adoption, powering roughly eight out of ten DNS servers worldwide. It’s freely available under the Internet Systems Consortium (ISC) license.

Every host machine that wants to reach a domain name relies on a DNS client. Just as DNS servers run on BIND, DNS clients are virtually built into every operating system. A DNS client sends a query to a DNS server, asking for the IP address of a specific hostname. The DNS server looks up the hostname in its stored mapping and returns the corresponding IP address. The exchange between the DNS client and server completes the translation process, as the host machine can use the address to load the website. 

DNS process operates in a distributed hierarchy where records are distributed across multiple DNS servers globally to avoid a single point of failure and also decrease latency. There are three classes of DNS servers:

Root name server: A root name server is at the top of the DNS server hierarchy. It doesn’t store the actual IP address, but knows where to direct the DNS query.

The 13 named root name server authorities (labelled A through M) are operated by 12 organizations, including the Internet Corporation for Assigned Names and Numbers (ICANN), NASA, and the US Department of Defence. These 13 root name server authorities are physically deployed over 1750+ server instances worldwide. This is possible due to Anycast routing, which is a technique that enables multiple servers to share the same IP address. As a result, a DNS query automatically reaches the nearest root name server.

TLD name server: A root name server directs queries to top-level domain (TLD) name servers. The TLD name server sits in the middle of the DNS server hierarchy and manages domains like .com, .org, .net, .gov, .edu, and country-specific domains, including .uk, .de, .fr, .jp, etc.

Similar to root name servers, TLD name servers don’t store the actual IP addresses, but know where to send DNS queries based on purpose, type, and geography.

Authoritative name server: TLD name servers map queries to authoritative name servers, which sit at the bottom of the DNS hierarchy. Authoritative name servers are the single source of truth for the DNS because they hold the IP address. An organization can have its own authoritative name server or get one from a service provider.

DNS recursor: DNS recursors are not a part of the DNS server hierarchy because they are not organized, standardized, and managed by a specific organization. DNS recursors are local servers provided by the internet service provider (ISP) or public DNS, like Google (8.8.8.8) and Cloudflare (1.1.1.1). Each host machine is automatically configured to use a single DNS recursor.

How does DNS work?

DNS lookup is the process of sending DNS messages, whether queries or replies, across the internet with the ultimate goal of translating human-readable domain names into IP addresses. All DNS messages are sent as UDP/TCP datagrams to port 53.  

Application-layer protocols, such as hypertext transfer protocol (HTTP), simple mail transfer protocol (SMTP), and file transfer protocol (FTP), use DNS to translate user hostname requests to IP addresses. 

When a user types a website name in the browser, the browser checks its local cache to fetch the IP address. If the IP address isn’t found there, the request moves on to the operating system, which checks its own DNS cache next. 

DNS caching is the first step that application-layer protocols execute for faster processing and less load on DNS servers. Every cached record has a time-to-live (TTL), which specifies the validity of a cached record. After TTL expires, DNS servers discard cache information because IP addresses are not permanent.

To fetch the IP address, HTTP calls gethostbyname() to invoke the DNS client side on the host machine. DNS client then queries the DNS recursor.

DNS recursor sends a query to the root name server, which directs the query to the TLD name server in the middle layer of the DNS hierarchy. Based on the website name, the TLD name server can be .com, .org, .net, .gov, etc. 

The TLD name server points the query to the authoritative name server. Upon receiving the DNS query, the authoritative name server returns the IP address to the DNS recursor. 

DNS recursor further caches the IP address and returns the reply to the DNS client on the host machine. All of this happens within a few milliseconds to seconds. The browser receives the desired DNS record and uses it to initiate a TCP connection to the destination server, with HTTP operating on port 80 to request and load the website. 

Recursive DNS resolver vs authoritative DNS server

Recursive DNS resolvers and authoritative DNS servers are different parts of the DNS lookup process.

A recursive DNS resolver functions as a “librarian”: it performs iterative search operations on behalf of the host machine to fetch IP addresses in the same way a librarian would search for a book a reader wants in a library

In the final steps of the DNS lookup process, the recursive DNS resolver sends a query to the authoritative DNS server, which holds the IP address. Instead of redirecting the DNS query, the authoritative DNS server finally returns the IP address to the recursive DNS resolver.

What happens when DNS fails?

Slow website loading, redirection to spam sites, or simple on-screen error messages, such as “Server not found”, “DNS server not responding," and “This site can’t be reached,” are common indicators of lookup failure. 

While most people encounter DNS failure while they try to open a website, misconfigurations can affect email delivery too. In such a case, the sender's mail server can’t determine where to deliver the email. The mail can return in the inbox with “DNS lookup failed”, “Domain not found”, or “Mail delivery failed”.  

Some common reasons for DNS lookup failure are listed below. 

• Domain shifted to a new hosting service.
• ISP server misconfiguration.
• Outdated routers.
• Incorrect DNS records: Wrong IP addresses or misspelled domains.
• Incomplete records for IPv6 clients.
• Incorrect DNS settings. 
• High TTL. 
• High latency due to geographical constraints.  

Some common methods to fix DNS failure are to restart or update the router, clear DNS cache, update TCP/IP settings, migrate from legacy devices, or switch to public DNS servers.

While DNS lookups can occasionally fail on their own, hackers can target DNS vulnerabilities through DNS DDoS attacks, cache poisoning, and domain hijacking.

Enterprises can combat DNS attacks by following a failsafe strategy. Configuring a secondary DNS as a backup to reroute traffic during an outage can prevent downtime. Another option is to use cloud DNS services like AWS Route 53 and Cloudflare, which have built-in support for DDoS attacks.