Brindlewatch field guide

A practical guide to responding to website security findings

A monitoring finding is a reason to look closer, not a verdict about your website. Start by recording what you can see, compare it with an approved record, and ask the provider who manages that part of your site before making a change.

Read first. Record clearly. Change only with approval.

Keep a small evidence note

For each check, note the exact hostname, date and time with time zone, the tool or account view you used, and the result you observed. Keep a copy of the relevant alert or provider notice. A timestamped observation helps the person responsible compare it with approved changes.

01

Certificate dates and trust

If a TLS certificate is nearing expiry

A browser warning or an approaching expiry date is useful context. It does not tell you by itself whether your host renews certificates automatically or whether a separate service manages them.

  1. 01

    Inspect the certificate being presented

    Open your site in a browser and use its connection or certificate details. Record the expiry date, the issuer, and the exact hostname you visited. Check that the hostname appears among the certificate’s listed names; include both the root domain and www version if customers use both.

  2. 02

    Review the chain and any browser warning

    Use the browser’s certificate details to note the issuing certificate authority and the intermediate certificates it shows. Record any trust or chain warning. Browsers validate a path to a trusted authority, so if the browser reports a chain problem, ask the host to investigate rather than trying to replace certificates yourself.

  3. 03

    Find out who renews it and how

    Check your hosting or certificate-management panel without changing settings. Identify whether the host manages renewal, an ACME client such as Certbot does, or someone installs certificates manually. Review the last renewal result, next scheduled renewal, and any recent errors. If you cannot find that status, ask the host who owns renewal and when it last succeeded.

Contact the hosting provider when renewal is late, the name is wrong, or a browser reports a trust or chain error. Contact the certificate authority when you need help identifying its issuance or when a certificate appears to have been issued without your request. Let’s Encrypt explains the host-managed and ACME-client paths; NIST SP 800-52 Rev. 2 is a technical reference for certificate names and validation paths, not a step-by-step renewal recipe.

Read the source guidance: Let's Encrypt: Getting Started, Let's Encrypt: Chains of Trust, NIST: SP 800-52 Rev. 2: Guidelines for TLS Implementations

02

Nameservers and public records

If DNS records or nameservers changed

DNS tells browsers and other services where a domain should go. A difference can follow a planned host move, but an unexplained difference deserves review before anyone edits the zone.

  1. 01

    Start with your intended values

    Find the last approved DNS change, hosting instructions, or other current record of the values your site and email should use. If account access itself looks unfamiliar, do not sign in through a message link or use the account to make corrections; follow the escalation steps below.

  2. 02

    Read the public authoritative answers

    First identify the domain’s delegated nameservers, then query the relevant authoritative server for records you use. Compare the answers with the intended values, and note each record’s value, TTL, server, and observation time. Check A/AAAA, CNAME, MX, and TXT records when they are relevant to your website or email.

  3. 03

    Secure accounts that can change DNS

    For the registrar and each DNS provider, use a unique strong password and turn on multifactor authentication or a passkey if offered. Ask the registrar about a transfer lock and how it is removed. ICANN describes a transfer lock as another layer of protection, not a guarantee against hijacking.

Example read-only lookups

Find the delegated nameserversdig NS your-domain.example +short
Read a record from one authoritative serverdig @ns1.example.net your-domain.example A +noall +answer
Repeat for other records you usedig @ns1.example.net your-domain.example MX +noall +answer
These are examples only: replace the .example names with your domain and its authoritative nameserver. DNS lookups read public answers; they do not change records.

CISA recommends checking public DNS against intended destinations and protecting all accounts that can change DNS with multifactor authentication. If an authoritative answer is unfamiliar and no approved change explains it, pause and contact the registrar or DNS provider through a known, trusted channel.

Read the source guidance: CISA: Mitigate DNS Infrastructure Tampering, ICANN: Do You Have a Domain Name? Here’s What You Need to Know

03

Public HTTP response headers

If a security header is missing

You can inspect the response your site already sends without editing the server. A missing header is a prompt to review whether it fits your site; the finding alone does not say what configuration is safe for your pages.

Read the response without changing the site

  1. In browser developer tools, open Network, reload the public page, select its document request, and review Response Headers.
  2. If you prefer a terminal, use a GET request and save only the response headers. This example uses the reserved .example domain and is not a real site:
curl --silent --show-error --dump-header - --output /dev/null https://your-domain.example/

Replace the .example hostname with your own domain. The command displays response headers and discards the response body.

Strict-Transport-Security (HSTS)

Tells browsers to use HTTPS for future connections to the host. Options such as includeSubDomains also affect subdomains, so confirm every affected hostname supports HTTPS before a responsible administrator changes this policy.

Source: MDN Web Docs: Strict-Transport-Security (HSTS)

Content-Security-Policy (CSP)

Restricts which sources a page may load resources from. A policy that is too restrictive can block scripts, styles, images, fonts, or other site features; MDN recommends checking a proposed policy in report-only mode before enforcing it.

Source: MDN Web Docs: Content-Security-Policy (CSP), MDN Web Docs: Content Security Policy implementation

X-Content-Type-Options

With the nosniff value, asks browsers to respect the media type declared in Content-Type instead of guessing. The site must also declare the correct type for each resource.

Source: MDN Web Docs: X-Content-Type-Options

Referrer-Policy

Controls how much address information about the current page is sent as a referrer with requests. Review the policy against how your site uses links and third-party services.

Source: MDN Web Docs: Referrer-Policy

Header settings depend on the site’s pages, subdomains, scripts, and services. Ask your host or a qualified web professional to review compatibility before changing them. Test an approved policy, review the results, then schedule and monitor it.

MDN references: MDN Web Docs: Strict-Transport-Security (HSTS), MDN Web Docs: Content-Security-Policy (CSP), MDN Web Docs: Content Security Policy implementation, MDN Web Docs: X-Content-Type-Options, MDN Web Docs: Referrer-Policy

04

Stop, preserve, and escalate

Pause if anything looks unauthorized

Do not try to undo a suspicious change or regain access by changing settings on your own. Preserve what you can see, note the time and time zone, and contact the provider through a known support channel.

  • An unfamiliar registrar login, device, location, or account activity appears.
  • A registrar contact or recovery address changed without approval.
  • DNS records or nameservers are not recognized and no approved change explains them.
  • A certificate was issued for your domain that you did not request.
  • The domain is in an active dispute, or a provider has locked the account.

Preserve a useful record

Save timestamps, alerts, screenshots, public DNS answers, certificate details, and provider notices. Keep original messages and ticket numbers. Do not share passwords, recovery codes, or private keys when collecting evidence.

Contact the right provider

  • Registrar for domain access, contacts, transfer status, and account locks.
  • DNS provider if it operates nameservers or records separately from the registrar.
  • Hosting provider for the site endpoint and its TLS certificate or response configuration.
  • The certificate authority for an unrequested certificate or questions about its issuance.
  • A qualified DNS security or incident-response professional if no trusted internal owner can investigate.
05

After review and approval

Make changes through the people who own them

This guide is educational. It is not a site-specific audit, diagnosis, or remediation plan, and it does not authorize anyone to change your website, DNS, registrar, or certificate settings.

This guide is educational. It is not a site-specific audit, diagnosis, or remediation plan, and it does not authorize anyone to change your website, DNS, registrar, or certificate settings.

  1. 1

    Test the proposed change in staging or another non-production environment when available.

  2. 2

    Have an authorized owner and the responsible technical provider review what will change and how to roll it back.

  3. 3

    Schedule the approved change for a suitable window, then monitor the site and the relevant TLS, DNS, and header behavior afterward.

If a safe test or qualified review is not available, leave the setting alone and ask the provider responsible for it to advise you.

Further reading

Authoritative references

These sources support the specific checks and explanations above. They are not a site-specific assessment of your domain.