|
|
Apricot 2003 Saturday Notes |
We start the Saturday by making delegations from 115.10.in-addr.arpa to 115.10.in-addr.arpa.
You create a delegation by entering the nameservers which are authoritative for the 1.115.10.in-addr.arpa. domain in the 115.10.in-addr.arpa zone.
Most of there rest of the day was based on demonstrations.
The DNSSEC demo was run in a preconfigured setup. You can find the directory with the setup here, the setup is described in the README in that directory. Note that you have to run a recent bind9.3.0 snapshot for these tests.
One can obtain DNSSEC records using dig with the +multiline +dnssec as demonstrated below with a query for the SOA RR of the top level domain TLD.
dig @10.0.53.202 tld SOA +dnssec +multiline
; <<>> DiG 9.3.0s20021217 <<>> @10.0.53.202 tld SOA +dnssec +multiline
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22431
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;tld. IN SOA
;; ANSWER SECTION:
tld. 100 IN SOA ns.registry.tld. olaf.ripe.net. (
2002050501 ; serial
100 ; refresh (1 minute 40 seconds)
200 ; retry (3 minutes 20 seconds)
604800 ; expire (1 week)
100 ; minimum (1 minute 40 seconds)
)
tld. 100 IN SIG SOA 1 1 100 20030324233317 (
20030222233317 37958 tld.
RxrfeE55oRyh1qcbZ0eWm1cOp7MJ9PkO+CfqYGmfT394
WyKH1bK6eL8QzihPUxBCYo0ziOFx4h1xbcBbPoqn9E/9
go2g1hu8yHCFVQPAYT9f8VQjnFf3K+2C+YMgSIh66hLw
9y4wYZppN+CqI4GT3gfxh+LJ5V1lM4ubXQLcIkc= )
;; AUTHORITY SECTION:
tld. 100 IN NS ns.registry.tld.
tld. 100 IN SIG NS 1 1 100 20030324233317 (
20030222233317 37958 tld.
z6ZgfDODQnAQKJx8Nn7aosIAgY0tuL077lGaaE9eNmqZ
x7PP6t6T69KkuC37ASRcKhZ4ZHdXjrgbFB8bKSVBp45n
vaMTUD6YNkOD36DZ6wHdpEfuNh9R9xX5cwsUS4NbEJIB
vN2iCLIHLPpuhexn6BPjqWwpOeXyd7LzpQuEkZ8= )
;; ADDITIONAL SECTION:
ns.registry.tld. 100 IN A 10.0.53.202
tld. 100 IN KEY 256 3 1 (
AQPQOhIjhTLvcDjo9xQJN0Z0Tj33UmvxJlb85CbgB+7P
lqDnh0hZwoZoOigR2fYYbmdIr/Oj+HzKy8sM9Jwsghv6
FWYEIMeQR2IyeMiZ6sho93ID7Rm8cG07yVHARTWzXdLx
2zi2Hj6yDPn1asL4TTvXamocjM6IJqaWgEMNSpRG7Q==
) ; key id = 37958
tld. 100 IN SIG KEY 1 1 100 20030324233317 (
20030222233317 37958 tld.
g5Ly7dTuAkn0N9YPLqTYmNq121buspLSOWdxXaKJgLCj
MMABBL6nc7AfGyIymOnh1EMybgxmFA67gNph3jRgcBBI
Nw2OnAiZdDVn12BKGxLod7li0HK1NC0Xodfj3hvguqoF
oqZqL0diGKyXj5Zupzor3kXuB/FOY0T7Jb5hSR4= )
ns.registry.tld. 100 IN SIG A 1 3 100 20030324233317 (
20030222233317 37958 tld.
gyZ6sLpl+o2E/ejg4lfcLnBIPQBDOKl4aIH/7xP7AzCL
Qzj/1qZz21sewZE4hTeztTftxx2Z35t1M/ftSgIM0GJY
0eWU9lLucRvuMPE1/M0eZQCllTtp6oA7bb49RvTP0CNN
jsU8DLFleUrfF5NFBtsDP6aVJC/kMVcm4v2wvJ0= )
;; Query time: 482 msec
;; SERVER: 10.0.53.202#53(10.0.53.202)
;; WHEN: Sun Feb 23 08:41:03 2003
;; MSG SIZE rcvd: 921
We also demonstrated that if the log messages of the dnssec category are channeled with debug level 3 you will be able to follow the verification chain in the verifier's log. Here follows the log for a query for sub.tld SOA. If you look carefully you see all kinds of positive response validations that recursively follow the chain of trust.
23-Feb-2003 08:47:17.933 dnssec: debug 3: validating . NS: starting
23-Feb-2003 08:47:17.933 dnssec: debug 3: validating . NS: attempting positive response validation
23-Feb-2003 08:47:18.084 dnssec: debug 3: validating . KEY: starting
23-Feb-2003 08:47:18.084 dnssec: debug 3: validating . KEY: attempting positive response validation
23-Feb-2003 08:47:18.086 dnssec: debug 3: validating . KEY: verify rdataset: success
23-Feb-2003 08:47:18.087 dnssec: debug 3: validating . KEY: signed by trusted key; marking as secure
23-Feb-2003 08:47:18.187 dnssec: debug 3: validator @0x46fd90: dns_validator_destroy
23-Feb-2003 08:47:18.189 dnssec: debug 3: validating . NS: in fetch_callback_validator
23-Feb-2003 08:47:18.189 dnssec: debug 3: validating . NS: keyset with trust 7
23-Feb-2003 08:47:18.189 dnssec: debug 3: validating . NS: resuming validate
23-Feb-2003 08:47:18.191 dnssec: debug 3: validating . NS: verify rdataset: success
23-Feb-2003 08:47:18.191 dnssec: debug 3: validating . NS: marking as secure
23-Feb-2003 08:47:18.197 dnssec: debug 3: validator @0x46e020: dns_validator_destroy
23-Feb-2003 08:47:18.201 dnssec: debug 3: validating sub.tld SOA: starting
23-Feb-2003 08:47:18.202 dnssec: debug 3: validating sub.tld SOA: attempting positive response validat
ion
23-Feb-2003 08:47:18.234 dnssec: debug 3: validating sub.tld KEY: starting
23-Feb-2003 08:47:18.234 dnssec: debug 3: validating sub.tld KEY: attempting positive response validat
ion
23-Feb-2003 08:47:18.234 dnssec: debug 3: validating sub.tld DS: starting
23-Feb-2003 08:47:18.234 dnssec: debug 3: validating sub.tld DS: attempting positive response validati
on
23-Feb-2003 08:47:18.244 dnssec: debug 3: validating tld KEY: starting
23-Feb-2003 08:47:18.244 dnssec: debug 3: validating tld KEY: attempting positive response validation
23-Feb-2003 08:47:18.244 dnssec: debug 3: validating tld DS: starting
23-Feb-2003 08:47:18.245 dnssec: debug 3: validating tld DS: attempting positive response validation
23-Feb-2003 08:47:18.245 dnssec: debug 3: validating tld DS: keyset with trust 7
23-Feb-2003 08:47:18.248 dnssec: debug 3: validating tld DS: verify rdataset: success
We demonstrated that if data gets corrupted you will get a SERVFAIL response. If you want to determine if the SERVFAIL is due to a verification error or a different problem you can use the +cd (checking disabled). The verifying caching server will answer you without checking. We have corrupted the A record for b1 in the 'sub.tld'. This is what you get when querying the verifier.
dig @10.0.53.204 b1.sub.tld
; <<>> DiG 9.3.0s20021217 <<>> @10.0.53.204 b1.sub.tld
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17280
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;b1.sub.tld. IN A
;; Query time: 712 msec
;; SERVER: 10.0.53.204#53(10.0.53.204)
;; WHEN: Sun Feb 23 09:03:08 2003
;; MSG SIZE rcvd: 28
You can test if this is a DNSSEC record that fails to verify by doing the same query without checking
dig @10.0.53.204 b1.sub.tld +cd
; <<>> DiG 9.3.0s20021217 <<>> @10.0.53.204 b1.sub.tld +cd
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65282
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;b1.sub.tld. IN A
;; ANSWER SECTION:
b1.sub.tld. 100 IN A 10.0.2.2
;; AUTHORITY SECTION:
sub.tld. 100 IN NS ns.sub.tld.
;; Query time: 106 msec
;; SERVER: 10.0.53.204#53(10.0.53.204)
;; WHEN: Sun Feb 23 09:06:42 2003
;; MSG SIZE rcvd: 61
You see that you get an answer.. the wrong one.
Below is what in the log file when the verifier finds corrupted data.
23-Feb-2003 09:03:07.971 dnssec: debug 3: validating b1.sub.tld A: in fetch_callback_validator
23-Feb-2003 09:03:07.971 dnssec: debug 3: validating b1.sub.tld A: keyset with trust 7
23-Feb-2003 09:03:07.972 dnssec: debug 3: validating b1.sub.tld A: resuming validate
23-Feb-2003 09:03:07.974 dnssec: debug 3: validating b1.sub.tld A: verify rdataset: SIG failed to verify
23-Feb-2003 09:03:07.975 dnssec: debug 3: validating b1.sub.tld A: failed to verify rdataset
23-Feb-2003 09:03:07.975 dnssec: debug 3: validating b1.sub.tld A: verify failure: SIG failed to verify
23-Feb-2003 09:03:07.975 dnssec: debug 3: validating b1.sub.tld A: keyset with trust 7
23-Feb-2003 09:03:08.190 dnssec: debug 3: validating b1.sub.tld A: verify rdataset: SIG failed to verify
23-Feb-2003 09:03:08.191 dnssec: debug 3: validating b1.sub.tld A: failed to verify rdataset
23-Feb-2003 09:03:08.191 dnssec: debug 3: validating b1.sub.tld A: verify failure: SIG failed to verify
Ed demonstrated some host security features.
The issue we are trying to tackle is to limit the amount of harm that can be done if a buffer overflow bug is discovered, that potentionally can lead to a compromise of the machine. It is a good practice to run services as a 'common' user and in a so called chrooted environment.
Check the documentation (section 7) for details on how to build a chroot environment.
Use one zone file without $ORIGIN statement. Use zone "" in named.conf as surrogate. Handy in webhosting environments.