[sf-lug] DNSSEC - how (not) different to maintain?
Michael Paoli
Michael.Paoli at cal.berkeley.edu
Thu Nov 3 23:36:23 PDT 2016
So, for those that may be curious (and also for those that might need to
maintain DNS on that host) ... what's different? Although there
certainly are additional steps to setting it up, once in place, most of
the routine maintenance is quite the same. Below I show what's
different in the config files. I'm essentially using the
"bump in the wire" method - but without an intermediate server.
So, some slight changes to implement that, and there was some general
maintenance, and some nameservers that were not up to snuff for serving
DNS with DNSSEC were dropped, and that's basically it. Master zone
files can be maintained quite as they were before. With
"bump in the wire", the server adds the signing, and the actual data
served may be a "higher" (Per DNS RFC arithmetic) serial number, but
that's it, the regular DNS maintenance remains quite the same. The only
portion that would be relatively different, would be rolling the KSK
keys - but that's generally done rather rarely (if at all), and needn't
be done at all, if one so chooses (and presuming also the KSK keys
aren't compromised).
Also the nameserver is running chroot ... was in earlier Debian release,
lost that change on change of init system to systemd ... added file to
have it run in chroot again. I have structure in place - symbolic links,
appropriate device files, etc., so the nameserver can and does run under
chroot - and will also run just fine without chroot. Additionally, with
or without chroot, the paths/locations are logically the same - but of
course physically different for chroot.
I also made some very slight minimal changes on ownerships/permissions
on some directories for the running nameserver to be able to do and
manage and track its automatic zone signing.
# hostname
balug-sf-lug-v2.balug.org
# pwd && pwd -P
/etc/bind
/var/lib/named/etc/bind
# rcsdiff -r1.4 -r1.5 named.conf.options 2>>/dev/null
2a3
> key-directory "/var/cache/bind/keys";
# rcsdiff -r1.12 -r1.14 named.conf.local 2>>/dev/null
51c51
< # 198.144.195.186; # ns2.sf-lug.com. / linuxmafia.com.
---
> # 198.144.195.186; # ns1.linuxmafia.com.
59c59
< 64.62.190.98; # ns1.svlug.org,
---
> 64.62.190.98; # ns1.svlug.org.
65,66d64
< 216.218.133.2; # for ns[1-5].he.net.
< 2001:470:600::2; # for ns[1-5].he.net.
68a67,69
> inline-signing yes;
> auto-dnssec maintain;
> serial-update-method unixtime;
179,180d179
< 216.218.133.2; # for ns[1-5].he.net.
< 2001:470:600::2; # for ns[1-5].he.net.
182a182,184
> inline-signing yes;
> auto-dnssec maintain;
> serial-update-method unixtime;
# { sudo -l -U jstockford && sudo -l -U grantbow; } | egrep '^User|bind'
User jstockford may run the following commands on balug-sf-lug-v2:
(root) sudoedit /etc/bind/master/sf-lug.org
(root) sudoedit /etc/bind/master/sf-lug.com
(root) /bin/systemctl reload bind9
User grantbow may run the following commands on balug-sf-lug-v2:
(root) sudoedit /etc/bind/master/sf-lug.org
(root) sudoedit /etc/bind/master/sf-lug.com
(root) /bin/systemctl reload bind9
#
And in the master zone files, really nothing more than routine
maintenance (suitable adjustment to SOA serial when changing data,
dropped nameservers that wouldn't properly support DNSSEC, and some
other minor routine maintenance).
$ ls -ld /etc/systemd/system/bind9.service.d
/etc/systemd/system/bind9.service.d/bind9.conf && cat
/etc/systemd/system/bind9.service.d/bind9.conf
drwxr-xr-x 2 root root 1024 Nov 3 23:00 /etc/systemd/system/bind9.service.d
-rw-r--r-- 1 root root 76 Nov 3 23:05
/etc/systemd/system/bind9.service.d/bind9.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/named -f -u bind -t /var/lib/named
$
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Got DNSSEC? :-) (sf-lug.org also now does)
> Date: Tue, 01 Nov 2016 06:02:35 -0700
> And likewise, now sf-lug.org. also has DNSSEC.
>
> Did also a bit earlier notice one missing AAAA glue record,
> and passed that information along for correction.
>
>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>> Subject: Got DNSSEC? :-) (sf-lug.com now does, will add to
>> sf-lug.org in future)
>> Date: Fri, 28 Oct 2016 00:38:08 -0700
>
>> Got DNSSEC? :-) (sf-lug.com now does, will add to sf-lug.org in future)
>>
>> So ... been pokin' at DNSSEC a bit.
>>
>> Anyway, sf-lug.com. now has DNSSEC enabled for the domain.
>> Yes, that's the non-canonical ... sf-lug.org. is canonical.
>> I wanted to start with the lower risk(/impact) domain.
>>
>> Some bits of related information / references:
>> http://dnssec-debugger.verisignlabs.com/sf-lug.com
>> http://dnsviz.net/d/sf-lug.com/dnssec/
>> https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions
>> https://users.isc.org/~jreed/dnssec-guide/dnssec-guide.html
>> TeamNANOG DNSSEC Tutorial: https://www.youtube.com/watch?v=9ksfOUyvNi8
>> file:/usr/share/doc/bind9-doc/arm/Bv9ARM.html
>>
>> If you're doing it using BIND, newer versions make it a fair bit easier.
>> It gets pretty easy with >= 9.9
>> If you're still using nslookup, it's probably past time to break that
>> habit, and only use nslookup as a last resort fall-back, as nslookup
>> knows absolutely nothing about DNSSEC.
>> So, ... use dig, ... right, ... right?
>> Uhm, except ... as of BIND 9.10, dig is being effectively
>> replaced by ... yet another tool ... delv. Which works quite similarly
>> to dig, but better. And, really best to have delv handy to
>> test/troubleshoot DNSSEC - it's also especially good at (pre-)testing
>> DNSSEC - make sure it's all good before going "live" with it.
>> And ... BIND 9.11 promises to be yet easier to manage DNSSEC.
>>
>> Screwing up DNSSEC implementation could be quite bad - in "worst case"
>> one totally knocks the domain (and any subdomains thereof) out of DNS -
>> at least for any resolvers that are DNSSEC aware. More and more
>> resolvers are becoming DNSSEC aware, and increasingly configured to use
>> DNSSEC. And that's not the only place DNSSEC is showing up - e.g. some
>> browsers are adding built-in DNSSEC checks, for additional security, or
>> have it available via a plug-in.
>>
>> Anyway, DNS - critical infrastructure. Likewise DNSSEC - certainly
>> don't want to break it. But, with reasonable care and attention, works
>> quite darn well. And yes, "of course", practice first on non-production
>> recommended.
>>
>> And ... what does DNSSEC *do*? Mostly it makes it much much harder (if
>> not "impossible") for DNS to be spoofed, and such. Notably with DNSSEC
>> signed domain, and DNSSEC enabled resolver, one won't get forged data or
>> incorrect DNS data due to cache poisoning, etc. Without DNSSEC, such
>> attacks are relatively easy and doable (though some other mittigating
>> measures have also been deployed over the years, that at least partly
>> address some of those issues).
>>
>> And, ... what's DNS, ... uhm, yeah, that:
>> https://en.wikipedia.org/wiki/Domain_Name_System
More information about the sf-lug
mailing list