simple named.conf with dnssec ?

[mayuka]

Hello.

Has anyone a working simple and secure named.conf for a home server that has dnssec enabled ? I just added dnssec to my (pretty ancient) named.conf, but honestly I'm not sure whether my config is still up-to-date when it comes to security. I'm using the latest openbsd.

I have a very simple configuration at home. The name server only runs on a dialup wifi-router and manages a "localnet" as you can see below:

192.168.1.x -- "localnet" <-> bind on router -> forwarders

How can I verify that my bind talks to the other name server via dnssec?

[J65nko]

According to http://en.wikipedia.org/wiki/DNSSEC DNSSEC has not been been implemented completely yet.

The following packet dump show a DNSSEC answer

23:03:05.558393 B2.ORG.AFILIAS-NST.org.53 > rnames.utp.xnet.36923:  43271-
q: A? www.daemonforums.org. 0/6/2 ns: daemonforums.org. NS
ns.rwxrwxrwx.net., daemonforums.org. NS ns.daemonforums.org.,
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. Type50,
h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. RRSIG,
u1rfjcpe050u05iqk0705qqqilnu83po.org. Type50,
u1rfjcpe050u05iqk0705qqqilnu83po.org. RRSIG ar: ns.daemonforums.org.
A 94.142.245.224, . OPT UDPsize=4096 (605) (DF) (ttl 58, id 0, len
633)

If you want a safe DNS infrastructure, use tinydns and dnscache from Daniel Bernstein

[mayuka]

Originally Posted by J65nko

If you want a safe DNS infrastructure, use tinydns and dnscache from Daniel Bernstein

Thanks for the info. I just read that here in Germany contemporary all ISPs have to enable dnssec...

Shouldn't be a "dig" enough for confirmation?

dig +dnssec @192.168.1.1 localnet

[J65nko]

Originally Posted by mayuka

dig +dnssec @192.168.1.1 localnet

What is stopping you from posting the answer and/or the captured tcpdump output of the answer?

# tcpdump -ni fxp0 -s4096 port 53

[Knobee]

nameservers don't talk to each other "with DNSSEC" -- an outbound query with the DO bit (DNSSEC OK) set tells the upstream server that yours is capable of dealing with DNSSEC replies, in which case you will get RRSIG responses in addition to the actual response to the query that was asked.

It's then up to you to do something with that RRSIG (validation step).

You will need to configure trust anchors on your server if you wish to validate on behalf of the client systems...

I wrote a short paper last year that may be able to help you out, but since I don't have enough "points" to post a URL, you can search for it:

"DNSSEC in 6 minutes"

If you have any questions, feel free to contact me directly (contact info in PDF) or ask on the bind-users mailing list. bind-users can be found again, via google, or look around on the isc.org website.

Knobee

EDIT: DNSSEC in 6 minutes

[Knobee]

Originally Posted by J65nko

According to wikipedia.org DNSSEC has not been been implemented completely yet.

I'm not sure what this means, nor do I find it on that Wikipedia page. BIND is (and has been for several years) completely DNSSEC compliant. The "standard" (as with all things Internet) has changed significantly over the years -- nothing like a "work in progress for 10 years", but I think that it's pretty well covered at this point.

If by "implemented", you mean "the root has not been signed yet" or "not everyone is using DNSSEC", I'm forced to agree.

The root, as-of last week, has signatures (dns-oarc.net slash node slash 240) that, while not able to be used for validation, are able to be used to test traffic patterns with the "larger" packet sizes required by the added signatures.

.gov has been signed for nearly a year. .se has been signed for nearly 5 years. I've been running a signed zone in .org for several months.

It's implemented. It works. It's NOT the answer to phishing attempts, but it does provide a good method of proving validity of DNS traffic end-to-end. (now those SSHFP resource records in my zones are actually worth using!)

Knobee

[mayuka]

Originally Posted by Knobee

"DNSSEC in 6 minutes"

Yes, thanks. The original tutorial i've found was yours I think.

I've found another one here: http://blog.techscrawl.com/2009/01/1...nssec-on-bind/

I did everything that was mentioned in the tutorial. So... I configured it? It's so easy?

[Knobee]

aclegg@Yellow:~$ dig www.isc.org +dnssec

; <<>> DiG 9.7.0 <<>> www.isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4605
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.isc.org.			IN	A

;; ANSWER SECTION:
www.isc.org.		597	IN	A	149.20.64.42
www.isc.org.		597	IN	RRSIG	A 5 3 600 20100226174218 20100127174218 8496 isc.org. uJ0g3BERRDCQ8GwmslhWVDBOc21hZikKrPU565704FQNSGgWeGt8oOZy C+Rjl3v5s+cIzu7oziupYK7qqDNSzYDGa8N6Ogs8v84Mx3edM4np+YCY 7kC8vXXsOpf9laC5t1cfdfNQxF99y/eN8zsLU98Jepnig/sSOV85Yr5Y gBo=

;; AUTHORITY SECTION:
isc.org.		38949	IN	NS	ord.sns-pb.isc.org.
isc.org.		38949	IN	NS	ns.isc.afilias-nst.info.
isc.org.		38949	IN	NS	ams.sns-pb.isc.org.
isc.org.		38949	IN	NS	sfba.sns-pb.isc.org.
isc.org.		38949	IN	RRSIG	NS 5 2 43200 20100226174218 20100127174218 8496 isc.org. JFI0uwkged++iWF0UiMMQYXucO7MLFgjxHJh4YkGMSjAn9R8uaBAfwRj 5ru+QcBY6TM4tBHm/itKaMFJrRRZdjWbVRHSKIKmlSAu1WINxcmIcScY KbSeRcbQIgx53WFwzPJ4GOrEyBwm8Fy2knhj0PeRpL2uptcCLWdpmEnI 588=

;; ADDITIONAL SECTION:
ams.sns-pb.isc.org.	38949	IN	A	199.6.1.30
ord.sns-pb.isc.org.	38949	IN	A	199.6.0.30
sfba.sns-pb.isc.org.	38949	IN	A	149.20.64.3
sfba.sns-pb.isc.org.	38949	IN	AAAA	2001:4f8:0:2::19
ams.sns-pb.isc.org.	38949	IN	RRSIG	A 5 4 43200 20100226174218 20100127174218 8496 isc.org. sdSE0noG61l2vsel+V4JI7NjH5am4p/2QG/2nHPm1tPa4ZQCXlVabSHv cdNNpwTy2jO8yW+PgJ/qBXCpupbnU6IUqy2Co1f7UoZDu1SVwamPvUDS nUmU18dfJLqUdwKZtPBNNoPRYvfMW3K3F18H5+kQPDKBy+pBVhT4DL79 Ick=
ord.sns-pb.isc.org.	38949	IN	RRSIG	A 5 4 43200 20100226174218 20100127174218 8496 isc.org. p3GkEpVSYeZvKYzhH/NxcAQAajBRufkYEVa9ey8zZ1KLP41zj2OqCS73 bg7b8kicNSwFnsbuqX0psKDI7EEgWEHij68Klve+f+xmXwTLy2/Dc3vu 9oDNe0ZlqrdxpMAdk9o9JFD2KtBU7w4KL4aflxqkCNp2fjYY+ltxIxJx Utw=
sfba.sns-pb.isc.org.	38949	IN	RRSIG	A 5 4 43200 20100226174218 20100127174218 8496 isc.org. evxhlGx13mpKLVkKsjpGzycS5twtIoxOmlN14w9t5AgzGBmzdiGdLIrF abqr72af2rUq+UDBKMWXujwZTZUTws32sVldDPk/NbuacJM25fQXfv5m O3Af7TOoow3AjMaVG9icjCW0V55WcWQUf49t+sXKPzbipN9g+s1ZPiIy ofc=
sfba.sns-pb.isc.org.	38949	IN	RRSIG	AAAA 5 4 43200 20100226174218 20100127174218 8496 isc.org. XC9Ml2xeE+Lde/x7We+XJoVyfSRBoDzyhEHF7sClLyCBqpTahnrJfSlh Uezp5xrB9HtVCaxjvX0BiPCyeGTndb1l4PuvKEKtbaYdO6p9mtNzFgD4 3+HsIhWuR+r72vegmV1g4y8g+euzlhCbnnvdHeAicaL3HPHE7l448P3L P8w=

;; Query time: 5 msec
;; SERVER: 192.168.1.2#53(192.168.1.2)
;; WHEN: Sat Jan 30 08:54:49 2010
;; MSG SIZE  rcvd: 1233

[mayuka]

This is what I'm getting... I think I either have misconfigured something or the forwarder from my provider does not support such things...

$ dig www.isc.org +dnssec

; <<>> DiG 9.4.2-P2 <<>> www.isc.org +dnssec
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 646
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;www.isc.org.                   IN      A

;; ANSWER SECTION:
www.isc.org.            488     IN      A       149.20.64.42

;; Query time: 26 msec
;; SERVER: 83.169.185.161#53(83.169.185.161)
;; WHEN: Sat Jan 30 15:02:46 2010
;; MSG SIZE  rcvd: 56

[Knobee]

Originally Posted by mayuka

Yes, thanks. The original tutorial i've found was yours I think.

I've found another one here: URL deleted.

I did everything that was mentioned in the tutorial. So... I configured it? It's so easy?

It's really quite simple once you understand the bits required to make it work (as with all things computer related, eh?)

If you'd like, send me your named.conf (again, e-mail address in .pdf linked above) and I'll let you know what I see.

Here is a validating recursive server configuration that I use on a WD NAS device (Worldbook?) here at my house:

include "/opt/etc/named/trusted-keys";

options {
	directory "/opt/etc/named";
        dnssec-enable yes;
        dnssec-validation yes;
	listen-on-v6 { any; };
	
	notify no;

        dnssec-lookaside . trust-anchor dlv.isc.org.;
        zone-statistics yes;
};

The "trusted-keys" file contains:

trusted-keys {

dlv.isc.org. 257 3 5 "BEAAAAPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
	brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
	1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
	ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
	Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
	QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
	TDN0YUuWrBNh";
};

This allows me to validate all DNSSEC signed zones that have published their DS records (actually DLV records, but they are pretty much identical) in the ISC DLV registry.

I'm going to be teaching a DNS and BIND class next week, followed by a DNSSEC class the week after in California, so I can't promise how quickly I'll be able to respond, but please do e-mail me if you have questions...

Look around the ISC.org website if you are interested in more information on DNS, DNSSEC, or the classes that we teach...

Knobee

[Knobee]

On a side-note, I'd like to make people aware of the upcoming release of BIND 9.7 -- it is currently at "rc2" and should be a full release shortly.

The primary reason for BIND 9.7 is the ease of configuration of DNSSEC (we are calling it the "DNSSEC for Humans" release).

There are a number of things that make 9.7 better on the authoritative server (automatic re-signing of zones, simpler key management, etc).

There are also a couple of things that allow you to configure validation on recursive servers very easily.

Adding this:

	dnssec-enable yes;
	dnssec-lookaside auto;

to your options section on a recursive server running BIND 9.7 will "do the right thing" with the trust anchors for dlv.isc.org and therefore allow your system to do validation based on the trust anchors available in the ISC DLV registry - aim your browser at dlv.isc.org for more information.

Knobee

[mayuka]

My named.conf looks like this:

# cat named.conf

// logging
logging {
        channel LAMER_log {
                file "log/named-lamer.log" versions 3 size 10m;
                severity info;
                print-severity yes;
                print-time yes;
        };

        channel SEC_log {
                file "log/named-sec.log" versions 3 size 10m;
                severity info;
                print-severity yes;
                print-time yes;
        };

        // channel STAT_log {
        //      file "log/named-stat.log" versions 3 size 10m;
        //      severity info;
        //      print-severity yes;
        //      print-time yes;
        // };

        // category cname { null; };
        category lame-servers { LAMER_log; };
        category security { SEC_log; };
        // category statistics { STAT_log; };
};



// define local addresses
acl "local-net" {
        10.1.1.0/24;
};

// define bogons (bogus addresses)
acl "bogons" {
        0.0.0.0/8;
        169.254.0.0/16;
        192.168.0.0/16;
};

// only allow local command channel on port 953
controls {
        inet 127.0.0.1 port 953 allow {
                127.0.0.1;
        };
};


include "etc/trusted-keys";

options {
        cleaning-interval 1440;
        dnssec-enable yes;
        dnssec-validation yes;
        //dnssec-lookaside auto; as of BIND>=9.7
        dnssec-lookaside . trust-anchor dlv.isc.org.;
        zone-statistics yes;

        dialup yes;

        listen-on port 53 {
                10.9.2.1;
        };
        listen-on-v6 port 53 {
        };

        // don't allow any host by default
        allow-transfer {
                none;
        };

        // allow only dns queries inside the local network
        allow-query {
                local-net;
        };

        blackhole {
                bogons;
        };                                

        // forwarders
        forward first;

        forwarders {
                xxx.xxx.xxx.xxx;
                xxx.xxx.xxx.xxx;
        };

        auth-nxdomain no;    # conform to RFC1035
};



// prime the server with knowledge of the root servers
zone "." {
        type hint;
        file "etc/root.hint";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "localhost" {
        type master;
        file "etc/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "etc/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "etc/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "etc/db.255";
};

zone "10.in-addr.arpa" {
        type master;
        file "etc/db.10";
};



zone "localnet" {
        type master;
        file "etc/localnet/db.localnet.signed";
};

zone "1.1.10.in-addr.arpa" {
        type master;
        file "etc/localnet/db.1.1.10";
};

[mayuka]

Oh btw... enabling the lookaside feature as you did produces dozens of error messages like these:

Jan 30 16:54:52 router named[6319]: validating @0x29743000: com.dlv.isc.org DS: must be secure failure
Jan 30 16:54:52 router named[6319]: validating @0x29743000: com.dlv.isc.org DS: must be secure failure

[Knobee]

Do you have a clean path to the Internet on port 53? If so, get rid of the forwarding statements.

Turn on DNSSEC debugging:

        channel dnssec_log {
                file "logs/dnssec.log" versions 2 size 2m;
                print-time yes;
                print-category yes;
                print-severity yes;
                severity debug 3;
        };

        category dnssec { dnssec_log; };

And see what logs you get. Also, make sure that your trusted-keys file is valid... running named-checkconf should give you a good indication.

[mayuka]

Okay.... Here's the output when I'm trying to browse de.wikipedia.org... I'm pretty sure that I have misconfigured something. But what?

30-Jan-2010 17:19:52.175 dnssec: debug 3: validating @0x2ab8b800: de.wikipedia.org A: starting
30-Jan-2010 17:19:52.175 dnssec: debug 3: validating @0x2ab8b800: de.wikipedia.org A: looking for DLV
30-Jan-2010 17:19:52.176 dnssec: debug 3: validating @0x2ab8b800: de.wikipedia.org A: plain DNSSEC returns unsecure (.): looking for DLV
30-Jan-2010 17:19:52.176 dnssec: debug 3: validating @0x2ab8b800: de.wikipedia.org A: looking for DLV de.wikipedia.org.dlv.isc.org
30-Jan-2010 17:19:52.176 dnssec: debug 3: validating @0x2ab8b800: de.wikipedia.org A: DLV lookup: wait
30-Jan-2010 17:19:52.195 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: starting
30-Jan-2010 17:19:52.195 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: attempting negative response validation
30-Jan-2010 17:19:52.195 dnssec: debug 3:   validating @0x21a24800: dlv.isc.org SOA: starting
30-Jan-2010 17:19:52.195 dnssec: debug 3:   validating @0x21a24800: dlv.isc.org SOA: attempting insecurity proof
30-Jan-2010 17:19:52.195 dnssec: debug 3:   validating @0x21a24800: dlv.isc.org SOA: insecurity proof failed
30-Jan-2010 17:19:52.195 dnssec: debug 3:   validator @0x21a24800: dns_validator_destroy
30-Jan-2010 17:19:52.195 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: in authvalidated
30-Jan-2010 17:19:52.196 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: authvalidated: got not insecure
30-Jan-2010 17:19:52.196 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: resuming nsecvalidate
30-Jan-2010 17:19:52.196 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: nonexistence proof(s) not found
30-Jan-2010 17:19:52.196 dnssec: debug 3: validating @0x21a24000: de.wikipedia.org.dlv.isc.org DLV: checking existence of DS at 'org.dlv.isc.org'
30-Jan-2010 17:19:52.213 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: starting
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: attempting negative response validation
30-Jan-2010 17:19:52.214 dnssec: debug 3:   validating @0x2f446000: dlv.isc.org SOA: starting
30-Jan-2010 17:19:52.214 dnssec: debug 3:   validating @0x2f446000: dlv.isc.org SOA: attempting insecurity proof
30-Jan-2010 17:19:52.214 dnssec: debug 3:   validating @0x2f446000: dlv.isc.org SOA: insecurity proof failed
30-Jan-2010 17:19:52.214 dnssec: debug 3:   validator @0x2f446000: dns_validator_destroy
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: in authvalidated
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: authvalidated: got not insecure
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: resuming nsecvalidate
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: nonexistence proof(s) not found
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: not beneath secure root
30-Jan-2010 17:19:52.214 dnssec: debug 3: validating @0x2f446800: org.dlv.isc.org DS: plain DNSSEC returns unsecure (.): looking for DLV
30-Jan-2010 17:19:52.214 dnssec: warning: validating @0x2f446800: org.dlv.isc.org DS: must be secure failure
30-Jan-2010 17:19:52.214 dnssec: debug 3: validator @0x2f446800: dns_validator_destroy
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: starting
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: attempting negative response validation
30-Jan-2010 17:19:52.224 dnssec: debug 3:   validating @0x29396000: dlv.isc.org SOA: starting
30-Jan-2010 17:19:52.224 dnssec: debug 3:   validating @0x29396000: dlv.isc.org SOA: attempting insecurity proof
30-Jan-2010 17:19:52.224 dnssec: debug 3:   validating @0x29396000: dlv.isc.org SOA: insecurity proof failed
30-Jan-2010 17:19:52.224 dnssec: debug 3:   validator @0x29396000: dns_validator_destroy
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: in authvalidated
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: authvalidated: got not insecure
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: resuming nsecvalidate
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: nonexistence proof(s) not found
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: not beneath secure root
30-Jan-2010 17:19:52.224 dnssec: debug 3: validating @0x21a24800: org.dlv.isc.org DS: plain DNSSEC returns unsecure (.): looking for DLV
30-Jan-2010 17:19:52.224 dnssec: warning: validating @0x21a24800: org.dlv.isc.org DS: must be secure failure
30-Jan-2010 17:19:52.224 dnssec: debug 3: validator @0x21a24800: dns_validator_destroy

[J65nko]

Maybe you could post the named/bind version

# named -v

[mayuka]

BIND 9.4.2-P2, that one that comes with the latest OpenBSD.

[Knobee]

Originally Posted by mayuka

BIND 9.4.2-P2, that one that comes with the latest OpenBSD.

Can you build a newer version of BIND, run it from its build directory (ie, "make" but not "make install") and see if you have issues?

you should be able to run it as: "$BUILDDIR/bin/named/named -g" (after killing off the running named process)

Knobee

[jggimi]

Knobee, OpenBSD's BIND is 9.4.2-P2 plus patches, which provide the following additions, from /usr/src/usr.sbin/bind/README.OpenBSD:

$OpenBSD: README.OpenBSD,v 1.10 2009/08/16 13:17:24 stsp Exp $

additional features

- write pid-file before chroot
- privilege separation for binding to privileged ports from within chroot
- add 64K entry shuffle (somewhat like Fisher-Yates) implementation to libisc
- use shuffle instead of LFSR for ID generation
- strlcpy/strlcat/snprintf fixes
- parse "nameserver [host]:port" syntax in /etc/resolv.conf

default parameter changes

- chroot to /var/named by default
- setuid to user named by default
- listen to IPv6 interfaces by default

[Knobee]

Originally Posted by jggimi

Knobee, OpenBSD's BIND is 9.4.2-P2 plus patches, which provide the following additions, from /usr/src/usr.sbin/bind/README.OpenBSD: ....

Right. Not being ISC code, I'm not going to try to debug it.

If it works with current ISC code, I can point the finger at "old code" and "not our code" instead of trying to figure out if there is a problem on-the-wire (forwarding, upstream mangling DNSSEC responses, etc etc)

-K