Author Archive: firstdns

Hi, i have a question about the dns root servers. For example if i want to resolve a domain www.google.com. i start from the dot(.) and then i go down(tree) and i find the com. and then another level down is the google.com. etc. The question is the f.root-servers.net which is a dns root server is located under the .net and then another level down root-servers.net etc?

Thanks in advance!

Lets say hypothetically you have a primary domain ‘example.com’. You have an external IP block 60.50.100.0/24 and internal IP block 10.150.0.0/24.

How would you handle issuing different IPs depending on the source network performing the lookup?

Eg. http://serviceA.example.com has two network interfaces. The internal host performing a lookup should get internal IP instead of external IP. The external host should get the external IP on lookup.

Isn’t it bad practice to run multiple servers authoritative over the same primary zone?

Is there a way you can tell the internal DNS server to forward to the external server? Since both have the primary zone, if possible, I assume there may be some special configuration required.

This is something I’m trying to figure out in a Windows Server lab so I’d rather not get BIND into this.

Thoughts?

Sorry, I didn’t have much time when I posted this. If anyone has additional questions, go ahead. My Macbook Pro and another laptop works fine on the same internet, by the way.

Details: http://gyazo.com/11d69351a6fa1d47dc82239478e489ab

Let’s just say that a recent post inspired me. 🙂 There are a few pre-requisites to this, and it won’t cover less common setups (such as a setup that involves multiple masters accepting zone updates), but just the same, the requirements aren’t necessarily crazy, either:

• A modern installation of BIND. My master is on 9.8.2, which ships with RHEL6. The below steps should work for 9.7 or newer.
• The ability to set a DS record with your registrar
• A zone to sign!

I run my master on CentOS6 with SELinux in full enforcing mode, but not in a chroot. Given that, the below steps will use CentOS-specific paths for their examples, and you may need to modify some of the paths to fit your environment. I’ll be using dnssec.inconcise.org in my examples.

Step one: create a directory to store the keys for your zone, and generate the Key Signing Key (KSK).

# mkdir -p /var/named/keys/dnssec.inconcise.org # cd /var/named/keys/dnssec.inconcise.org # dnssec-keygen -K . -a RSASHA512 -b 2048 -n ZONE -f KSK dnssec.inconcise.org Generating key pair.......................................+++ Kdnssec.inconcise.org.+010+07827 

The last line of text is the file name that has been generated for your KSK. It includes the algorithm information (010 is RSASHA512), and the key identifier (7827). They key identifier is just a unique way to identify the key, little more.

This will generate a key that is used to sign only the Zone Signing Key (ZSK), which will be generated in a moment. This key will be used to generate the DS record, which will need to be uploaded to your registrar (or upstream NS). Generate the DS records now:

# dnssec-dsfromkey Kdnssec.inconcise.org.+010+07827.key dnssec.inconcise.org. IN DS 7827 10 1 5D203F5D678A64563690B115C3095921DD8F3E9E dnssec.inconcise.org. IN DS 7827 10 2 791EC9B58E6380ED64BFE0BF9692B16554C1DD2DDBE6354F3C770444 34287FB0 

Two records were output. You only need to include one of them, but including both won’t harm anything. The values stored in these records are little more than the contents of your public key, run through different hashes. Keep these records for later use.

Generate the Zone Signing Key (ZSK):

# dnssec-keygen -K . -a RSASHA512 -b 2048 -n ZONE dnssec.inconcise.org Generating key pair..................+++ ......................+++ Kdnssec.inconcise.org.+010+52835 

Great, we now have a Key Signing Key, and a Zone Signing Key. The ZSK has an identifier of 7827, while the KSK has an identifier of 52835.

Tidy up the permissions on your keys, and ensure that everything is properly labeled:

# chown -R named:named /var/named/keys # chmod 700 /var/named/keys /var/named/keys/dnssec.inconcise.org # chmod 600 /var/named/keys/dnssec.inconcise.org/* # restorecon -R /var/named/keys 

This would be a good time to back up your zone files. Once enabled, BIND will automatically sign the zone, which will increase the zone file size significantly.

Modify your zone stanza in named.conf to tell BIND to manage DNSSEC for your zone. I’ve included my complete zone stanza here for simplicity.

zone "dnssec.inconcise.org." IN { type master; file "data/dnssec.inconcise.org.zone"; allow-transfer { key inter-server-key; }; update-policy { grant local-ddns zonesub any; }; key-directory "keys/dnssec.inconcise.org"; auto-dnssec maintain; }; 

The important bits are the key-directory and auto-dnssec statements. The key-directory statement tells BIND where to find the keys, while the auto-dnssec statement instructs BIND to manage the signatures automatically.

Reload BIND and it should automatically sign your zone:

# rndc reload server reload successful # tail -n100 /var/log/messages | grep dnssec.inconcise.org Jan 18 20:19:13 nsx named[770]: zone dnssec.inconcise.org/IN: loaded serial 1 Jan 18 20:19:13 nsx named[770]: zone dnssec.inconcise.org/IN: reconfiguring zone keys Jan 18 20:19:13 nsx named[770]: zone dnssec.inconcise.org/IN: next key event: 18-Jan-2015 21:19:13.015 Jan 18 20:19:13 nsx named[770]: zone dnssec.inconcise.org/IN: sending notifies (serial 2) Jan 18 20:19:18 nsx named[770]: zone dnssec.inconcise.org/IN: sending notifies (serial 3) 

Let’s also configure NSEC3. To do that, add an NSEC3PARAM record to the root of the zone in question:

# nsupdate -l > update add dnssec.inconcise.org. 86400 NSEC3PARAM 1 0 150 76ff87789d6385b2 > send > quit # tail -n40 /var/log/messages | grep dnssec.inconcise.org Jan 18 20:37:38 nsx named[770]: client 127.0.0.1#7731: updating zone 'dnssec.inconcise.org/IN': adding an RR at 'dnssec.inconcise.org' NSEC3PARAM Jan 18 20:37:39 nsx named[770]: zone dnssec.inconcise.org/IN: dns_zone_addnsec3chain(hash=1, iterations=150, salt=76FF87789D6385B2) Jan 18 20:37:39 nsx named[770]: zone dnssec.inconcise.org/IN: zone_addnsec3chain(1,CREATE,150,76FF87789D6385B2) Jan 18 20:37:39 nsx named[770]: zone dnssec.inconcise.org/IN: sending notifies (serial 4) 

(Note: the ’76ff87789d6385b2′ is simply used as a salt to the hash. Specify any 16 hex bytes to use for this, or generate it with “head -c300 /dev/random | sha1sum | cut -b 1-16”.)

The zone has been updated three times: once to include the proper keys into the zone, and again once all of the signatures have been generated. Lastly, we inserted an NSEC3PARAM RR, which caused the NSEC RR chain to be replaced with a NSEC3 RR chain. Ensure that your zone is fully in sync across your slaves.

This would be a good time to validate your configuration before flipping the big “on” switch.

• Ensure that you have DNSKEY records in your zone: dig @localhost dnssec.inconcise.org. DNSKEY
• Ensure that your records are signed, based on the presence of the RRSIG records: dig @localhost +dnssec dnssec.inconcise.org.
• Test your config signing with DNSViz (http://dnsviz.net/). Give it an A record in your zone, and it should show you that you have a chain from your KSK to your KSK to your record within your zone (sample).

The final step is to add your DS records (that were generated earlier) to the parent zone. Most registrars have an interface where you can simply paste the record in, and it’ll parse it for you. This step is what will signal all DNSSEC aware resolves to validate your zone: if anything is wrong, your zone will stop resolving, and you’ll only have two choices: back the DS records out, or fix your DNSSEC problem, whatever that may be. 🙂

Once done, DNSViz should show you a fully authenticated chain from the zone apex, all the way down to your record, like so.

That’s it! Your zone is signed.