Elysia Tools
Navigation
Workflow Playbook
Prepare a DNS zone draft, compare live records, inspect DNSSEC delegation and verify the served HTTPS certificate before announcing a domain.
Hubs
This workflow is for a domain owner or operator preparing to announce a new web hostname or a DNS change. Record the registrar, intended nameservers, target addresses, mail routes and HTTPS hostname before editing anything. In dns-zone-file-record-builder, express the proposed SOA, NS, A or AAAA, CNAME, MX and TXT records that actually apply. Review the generated zone text for wrong owners, missing final dots on target names and accidental conflicts. The tool creates syntax and a readable plan; it does not publish records, control your DNS provider or prove that a resolver can already see the change.
After publishing through your provider, query each hostname with dns-query and compare the returned A, AAAA, MX, TXT, NS or CNAME value with the plan. Write down the query time and which resolver produced the answer. The tool currently uses the system resolver even when a custom nameserver is entered, so do not present its result as a direct authoritative-server check. A stale answer may be cache or propagation rather than a wrong zone; wait for the relevant TTL and repeat before changing records again.
If DNSSEC is enabled, use whois-rdap-dnssec-chain-validator-and-iana-bootstrap-trust-auditor to inspect registrar context and the root-to-apex DS/DNSKEY links. A registrar DS left behind after changing DNS providers is different from an intentionally unsigned delegation. Record which link failed; do not treat an unsigned domain as if a cryptographic chain had passed.
Run ssl-checker against the actual visitor hostname after DNS points to the intended service. Check the served certificate's validity dates and hostname coverage. If the operator has a PEM or CRT file, certificate-decoder can reveal its issuer, subject alternative names and fingerprint, but decoding that file alone says nothing about which certificate the server presents. Compare the two only when you need to investigate a deployment mismatch. Finish with an evidence note: expected records, observed records, check times, DNSSEC state and live HTTPS result. For an existing outage involving captures or request delivery, switch to network-triage-debugging; for selecting an available name, use domain-name-ideation-and-availability instead.
Workflow playbook
Build and validate a proposed SOA, NS and required web or mail records. Treat the output as a change plan to publish through your DNS provider, not as a live zone.
Query each required hostname and record type after deployment. Compare A, AAAA, MX, TXT, NS and CNAME answers with the approved plan; record the resolver and observation time.
Audit RDAP delegation and the DS to DNSKEY chain if DNSSEC is enabled. Distinguish an unsigned delegation from a broken signed chain before changing registrar settings.
Check the live hostname with SSL Checker; inspect a supplied PEM separately when you need to compare SANs, issuer, dates or fingerprint with the intended deployment.
Use the zone builder for a proposed zone; use DNS Query for published A, AAAA, MX, TXT, NS and CNAME records. A generated file is not a deployment or proof of propagation.
Audit DS and DNSKEY when DNSSEC is enabled. Use SSL Checker for the certificate served by a hostname; use Certificate Decoder only for a PEM file you already have.
Finish here for prelaunch evidence. Move to network-triage-debugging when packets, webhook delivery, hosts overrides or endpoint failures need investigation.