[dns-operations] help with a resolution

[Mukund Sivaraman]

On Wed, Jan 08, 2020 at 07:05:04PM +0800, William C wrote:
> Thanks all for explains.
> I am new to DNSSEC, so I have questions:
> 
> 1. how to check if a zone has a valid DNSSEC key?

The hash in the DS record in the parent zone should correspond to the
DNSKEY at the apex of your (child) zone.

So, for example, if you have generated your DNSKEY using BIND's
dnssec-keygen utility, you can use the dnssec-dsfromkey to generate DS
records for such keys.

The following is an example that prints a DNSKEY's corresponding DS
records (I'm using Loop's utilities which are similar with some small
differences):

[muks at jurassic ~/tmp-dnssec]$ dnssec-keygen -f KSK example.org
Generating key pair..................+++++ .............+++++ 
Kexample.org.+005+04222
[muks at jurassic ~/tmp-dnssec]$ ls
Kexample.org.+005+04222.key  Kexample.org.+005+04222.private
[muks at jurassic ~/tmp-dnssec]$ dnssec-dsfromkey Kexample.org.+005+04222
example.org. IN DS 4222 5 1 7B83C10E0220CA65139DFFE14F3F24B8D8ACAEA2
example.org. IN DS 4222 5 2 06B8EB5B92B64B87C75E7B0F589876067E4E31B6F34750DA853FF5D79101D831
[muks at jurassic ~/tmp-dnssec]$ 

The DS records printed should be added to the parent zone (e.g., if your
zone's parent is a top-level zone such as com., you would typically add
these DS records using the registrar's interface).

Also note that hash algorithm 1 (in the "5 1" RR printed above) stands
for SHA-1 hash which is weakening in security day by day, so you would
probably want to add only the "5 2" RR from above, where 2 stands for
SHA-256. A complete list of these is here:
https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml

> 2. how to validate if the zone has been signed with correct key?

If you have a signed zone in master file format (such as generated by
BIND's dnssec-signzone utility), you may verify the signatures using
dnssec-verify. For example, let's create an example zone and sign it
using the KSK key above:

[muks at jurassic ~/tmp-dnssec]$ echo "example.org. 3600 IN SOA . . 1 3600 3600 3600 3600" > example.org.zone
[muks at jurassic ~/tmp-dnssec]$ echo "example.org. NS ns1.example.com." >> example.org.zone
[muks at jurassic ~/tmp-dnssec]$ dnssec-signzone -z -S -o example.org example.org.zone 
dnssec-signzone: warning: example.org.zone:2: using RFC1035 TTL semantics
Fetching KSK/ZSK 4222/RSASHA1 from key repository.
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 0 active, 0 stand-by, 0 revoked
example.org.zone.signed
[muks at jurassic ~/tmp-dnssec]$ 

Let's verify the signed zone against the KSK:

[muks at jurassic ~/tmp-dnssec]$ dnssec-verify -x -o example.org example.org.zone.signed Kexample.org.+005+49357
Loading zone 'example.org' from file 'example.org.zone.signed'
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
                    ZSKs: 0 active, 0 present, 0 revoked
[muks at jurassic ~/tmp-dnssec]$ 

Please read the manpages of dnssec-keygen, dnssec-signzone, and
dnssec-verify on why the arguments above were used. Typically you would
use a second DNSKEY called a ZSK in your zones, and you wouldn't have to
use the arguments above.

Finally, delv and dig +trace are useful to check what your network sees
of the public DNS data.

       	      	  Mukund