DNS Zone

The global DNS infrastructure is organized as a series of hierarchical DNS zones. The root zone hosts a number of global and country TLDs, which in turn host further zones that are delegated to their customers. Each organization that controls a zone can delegate parts of its namespace to other zones. In this test we perform detailed inspection of a DNS zone, but only if the host being tested matches the zone.

Nameserver Names

Nameservers can be referred to by name and by address. In this section we show the names, which can appear in the NS records, the referrals from the parent zone, and the SOA record. In some situations, servers from the parent zone respond authoritatively, in which case we will include them in the list as well.

Nameserver Addresses

This section shows the configuration of all discovered nameservers by their IP address. To find all applicable nameservers, we inspect the parent zone nameservers for names and glue and then the tested zone nameservers for NS records. We then resolve all discovered names to IP addresses. Finally, we test each address individually.

Start of Authority (SOA) Record

Start of Authority (SOA) records contain administrative information pertaining to one DNS zone, especially the configuration that's used for zone transfers between the primary nameserver and the secondaries. Only one SOA record should exist, with all nameservers providing the same information.

Backing DNS Queries

Below are all DNS queries we submitted during the zone inspection.

DNS Records

Correctly functioning name servers are necessary to hold and distribute information that's necessary for your domain name to operate correctly. Examples include converting names to IP addresses, determining where email should go, and so on. More recently, the DNS is being used to communicate email and other security policies.

DNS Records

These are the results of individual DNS queries against your nameserver for common resource record types.

Backing DNS Queries

Below are all DNS queries we submitted while inspecting the resource records.

DNSSEC

DNSSEC is an extension of the DNS protocol that provides cryptographic assurance of the authenticity and integrity of responses; it's intended as a defense against network attackers who are able to manipulate DNS to redirect their victims to servers of their choice. DNSSEC is controversial, with the industry split largely between those who think it's essential and those who believe that it's problematic and unnecessary.

Useful DNSSEC Tools

• Test wgvc.com @ DNSViz
• Test wgvc.com @ DNSSEC Analyzer (Verisign Labs)
• Zonemaster (iiS and AFNIC)

Certification Authority Authorization

CAA (RFC 8659) is a new standard that allows domain name owners to restrict which CAs are allowed to issue certificates for their domains. This can help to reduce the chance of misissuance, either accidentally or maliciously. In September 2017, CAA became mandatory for CAs to implement.

Email (SMTP)

An internet hostname can be served by zero or more mail servers, as specified by MX (mail exchange) DNS resource records. Each server can further resolve to multiple IP addresses, for example to handle IPv4 and IPv6 clients. Thus, in practice, hosts that wish to receive email reliably are supported by many endpoint.

220 ahs4.r4l.com ESMTP Postfix (Ubuntu)
EHLO outbound.hardenize.com
250-ahs4.r4l.com
250-PIPELINING
250-SIZE 102400000
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING
QUIT
221 2.0.0 Bye

Email TLS (SMTP)

Transport Layer Security (TLS) is the most widely used encryption protocol on the Internet. In combination with valid certificates, servers can establish trusted communication channels even with users who have never visited them before. Network attackers can't uncover what is being communicated, even when they can see all the traffic.

Email Certificates (SMTP)

A certificate is a digital document that contains a public key, some information about the entity associated with it, and a digital signature from the certificate issuer. It’s a mechanism that enables us to exchange, store, and use public keys. Being able to reliably verify the identity of a remote server is crucial in order to achieve secure encrypted communication.

Certificate #1

Leaf certificate webmail.wgvc.com
Issuer: Let's Encrypt
Not Before: 16 Jul 2025 04:12:43 UTC
Not After: 14 Oct 2025 04:12:42 UTC (expires in 2 months 5 days)
Key: RSA 2048 bits
Signature: SHA256withRSA
 View details

Names	mail.wgvc.com webmail.wgvc.com
Subject DN	CN=webmail.wgvc.com
Subject Key Identifier	66636e033c46e12f348710e06a5dcd8c959d699e
Serial	0613b3c8b96e80a88dac351d9278e9886ae4
Not Before	16 Jul 2025 04:12:43 UTC
Not After	14 Oct 2025 04:12:42 UTC
Validity period	90 days
Key Usage	digitalSignature, keyEncipherment
Extended Key Usage	serverAuth, clientAuth
Must Staple	No
Issuer
Issuer DN	CN=R10, O=Let's Encrypt, C=US
Certification Authority	Let's Encrypt
Validation Type	Domain Validation (DV)
Authority Key Identifier	keyid:bbbcc347a5e4bca9c6c3a4720c108da235e1c8e8
Parent Certificate	http://r10.i.lencr.org/
CRL	http://r10.c.lencr.org/101.crl
Certificate Transparency
Signed Certificate Timestamps	16 Jul 2025 05:11:13 UTC | Let's Encrypt 'Oak2025h2' | Qualified 16 Jul 2025 05:11:15 UTC | Google 'Argon2025h2' log | Qualified
Fingerprints
SHA1	c8be9c7081ea02f97ee0c7b8b291c75c3a53c16b
SHA256	c7af5e4fcbe91014d53551cf51638337f9a8d94bcbf1baaf8c57f55df9f818b4
SPKI SHA256	85394ba3b644ff9fa85c2232dee0f3b1bc24e4954a0af7956462cbf6c64e009c

Analysis

Good

Strong private key

Good. The private key associated with this certificate is secure.

Good

Strong signature algorithm

Good. This certificate uses a strong signature algorithm.

Good

Certificate matches hostname

Good. The provided certificate matches the expected hostnames.

Good

Certificate dates match

Good. The certificate is valid for use at this point of time.

Good

Certificate has not been revoked

Good. This certificate has not been revoked.

Good

Certificate satisfies Apple's CT compliance requirements

Good. This certificate satisfies Apple's CT requirements at present.

Certificate Chain

Leaf certificate

webmail.wgvc.com | c7af5e4
Not After: 14 Oct 2025 04:12:42 UTC (expires in 2 months 5 days)
Authentication: RSA 2048 bits (SHA256withRSA)
 View details

Names	mail.wgvc.com webmail.wgvc.com
Subject DN	CN=webmail.wgvc.com
Subject Key Identifier	66636e033c46e12f348710e06a5dcd8c959d699e
Serial	0613b3c8b96e80a88dac351d9278e9886ae4
Not Before	16 Jul 2025 04:12:43 UTC
Not After	14 Oct 2025 04:12:42 UTC
Validity period	90 days
Key Usage	digitalSignature, keyEncipherment
Extended Key Usage	serverAuth, clientAuth
Must Staple	No
Issuer
Issuer DN	CN=R10, O=Let's Encrypt, C=US
Certification Authority	Let's Encrypt
Validation Type	Domain Validation (DV)
Authority Key Identifier	keyid:bbbcc347a5e4bca9c6c3a4720c108da235e1c8e8
Parent Certificate	http://r10.i.lencr.org/
CRL	http://r10.c.lencr.org/101.crl
Certificate Transparency
Signed Certificate Timestamps	16 Jul 2025 05:11:13 UTC | Let's Encrypt 'Oak2025h2' | Qualified 16 Jul 2025 05:11:15 UTC | Google 'Argon2025h2' log | Qualified
Fingerprints
SHA1	c8be9c7081ea02f97ee0c7b8b291c75c3a53c16b
SHA256	c7af5e4fcbe91014d53551cf51638337f9a8d94bcbf1baaf8c57f55df9f818b4
SPKI SHA256	85394ba3b644ff9fa85c2232dee0f3b1bc24e4954a0af7956462cbf6c64e009c

Intermediate certificate

R10 | 9d7c3f1
Not After: 12 Mar 2027 23:59:59 UTC (expires in 1 year 7 months)
Authentication: RSA 2048 bits (SHA256withRSA)
 View details

Subject DN	CN=R10, O=Let's Encrypt, C=US
Subject Key Identifier	bbbcc347a5e4bca9c6c3a4720c108da235e1c8e8
Serial	4ba85293f79a2fa273064ba8048d75d0
Not Before	13 Mar 2024 00:00:00 UTC
Not After	12 Mar 2027 23:59:59 UTC
Validity period	1095 days
Key Usage	digitalSignature, keyCertSign, cRLSign
Extended Key Usage	clientAuth, serverAuth
Issuer
Issuer DN	CN=ISRG Root X1, O=Internet Security Research Group, C=US
Certification Authority	Let's Encrypt
Validation Type	Not Applicable
Authority Key Identifier	keyid:79b459e67bb6e5e40173800888c81a58f6e99b6e
Parent Certificate	http://x1.i.lencr.org/
CRL	http://x1.c.lencr.org/
CA certificate	Yes (pathlen 0)
Fingerprints
SHA1	00abefd055f9a9c784ffdeabd1dcdd8fed741436
SHA256	9d7c3f1aa6ad2b2ec0d5cf1e246f8d9ae6cbc9fd0755ad37bb974b1f2fb603f3
SPKI SHA256	2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba

Root certificate

ISRG Root X1 | 96bcec0
Not After: 04 Jun 2035 11:04:38 UTC (expires in 9 years 9 months)
Authentication: RSA 4096 bits (SHA256withRSA)
 View details

Subject DN	CN=ISRG Root X1, O=Internet Security Research Group, C=US
Subject Key Identifier	79b459e67bb6e5e40173800888c81a58f6e99b6e
Serial	8210cfb0d240e3594463e0bb63828b00
Not Before	04 Jun 2015 11:04:38 UTC
Not After	04 Jun 2035 11:04:38 UTC
Key Usage	keyCertSign, cRLSign
Issuer
Issuer DN	CN=ISRG Root X1, O=Internet Security Research Group, C=US
Certification Authority	Let's Encrypt
Validation Type	Self-signed
CA certificate	Yes (pathlen unlimited)
Fingerprints
SHA1	cabd2a79a1076a31f21d253635cb039d4329a5e8
SHA256	96bcec06264976f37460779acf28c5a7cfe8a3c0aae11a8ffcee05c0bddf08c6
SPKI SHA256	0b9fa5a59eed715c26c1020c711b4f6ec42d58b0015e14337a39dad301c5afc3

Email DANE (SMTP)

DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone.

SPF

Sender Policy Framework (SPF) is a protocol that allows domain name owners to control which internet hosts are allowed to send email on their behalf. This simple mechanism can be used to reduce the effect of email spoofing and cut down on spam.

DMARC

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is a scalable mechanism by which a mail-originating organization can express domain-level policies and preferences for message validation, disposition, and reporting, that a mail-receiving organization can use to improve mail handling.

MTA Strict Transport Security

SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.

SMTP TLS Reporting

SMTP TLS Reporting (RFC 8460), or TLS-RPT for short, describes a reporting mechanism and format by which systems sending email can share statistics and specific information about potential failures with recipient domains. Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations. TLS-RPT can be used with DANE or MTA-STS.

HTTP (80)

To observe your HTTP implementation, we submit a request to the homepage of your site on port 80, follow all redirections (even when they take us to other domain names), and record the returned HTTP headers.

URL: http://wgvc.com/

URL: http://www.wgvc.com/

HTTP (443)

To observe your HTTPS implementation, we submit a request to the homepage of your site on port 443, follow all redirections (even when they take us to other domain names), and record the returned HTTP headers. We use the most recent set of headers returned from the tested hostname for further tests such as HSTS and HPKP.

URL: https://wgvc.com/

URL: https://www.wgvc.com/

WWW TLS

Transport Layer Security (TLS) is the most widely used encryption protocol on the Internet. In combination with valid certificates, servers can establish trusted communication channels even with users who have never visited them before. Network attackers can't uncover what is being communicated, even when they can see all the traffic.

WWW Certificates

A certificate is a digital document that contains a public key, some information about the entity associated with it, and a digital signature from the certificate issuer. It’s a mechanism that enables us to exchange, store, and use public keys. Being able to reliably verify the identity of a remote server is crucial in order to achieve secure encrypted communication.

DANE (443)

DNS-based Authentication of Named Entities (DANE) is a bridge between DNSSEC and TLS. In one possible scenario, DANE can be used for public key pinning, building on an existing publicly-trusted certificate. In another approach, it can be used to completely bypass the CA ecosystem and establish trust using DNSSEC alone.

Cookies

Cookies are small chunks of text that are sent between your browser and a website. They are often essential to the operation of the site and sometimes contain sensitive information. Session cookies sent from secure sites must be explicitly marked as secure to prevent being obtained by active network attackers.

HTML Content

On virtually all web sites, HTML markup, images, style sheets, JavaScript, and other page resources arrive not only over multiple connections but possibly from multiple servers and sites spread across the entire Internet. For a page to be properly encrypted, it’s necessary that all the content is retrieved over HTTPS. In practice, that’s very often not the case, leading to mixed content security problems.

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) vastly improves security of the network encryption layer. With HSTS enabled, browsers no longer allow clicking through certificate warnings errors, which are typically trivial to exploit. Additionally, they will no longer submit insecure (plaintext) requests to the site in question, even if asked.

HTTP Public Key Pinning

HTTP Public Key Pinning (HPKP) enables site operators to restrict which certificates are considered valid for their domain names. With a valid HPKP configuration, sites can defeat man in the middle (MITM) attacks using fraudulent or misissued certificates. HPKP is an advanced feature, suitable for use by only high-profile web sites.

Content Security Policy

Content Security Policy (CSP) is a security mechanism that allows web sites control how browsers process their pages. In essence, sites can restrict what types of resources are loaded and from where. CSP policies can be used to defend against cross-site scripting, prevent mixed content issues, as well as report violations for investigation.

Subresource Integrity

Subresource Integrity (SRI) is a new standard that enables browsers to verify the integrity of embedded page resources (e.g., scripts and stylesheets) when they are loaded from third-party web sites. With SRI deployed, remote resources can be used safely, without fear of them being modified by malicious parties.

Expect CT

Expect-CT is a deprecated response HTTP header designed to enable web sites to monitor problems related to their Certificate Transparency (CT) compliance. Should any CT issues arise, browsers that supported this header will submit reports to the specified reporting endpoint. Chrome was the browser that introduced support for this response header, but later deprecated it and removed it in version 107.

Frame Options

The X-Frame-Options header controls page framing, which occurs when a page is incorporated into some other page, possibly on a different site. If framing is allowed, attackers can employ clever tricks to make victims perform arbitrary actions on your site; they do this by showing their web site while forwarding the victim's clicks to yours.

XSS Protection

Some browsers ship with so-called XSS Auditors, built-in defenses against XSS. Although these defenses work against simple reflective XSS attacks, they can be abused by skillful attackers to add weaknesses to otherwise secure web sites. These dangers are present in both filtering and blocking modes. At this time, the Safari browser ships with its XSS defenses enabled by default. For this reason, the best approach is to explicitly disable this functionality.

Content Type Options

Some browsers use a technique called content sniffing to override response MIME types provided by HTTP servers and interpret responses as something else (usually HTML). This behavior, which could potentially lead to security issues, should be disabled by attaching an X-Content-Type-Options header to all responses.