Slashdot Mirror

You can fairly easily sign your zones using Bind: http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch04.html#DNSSEC

This takes a few steps:
  * Generate keys - a zone-signing key (ZSK) and a key-signing-key (KSK) - usually a pair of keys for each zone
  * Sign your zones - well, the records inside them
  * Now use your zone.signed file as the zonefile that Bind serves up

Next, once you query your server and everything looks good, you need to ship either the DNSKEY record or DS (digest of the key) to your registrar *. They will ship that to the registry, which signs either your key or digest. Most gTLDs (.com/.org) require only DS records, while ccTLDs (.de/.eu) require DNSKEY records.

Then, as long as you're using a DNSSEC aware resolver, you can test the hierarchy of the signed zone:

dig @149.20.64.21 comcast.com any +dnssec

Look for the "ad" bit set in the Flags section. If you just want to see the keys in this example, simply limit dig to that RR type:

dig @149.20.64.21 comcast.com dnskey +multiline +dnssec

DNSKEY 257 is the key-signing-key, which was sent to the registry, while DNSKEY 256 is the zone-signing key. Dig +trace to see the DS records at the .com registry - they host two different digests for the same key tag/id (35356):

dig comcast.com dnskey +multiline +dnssec +trace

You'll often notice zones with multiple keys - you must support more than one key at a time to enable key rotation. E.g. You, as an authoritative server operator, may wish to rotate your zone-signing key fairly often, while you may wish to rotate the key-signing-key once per year. Each registry decides the expiration of the key or digest they are storing.

* = Not all registrars support DNSSEC; once you sign your domain you cannot transfer the domain to a non-DNSSEC enabled registrar. Either you have to un-sign it or transfer it somewhere else.

There is no certificate authority involved, as the DNS hierarchy contains the signature chain, from the root servers, to each TLD, to each domain. One proposed use of DNSSEC is to publish an SSL certificate public key -- then no Certificate Authorities are required! A browser can use the DNSSEC validated response to match the public key (or more likely, fingerprint) to the web server it is connecting with. You can already use DNS to publish SSH key fingerprints, now you can sign that record for even more trust.

I'll take DNS caching for $200, Alex. I don't think Google should be taking the blame for the additional load.

BIND9 has a concept called views. Views are separate sets of option{}; and zone{}; scopes based on client address or destination address or even something else.

It's very easy to define an external zone without recursion and some master zones and an internal zone that recurses. This also has the benfit of split caches. If you just disabled recursion for some clients in a "single-zone" BIND, you still are "vulnerable" to information leakage where external clients can probe your cache for records.

http://www.bind9.net/manual/bind/9.3.2/Bv9ARM.ch06 .html#view_statement_grammar

Jesus Tom, this is twice in a week I've seen you get moderated up for blatantly false statements on Slashdot. As saikatguha266 rightfully pointed out, operating the root DNS servers requires a massive amount of bandwidth and has high operating costs. In addition to that, DNS queries are already recursive, so I don't understand what your point is. People who don't even understand how the DNS protocol works, and try to assert that a fundamental component of how it works--recursion--isn't used, shouldn't criticize it.

You're not insightful, you're suggesting making them waste even more money than is already wasted. As someone else pointed out (http://www.bind9.net/dnshealth/), many DNS servers are already improperly configured and as a result, are bombarding the root DNS servers with tons of unnecessary queries. It's a huge waste of bandwidth and resources. If DNS servers were configured properly, respecteced DNS TTLs, cached queries properly, a huge burden would be taken off the root servers, and they could actually lower their prices.

http://www.bind9.net/dnshealth/ -- 98% of all queries to the root name servers are bunk.

* Off-topic, but can someone explain to me why (at least with ISC dhcpd) I can't assign IPs on two different subnets on the same physical LAN? Can this be done with a different DHCP server? Is there any kind of limitation to the protocol that makes this impossible, or is it just an implementation problem?

You can run multiple subnets on the same physical LAN, although this is generally a bad idea since you'll spend a lot of time tracking down odd glitches and problems. You will, of course, have to route between those two subnets if you expect them to communicate.

ISC DHCP (or any DHCP server) will receive your DHCP request in one of two ways. Either as a broadcast packet, which indicates the DHCP client is on the local subnet, or as a unicast packet from a DHCP relay agent (i.e. a router with ip-helper configured in Cisco-speak). The unicast packet contains the IP address of the relay agent which lets the DHCP server know which pool of addresses to draw your lease from.

You cannot have mulitiple IP addresses assigned to an interface with a DHCP relay agent or to an interface which has a DHCP server bound to it. That breaks the protocol since it makes it impossible for the DHCP server to determine which pool of leases to draw from. See the RFC for more details. http://www.bind9.net/rfc-dhcp

You also cannot use DHCP to assign two IP addresses to a single client NIC, whether those addresses are on the same subnet or not.