关于payments.paystation.co.nz域名DNS解析失败问题的技术咨询

Hey Gareth, let's break down your questions one by one based on DNS best practices and real-world troubleshooting experience:

1. Does this sound accurate? #

Absolutely, Paystation's explanation is spot-on. Here's why:

• DNS lookups use UDP by default, a connectionless protocol where packet loss can happen for all sorts of brief reasons: a blip in network connectivity between your resolver and AWS Route 53, temporary load on Route 53 nameservers, or even a momentary glitch in your local DNS resolver.
• Route 53-hosted domains typically have multiple nameservers (usually 4, as Paystation mentioned), so failing to reach one doesn't mean the domain is unreachable—your client should fall back to querying the others.
• DNS query failures are routine enough that retry logic is considered standard for production applications. If your code isn't retrying, that's likely why these errors are impacting your business instead of being transparent to users.

2. If they keep rotating the IP address of their server(s) wouldn't this cause the same issue? #

IP rotation (like using Elastic Load Balancers or auto-scaling groups) shouldn't trigger "could not resolve host" errors—here's the key difference:

• When a domain's IPs rotate, the DNS records are updated in Route 53. The issue you'd run into would be stale cached IPs (where your resolver or client uses an old IP that's no longer valid), but that would result in connection timeouts/refused errors, not a failure to resolve the host itself.
• As long as Paystation's DNS records are correctly configured with a reasonable TTL (time-to-live) value, your resolver will automatically fetch the new IPs once the old cache expires. The "could not resolve host" error is about failing to get any DNS record response at all, not getting an outdated one.

3. How do you change your client code to make sure DNS is resolved after a failed attempt? I assume the server (Ubuntu 20.04.5 LTS) attempts automatically by default? #

You're partially right about Ubuntu's default behavior, but relying solely on system-level retries can be inconsistent. Let's break this down:

• System-level defaults: Ubuntu 20.04 uses systemd-resolved by default, which has basic retry logic, but the settings (like number of attempts and timeout) might not be optimized for your use case. You can check or adjust these by editing /etc/systemd/resolved.conf—look for DNSRetry= options, or add options timeout:2 attempts:3 to /etc/resolv.conf (note: if using systemd-resolved, this file is symlinked, so edit the resolved config instead).
• Client code retry (more reliable): The best approach is to implement retry logic directly in your application code, since you can tailor it to your specific workflow. For example, in Python, you could wrap DNS lookup/HTTP calls in a retry loop:

  import socket
  import requests
  from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
  
  @retry(
      stop=stop_after_attempt(3),
      wait=wait_exponential(multiplier=1, min=2, max=10),
      retry=retry_if_exception_type(socket.gaierror)
  )
  def make_payment_request():
      response = requests.get("https://payments.paystation.co.nz/api/endpoint")
      response.raise_for_status()
      return response.json()
  

  This example uses the tenacity library to retry up to 3 times with exponential backoff whenever a socket.gaierror (Python's error for "could not resolve host") occurs.
• Other tips: If your application uses a HTTP client library, check if it supports built-in DNS retry. For example, curl has --retry and --retry-delay flags, and many modern HTTP clients allow configuring retry policies for DNS failures.

备注：内容来源于stack exchange，提问作者Gareth Foster