DNSSEC recursive servers by socpuppets, made easy as 1 2 3 4 5

1st let look at what DNSSEC offers

DNSSEC advantages

1: The owner of the signed zone information, can build confidence in his end-users, that no part of the response or data was compromised

2: A small performance penalty, but  a major security enhancements for the dns systems in whole

3:  The local clients are protected from a hijacked response 
( poisoned responses )

DNSSEC dis-advantages

1: The signing of zone data can be complex,  and intimidating for the 1^st time user

2: It's easy to "DoS"  your domain  if you have problems or make a mistaken ( been their.... done that :(   )

3: Not all systems within  the DNS levels  uses DNSSEC 
( resolvers, tld, ccTLD, etc…..  trust-points    ......aka trust-anchors... )

4: Firewalls might restrict or block large UDP response 
( lack of EDNS0 support  or improper configure local systems   )

5: A firewall might not be open for dns 53/tcp 
( the old habit of restricting  tcp/53 only for AXFR and  TSIG  between authoritives pairs .... bad practices & improper configured local systems ! )

6: our trust-anchors maintenance,  could be easily overlooked and doesn’t scale very well when hiearchrial levels of trusts are not chained 
( island of trust-points boundaries exists  )

7: DNSSEC is greatly mis-understood by the general population, and poorly implemented 

8: Not all DNSSEC servers understands all alogrithims 
( NSEC3 issues )

9: Changing to a new registrar & dnssevers,  could be problematic if you depend on DNSSEC

10: Older DNS servers did not fair well with response over 4K bytes

11: IPS/DDoS mitigation gear might mistakenly block large UDP response and/or udp fragments which is commonly seen in 1400+ bytes response sizes

( they assume it's part of an attack.... a lot of false positives  )

12: DNSSEC is not very well adapted on all corners of planet earth due to all of the above and lack of experience by domain administrators 
( the issues of  island of trust boundaries again  )

                              

13: Most larger ISP are ignorant of DNSSEC,  and of  the value it offers, so the large massives of end-users have no protection afforded by DNSSEC 

The two following slides shows  what a DNSSEC trust-point boundary and how the chain is broken per-se

In each of the above examples, we have a non contiguous  hierarchical  systems  & with regards to the DNSSEC protocol from the root to the subzone level ( see the red ovals... these  break the chain )

We can remediate some oft this via trust-anchors to some degree,  but that doesn't scale very well.  ( your only as strong as your weakest link )

fwiw: All "dot" root-servers are DNSSEC enabled for well  over 2+ years now  reference :  http://www.root-dnssec.org/

Okay now let's look at a bind9 recursive name-servers,  and with us adding the ability for DNSSEC for  a local resolver ;

1:

Ensure you should have the the correct system time.  A stratum 3 time-source or  better imho.

I never trust  the ntpd daemon  alone , and prefer using the ntpadate tool or a regular interval. We typically  executed ntpdate on a regular interval &  against a stratum  external time reference. 

e.g 

( update to 2 fictious ntp sources  via a cron job  every @  59mins on the clock)

59 * * * * /usr/sbin/ntpdate -b  1.1.1.1  2.2.2.2  > /dev/null 2>&1

With ntpdate and the <-b> option,  you will always step the time  vrs the slower skew time updates. A interval of 5mins seems to be sufficient on systems that don't managed ntpd and the correct time properly. Every hour would be my extreme interval imho

2: 

Install the trust anchor from a known secured site using a HTTPs enable website 

e.g

https://www.iana.org/dnssec

Do not use dig, unless you  compare the output to a known good  sources

e.g ( very bad without any validation )

dig +short +noall +answer . dnskey  | grep -E -v '^($|;)'

3:

 Modify the named.conf file with the following;

include "/etc/bind/bind.keys";

and touch the following file in your bind directory;


touch /etc/bind/managed-keys.bind

4: 

Enable validation within your named conf options ;

        dnssec-enable yes;
        dnssec-validation yes;
        managed-keys-directory "/etc/bind";

5: 

(optional) 

enable the logging channel for dnssec in your named.conf

logging {
  channel logdnssec {
    severity info;
    syslog local7;
    print-time yes;
    print-severity yes;
    print-category yes;
    
  };

category  dnssec  { logdnssec; };

};

After you have made the above configurations changes, you must restart or reconfig the named process;

rndc reconfig

rndc reload

or

pkill -HUP named

Cool means for testing DNSSEC

1: Using the unix dig command & with the dnssec option;

e.g

dig +dnssec isc.org @8.8.4.4 dnskey

and


dig +dnssec +multiline -t ns com. @127.0.0.1 | more

2: if your lazy, you can use the versignlabs link below for external testing on authoritive DNS servers:)

http://dnssec-­‐debugger.verisignlabs.com      

3: Theses site also has some good checks & tools

http://www.dnssec-tools.org/download/#gotoDNSSEC-Check

http://viewdns.info/



And here's some misc information that might come in handy

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(  @   O )=

          o

       /     \