Friday, December 6, 2013

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 1st 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 :

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

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. 


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

59 * * * * /usr/sbin/ntpdate -b  > /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


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


Do not use digunless you  compare the output to a known good  sources

e.g ( very bad without any validation )

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


 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


Enable validation within your named conf options ;

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


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


pkill -HUP named

Cool means for testing DNSSEC

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


dig +dnssec @ dnskey


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

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

3: Theses site also has some good checks & tools

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 )=
       /     \

1 comment:

  1. this is good post.
    and you can go here

    tanks very much.... :)