Unused Domain – Add These DNS Records

Why would an unused domain even need any resources records?

It’s common for domains to go unused. Sometimes they’re purchased for a potential idea or project. Other times, it’s to protect a name or trademark, or maybe they’re meant for use internally on a protected and private network. But the internet does weird stuff and sometimes there are steps that should be taken even if these domains aren’t being used.

In August of 2023, @byt3bl33d3r gave a talk at Defcon 31 called “SpamChannel: Spoofing Emails From 2 Million+ Domains and Virtually Becoming Satan,” on how he was able to use Cloudflare Workers to send email as millions of domains and pass many all of the protections meant to stop abuse. The talk is worth watching to see how these systems can be abused. Talk: https://www.youtube.com/watch?v=NwnT15q_PS8.

One takeaway from the talk was to add a null SPF record with “v=spf1 -all” in order to stop this kind of oversight and abuse. This got me thinking: What other DNS records should be in place to protect the abuse of a publicly unused domain?

MX (Mail Exchanger) Records

If the domain isn’t used, we’ll never be receiving email. While this record can simply be left out, we can help tell the internet that’s the case. In fact, RFC 7505 “A ‘Null MX’ No Service Resource Record for Domains That Accept No Mail” provides just this mechanism. A dot ( . ).

Sender Policy Framework, SPF

Of all the resource records, SPF provides the most direct example of how to let others on the web know to not accept email for the domain. In RFC 7208 “Sender Policy Framework (SPF) for Authorizing Use of Domains in Email”, it states, “Publishing SPF records for domains that send no mail is a well-established best practice.” My experience shows that’s not the case. At least as of 2023. But it is right there in the RFC which is helpful.

Domain-based Message Authentication, Reporting, and Conformance, DMARC

This may be overkill, but in the case pointed in the talk, I believe it’s simply extra insurance to go ahead and configure. And, like SPF, configuration helps everybody else detect the abuse and is simply a good netizen practice. For DMARC, there is not a “best practice” for this use case outlined within RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC). However, it’s pretty straight forward to tell the world to reject anything for this domain with the declaration below.

v=DMARC1 → Required. This directive is always the same and required. Simply tells the version, of which there is only one.

p=reject → Required. This is the Requested Mail Receiver Policy and is required for any DMARC record. “Reject” simply tells mail receivers to reject email that fails the DMARC mechanism check.

adkim=s; aspf=s These defines strict (opp. relaxed) conformance/alignment with SPF or DKIM as required. Because there are no DKIM records for this domain and the SPF doesn’t permit a valid sender, these should fail.

spNote: This directive provides a policy if we were using subdomains. In its absence, all subdomains are covered by the primary policy so this isn’t required.

pctNote: This provides a mechanism for mail receivers to apply the policy to a portion of mail received from the sending domain. This is helpful when testing out the impact of a new policy adjustment, especially for high volume senders. Default is to apply to 100 percent so this directive is unnecessary.

DomainKeys Identified Mail, DKIM

DKIM uses selectors to provide a mechanism of providing multiple public keys per signing domain. You can find the details of this within RFC 4871: DomainKeys Identified Mail (DKIM) Signatures. Because of this, when DKIM is used, it’s common to find many different selectors in use. And while some selectors are common (e.g. selector1, selector2, dkim, k1, google), there is no “default” selector we can provide a junk or null value to in order to ensure this check fails. However, requiring DKIM alignment within the DMARC policy should tell a receiving party to require valid DKIM which should always fail, thereby keeping the domain from being abused via email.

Certification Authority Authorization, CAA

CAA records allow a DNS domain name holder to specify one or more Certification Authorities authorized to issue certificates for that domain. The absence of a CAA record enables the domain holder to use any CA they want. Because this is an unused domain, there should never be a certificate issued (at least publicly) for any resources in this domain. RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record provides a mechanism for disallowing CAs following the CAA standard from issuing certificates by creating a CAA record with a value of a semicolon only ( ; ).

Note: For private use of a domain name, an additional benefit of using this mechanism to block certificate issuance is with Certificate Transparency (CT) information leakage. RFC 9162 defines CT as a system of public logs that seek to eventually record all certificates issued by publicly trusted certificate authorities. Blocking them from issuing certificates aids in protecting the private use of certificates and unintended information disclosure.

Root Domain Records: A, AAAA

These records are probably unnecessary and simply personal preference. There are really two acceptable choices here: 1) no records at all, or 2) use of addresses that won’t work on a public or private network. I’ve seen folks recommend private address spaces such as 192.168.0.0/16 or 10.0.0.0/8 or 172.16.0.0/24. However, these records could be abused as they would still potentially resolve to an address that is in use on a private network. If we’re going to use an address for these records, we want it to point to an address that cannot be used. Fortunately, engineers provided options for this in the ipv4 and ipv6 address space.

ipv4 root domain A record or “@”: 192.0.2.1 RFC 5737: IPv4 Address Blocks Reserved for Documentation sets aside 192.0.2.0/24 for use in documentation and advises operators to block or otherwise make inoperable, these addresses on private, public, and local networks.

ipv6 root domain AAAA record: 2001:DB8:: RFC 3849: IPv6 Address Prefix Reserved for Documentation sets aside 2001:DB8::/32 for use in documentation and advises operators to block or otherwise make inoperable, these addresses on private, public, and local networks.

Other Considerations

www CNAME record: There is a lot of debate about whether to use or not use www. The reality is that many things, including some users, prepend a domain name with www for a myriad of reasons. I usually throw this in there to save them a step and give them the domain root answer right away. And with CNAME flattening, I don’t see any downside to including this.

Wildcard DNS: There may be benefits to using a wildcard dns record, if your provider supports this functionality. This will always provide an answer for anything at your domain instead of an NXDOMAIN response.

The DNS Security Extensions: DNSSEC

And of course, none of this ensures the party querying your domain gets a trusted response unless you are signing your zones. Make sure to enable DNSSEC on those zones. If you ever end up using the domain, it’s one less thing you’ll forget about and later have to enable anyway. More info on DNSSEC.

Putting It All Together

Here’s an example zone file with all the recommendations.


Weekend Reading – April 22, 2016

Blogs / News

Microsoft IT Environment Health Scanner

It's essentially a server for business.
It's essentially a server for business.
Most people have a fear of taking their vehicle to the mechanic for even the simplest tasks just to find out they need their transfunctioner adjusted because of wear to the driver’s side steering widget.  For many in the SMB market, that same fear can be found in their technology investments.  “Did that last IT guy wrap our SQL server in duct tape and tie it to the web server with shoe string?”  The reality is often not that bad, but it can be unsettling not knowing.

The first thing I want to check when preparing any SMB (or large scale Enterprise) for a project is the overall health of their environment.  I typically use a few custom scripts, the invaluable tools from Joeware and Sysinternals, plus a few others offered by various vendors to collect the data for analysis.  The standard services are checked, like DNS, DHCP, WINS (ugh), Exchange, AD, NTP, Group Policy, CAs, etc. for overall health and misconfigurations.  Even with the rich ecosystem of tools, this process can be time consuming so I am always looking for ways to streamline the process.

It seems a lot of others were looking for a quick method as well; at least one that can get a quick assessment of whether you are dealing with a disaster or limited pieces to fix.  The Microsoft Essential Business Server runs a check on the environment to assess its health before installation.  From this Microsoft Technet blog, “[the EBS team] noticed that Preparation Wizard was widely used, not just by customers who were deploying EBS, but anyone with Active Directory in their network who wanted to verify the health of their environment.” This gave birth to the Microsoft IT Environment Health Scanner in the summer of 2009.

This free tool does the basic checks I’m going to do anyway but it gives that quick assessment that often tells me whether I need to dig further. Microsoft’s download page states:

When run from a computer with the proper network access, the tool takes a few minutes to scan your IT environment, perform more than 100 separate checks, and collect and analyze information about the following:

  • Configuration of sites and subnets in Active Directory
  • Replication of Active Directory, the file system, and SYSVOL shared folders
  • Name resolution by the Domain Name System (DNS)
  • Configuration of the network adapters of all domain controllers, DNS servers, and e-mail servers running Microsoft Exchange Server
  • Health of the domain controllers
  • Configuration of the Network Time Protocol (NTP) for all domain controllers

Whether you have a small Microsoft IT environment or are Enterprise large, this tool is great for catching those things often overlooked during setup or changes or misconfigured. Download link: Microsoft IT Environment Health Scanner.

Office 365 Deployment Readiness Tool Beta Released

Office365 Migration Readiness Tool
Office365 Migration Readiness Tool

On Friday (May 6th), Microsoft released the Enterprise Beta Readiness Tool for Office365. As the name implies, this tool is meant to do a quick readiness check on your environment.  Upon execution, it will automatically extract the files to C:office365reskit and launch the app within IE. If you system has IE locked down, this may be problematic or at least require the acknowledgement of a few warnings. As it’s running, it collects information (be patient) from your organization’s network into its temp directory (c:office365reskittmp). The files within this directory are plain text and offer an interesting look into the environment. Unfortunately, once the test completes, the utility analyzes and consolidates these temp files and deletes the originating files, leaving a technical person with much to be desired.

 

The report is long and not filled with a whole lot of technical details. It gives basic information about your organization like sip domains, AD functionality levels, Exchange org, object counts and more. It then compares that to known requirements to measure your readiness to migrate to Office365 and gives a pass/fail grade in each category. For an organization looking at Office365, this info will give a good base to start a discovery process towards Office365 readiness.

My overall impression is the tool is a bit rough around the edges but a useful for quick discovery. The information can even be helpful for doing quick, limited Active Directory, Exchange and OCS/Lync discovery (although there are better tools for this job). Microsoft is showings its commitment to what will likely become a pretty aggressive push to business migration to their cloud offerings.

Webcast: Dell, Hyper-V and System Center Goodness

Removing Virtualization Barriers and Simplifying Management with A Frameless Storage Solution and Microsoft System Center

Virtualization is no longer just an IT buzzword –your customers are asking for it, and you’re ready to deliver. But with the different types of storage hardware and protocol choices in the market, are you prepared to offer the best storage option for your customer’s virtualization solution? How about keeping management and maintenance simple after deployment?

Date/Time: April 19, 2011 12 PM Pacific/ 2 PM Central / 3 PM Eastern

Sign up here: http://goo.gl/Cdpkf