DNSSEC introduces a delegation signer (DS) record to allow the transfer of trust from a parent zone to a child zone. A zone operator hashes the DNSKEY record containing the public KSK and gives it to the parent zone to publish as a DS record.
Every time a resolver is referred to a child zone, the parent zone also provides a DS record. This DS record is how resolvers know that the child zone is DNSSEC-enabled. To check the validity of the child zone’s public KSK, the resolver hashes it and compares it to the DS record from the parent. If they match, the resolver can assume that the public KSK hasn’t been tampered with, which means it can trust all of the records in the child zone. This is how a chain of trust is established in DNSSEC.
Note that any change in the KSK also requires a change in the parent zone’s DS record. Changing the DS record is a multi-step process that can end up breaking the zone if it’s performed incorrectly. First, the parent needs to add the new DS record, then they need to wait until the TTL for the original DS record to expire before removing it. This is why it’s much easier to swap out zone-signing keys than key-signing keys.
Explicit Denial of Existence
If you ask DNS for the IP address of a domain that doesn’t exist, it returns an empty answer—there’s no way to explicitly say, “sorry, the zone you requested doesn’t exist.” This is a problem if you want to authenticate the response, since there’s no message to sign. DNSSEC fixes this by adding the NSEC and NSEC3 record types. They both allow for an authenticated denial of existence.
NSEC works by returning the “next secure” record. For example, consider a name server that defines AAAA records for api, blog, and www. If you request a record for store, it would return an NSEC record containing www, meaning there’s no AAAA records between store and www when the records are sorted alphabetically. This effectively tells you that store doesn’t exist. And, since the NSEC record is signed, you can validate its corresponding RRSIG just like any RRset.
Unfortunately, this solution allows anybody to walk through the zone and gather every single record without knowing which ones they’re looking for. This can be a potential security threat if the zone administrator was counting on the contents of the zone being private. You can read more about this problem in DNSSEC: Complexities and Considerations, as well as Cloudflare’s unique solution in DNSSEC Done Right.
If you use custom name servers, you must configure your resource records through your name server provider. Resource records are stored with name servers. Google Domains provides name servers at no additional cost and allows you to configure resource records directly.
Learn how to manage name servers. For examples of resource records, go to resource record types. When you add resource records in Google Domains, you must complete the following fields. Host name The Host name field
indicates the object a resource record refers to. For example, a record might be relevant for your entire website, like example.com, or just a subdomain, like shop.example.com. There are different ways to format the Host name field to specify what you want a resource record to apply to. If you’re not sure what to include in the Host name field, contact the service provider for your record type, such as your email service. Below are some common formats: Apply a record to an
entire domain If you want a resource record to apply to your entire domain, like example.com, you can leave the Host name field blank, or add the “@” symbol. For example:
Host name Type TTL Data @ A 1H 123.123.123.123 Apply a record to a single subdomain If you want a resource record to apply to a single subdomain, like shop.example.com, include the prefix in the Host name field. For example:
Host name Type TTL Data shop A 1H 123.123.123.123 Apply a record to multiple subdomains If you want a resource record to apply to multiple subdomains that don’t have any other resource records defined, you can use a wildcard record. For example, you could format the Host name field with an asterisk (*), followed by a dot (.), followed by your domain name. For example:
Host name Type TTL Data *.example.com MX 1H mailhost1.example.com. Important: You can only use wildcard records for some record types. If not used properly, wildcard records may return unexpected results. For more detailed info, go to RFC 1034 (section 4.3.3) and RFC 4592. For more examples, go to
RFC 4592 (section 2.2.1). Type of resource record Time-To-Live To make internet resources more efficient, a device may store info about a website. To make sure resources are up-to-date, Time-To-Live (TTL) defines how frequently a resource record should be refreshed. By default,
Google Domains offers the most common refresh values: You may select Other and enter any value in seconds.Learn about resource record fields
Record's data
The record's data depends on the resource record types. For example, an A record would include an IP address in the Data field. If you’re not sure what info to include, contact the service provider for your record type, like your email service for MX record types.
Create or modify a resource record
Important: Updates to resource records may take 24-48 hours to propagate across the entire internet. That means different internet users may get different results when they try to access or use your site during that time. This delay is due to the fact that for efficiency, most machines and browsers store or cache info about your website. That way, they don’t have to look up all of the details of the resource records every time the website is accessed.
Use the Time-To-Live (TTL) field to define how often machines and browsers should update your records.
Add a resource record
- Sign in to Google Domains.
- Select the name of your domain.
- At
the top left, click Menu DNS.
- At the top of the page, confirm that the Google Domains tab is set to "Google Domains (Active)." If the Custom tab is set to "Custom (Active)," you use custom name servers and must configure resource records with your name server provider.
- Under “Resource records,” click Custom records Manage custom records.
- In the gray boxed area, add field values.
To include multiple records with the same Host name, Type, TTL, and Data values at the same time, you can use “Add more to this record.” This is known as a resource record set. For examples of how to format entries, check resource record types. - To add another record, click Create new record > Save.
Modify or delete a resource record
- Sign in to Google Domains.
- Select the name of your domain.
- At the top left, click Menu
DNS.
- At the top of the page, confirm that the Google Domains tab is set to "Google Domains (Active)." If the Custom tab is set to "Custom (Active)," you use custom name servers and must configure resource records with your name server provider.
- Under “Resource records,” click Custom records Manage custom records.
- Edit the Type, TTL, or Data fields directly, or to delete an entire record, click Delete . If you want to remove one data field from a record set, click Remove .
Important: If you click Delete
- Click Save.
Export resource records
To export the resource records you set up in Google Domains with a different DNS provider:
- Sign in to Google Domains.
- Select the name of your domain.
- At the top left, click Menu DNS.
- Select Google Domains.
Tip: If Google Domains is set to "Google Domains (Active)" you currently use our default name servers. If the Custom tab is set to "Custom (Active)," you currently use custom name servers and must configure resource records with your name server provider.
- Under “Resource records,” click Export DNS records.
- Choose the file type you want to export:
- BIND: A BIND file is a .txt file many DNS providers commonly use to describe resource records.
- YAML: A .yaml file is exclusive to Google Cloud DNS. This option only works if you export your DNS resource records in Google Cloud DNS.
Was this helpful?
How can we improve it?