1

I have local (private) root domain domainX.example and subdomains : subdomainY.domainX.example and subdomainZ.domainX.example.

How would I create chain of trust without using root-servers.net?

Improve this question
3
  • Using BIND9 on Linux distro eg Centos 7
    – Mundile
    Oct 30, 2019 at 16:56
  • You are mixing authoritative and recursive. The authoritative nameservers do not need any chain of trust. THey have locally all the keys needed to sign records in the zones they are authoritative for. It is the recursive nameservers that need to have, basically, the root key locally as fully trusted and then they will descend from it and checks things at each traversed zone. This does not depend very much on root-servers.net at all.
    – Patrick Mevzek
    Oct 31, 2019 at 6:39
  • Thanks Patrick. However, what will be dnssec-validation ( yes | auto | no) at the local root DNS server a.domainX.loc. Should I comment out configuration statements that specify bind-keys such as bindkeys-file "/etc/named.root.key"; include "/etc/named.root.key";
    – Mundile
    Oct 31, 2019 at 7:35

2 Answers 2

Reset to default
1

Look at https://ftp.isc.org/isc/bind9/cur/9.15/doc/arm/Bv9ARM.ch05.html#dnssec-keys

A trust anchor is defined when the public key for a non-authoritative zone is known, but cannot be securely obtained through DNS, either because it is the DNS root zone or because its parent zone is unsigned. Once a key has been configured as a trust anchor, it is treated as if it had been validated and proven secure.

The resolver attempts DNSSEC validation on all DNS data in subdomains of configured trust anchors. (Validation below specified names can be temporarily disabled by using rndc nta, or permanently disabled with the validate-except option).

And the example at https://ftp.isc.org/isc/bind9/cur/9.15/doc/arm/Bv9ARM.ch04.html#dnssec_config

dnssec-keys {
        /* Root Key */
        "." initial-key 257 3 3 "BNY4wrWM1nCfJ+CXd0rVXyYmobt7sEEfK3clRbGaTwS
                                 JxrGkxJWoZu6I7PzJu/E9gx4UC1zGAHlXKdE4zYIpRh
                                 aBKnvcC2U9mZhkdUpd1Vso/HAdjNe8LmMlnzY3zy2Xy
                                 4klWOADTPzSv9eamj8V18PHGjBLaVtYvk/ln5ZApjYg
                                 hf+6fElrmLkdaz MQ2OCnACR817DF4BBa7UR/beDHyp
                                 5iWTXWSi6XmoJLbG9Scqc7l70KDqlvXR3M/lUUVRbke
                                 g1IPJSidmK3ZyCllh4XSKbje/45SKucHgnwU5jefMtq
                                 66gKodQj+MiA21AfUVe7u99WzTLzY3qlxDhxYQQ20FQ
                                 97S+LKUTpQcq27R7AT3/V5hRQxScINqwcz4jYqZD2fQ
                                 dgxbcDTClU0CRBdiieyLMNzXG3";
        /* Key for our organization's forward zone */
        example.com. static-key 257 3 5 "AwEAAaxPMcR2x0HbQV4WeZB6oEDX+r0QM6
                              5KbhTjrW1ZaARmPhEZZe3Y9ifgEuq7vZ/z
                              GZUdEGNWy+JZzus0lUptwgjGwhUS1558Hb
                              4JKUbbOTcM8pwXlj0EiX3oDFVmjHO444gL
                              kBOUKUf/mC7HvfwYH/Be22GnClrinKJp1O
                              g4ywzO9WglMk7jbfW33gUKvirTHr25GL7S
                              TQUzBb5Usxt8lgnyTUHs1t3JwCY5hKZ6Cq
                              FxmAVZP20igTixin/1LcrgX/KMEGd/biuv
                              F4qJCyduieHukuY3H4XMAcR+xia2nIUPvm
                              /oyWR8BW/hWdzOvnSCThlHf3xiYleDbt/o
                              1OTQ09A0=";

...

So define your key for your zone in one such dnssec-keys statement, and set dnssec-validation to yes (not auto).

See also this explanation later:

The keys specified in dnssec-keys copies of DNSKEY RRs for zones that are used to form the first link in the cryptographic chain of trust. Keys configured with the keyword static-key are loaded directly into the table of trust anchors, and can only be changed by altering the configuration. Keys configured with initial-key are used to initialize RFC 5011 trust anchor maintenance, and will be kept up to date automatically after the first time named runs.

Improve this answer
6
  • Ok noted Patrick. I will try to use dnssec-keys instead of managed/trusted keys. However, does this apply to the local root nameserver or only recursive nameservers and subdomains nameservers. I am stuck on how to configure dnssec-keys at the local root nameserver
    – Mundile
    Nov 9, 2019 at 21:27
  • You said "I have local (private) root domain domainX.example" so use the above dnssec-keys statement to define a key for this zone that you have. The root zone is ., so it is not yours. These keys need to be defined on the recursive nameserver that needs to do the resolution and the DNSSEC validation. Of course the authoritative nameservers need to use the proper key (their private parts) to generate the appropriate signatures to be validated.
    – Patrick Mevzek
    Nov 10, 2019 at 1:33
  • Let me guess, Bind 9.15 isn’t the best version to use if hosting a private DNSSEC zone, right?
    – John Greene
    Mar 29, 2020 at 8:45
  • 1
    @JohnGreene from bind release notes it seems indeed there was a lot of work regarding DNSSEC management that went into 9.16 so it might be a better target.
    – Patrick Mevzek
    Mar 29, 2020 at 17:39
  • Too bad that the dnssec-keys clause is arguably the shortest-lived keyword in the Bind9 configuration set: v9.15.2 to v9.15.6. Is there another clause that can save the day?
    – John Greene
    Dec 20, 2021 at 21:00
0

There is a bash script to generate the ISC Bind9 named.conf file for a working standalone closed-network (13) Root Server(s) that fully-supports DNSSEC.

Works with ISC Bind9 v9.16.24-RH and v9.17.21 on Debian 11, Redhat 8, or Fedora 35.

Once run, it generates all settings under its newly-created build subdirectory so you can preview it before copying into the Bind configuration and zone directories.

DISCLAIMER: Of course, when I say closed-network, that means other users will not (and should not) be able to use this. Most useful for closed-network experimentation of DNS and DNSSEC. This script will do nothing and can do nothing to help reuse or extend DNS to include your private TLD (much less the Internet) or substituted domain toward any existing ICANN-related or NIC-related DNS infrastructure much less do anything with existing DNS infrastructure of the Internet as we know of today.

Execute:

$ gh repo clone egberts/easy-admin
$ # or
$ git clone https://github.com/egberts/easy-admin
$ cd easy-admin/500-dns
$ ./599-dns-root-server-standalone.sh 
Create a standalone root server for a closed network whitelab usage

Only one 'named' found: /usr/local/sbin/named /usr/sbin/named
Using 'named' binary in: /usr/local/sbin/named
systemd named.service unit uses this config file: /etc/named.conf
Creating build/var/named/dynamic directory ...
Creating build/var/named/data directory ...
List of supported DNSSEC algorithms:
  1: ecdsaP256Sha256
  2: ecdsaP384Sha384
  3: ed25519
  4: rsaSha256
  5: rsaSha512
Enter in desired algorithm index: 1
Creating Zone-Signing-Key (ZSK) files in easy-admin/500-dns PWD...
Generating key pair.
Creating Key-Signing-Key (KSK) files ...
Generating key pair.

Creating SOA, NS, annd A glue record in build/var/named/db.root.standalone ...
build/var/named/db.root.standalone created.

dnssec-signzone: warning: build/var/named/db.root.standalone:8: using RFC1035 TTL semantics
Fetching ./ECDSAP384SHA384/53186 (ZSK) from key repository.
Fetching ./ECDSAP384SHA384/46088 (KSK) from key repository.
Verifying the zone using the following algorithms:
- ECDSAP384SHA384
Zone fully signed:
Algorithm: ECDSAP384SHA384: KSKs: 2 active, 0 stand-by, 0 revoked
                            ZSKs: 2 active, 0 stand-by, 0 revoked
build/var/named/db.root.standalone.signed
Signatures generated:                       20
Signatures retained:                         0
Signatures dropped:                          0
Signatures successfully verified:           20
Signatures unsuccessfully verified:          0
Signing time in seconds:                 0.155
Signatures per second:                 129.028
Runtime in seconds:                      0.292
build/var/named/keys/dsset-root created.
/var/named/db.root.standalone.signed created.
Creating /etc/named/standalone-view-recursive-zone-root-named.conf ...
Creating /etc/named/standalone-options-named.conf ...
Creating /etc/named/standalone-key-named.conf ...
Creating /etc/named/standalone-trust-anchors-named.conf ...
Creating /etc/named/standalone-named.conf ...
$

Using Fedora 35, it creates /etc/named/standalone-named.conf

# File: /etc/named/standalone-named.conf
# Date: 20213512/25/21 0935"
# Title: named configuration file for standalone CLOSED-NET root server

# include "/etc/named/logging-named.conf";
include "/etc/named/standalone-key-named.conf";
include "/etc/named/standalone-options-named.conf";
include "/etc/named/standalone-trust-anchors-named.conf";
include "/etc/named/standalone-view-recursive-zone-root-named.conf";

And /etc/named/standalone-options-named.conf file:

# File: /etc/named/standalone-options-named.conf
# Date: 20213512/25/21 0935"
# Title: options clause of named configuration file

options {
    # Make sure that 'directory' is near the beginning of named.conf
    # before any relative directory settings.
    # Because it actually does LIVE change-directory while reading config
    # ISC has said WONTFIX on the shortcoming of this 'directory' statement.
    directory "/var/named";
    key-directory "/var/named/keys";

    dump-file "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named.memstats";

    session-keyfile "/run/named-session.key";
    pid-file none;

    zone-statistics yes;

    recursion yes;
    // Authoritative root server notifies nobody.
    notify no;

    allow-recursion { any; };


    // Tony Finch recommends 'no' at global, but 'auto' within 'view's.
    # dnssec-validation auto;
    dnssec-validation no;
    # dnssec-enable yes;  # obsoleted in v9.15.0

    auth-nxdomain no;

    listen-on { 127.0.0.1; 10.10.0.1; };

    // The magical word:
    root-delegation-only;

    // Keep that one to ourself
    //trust-anchor-telemetry yes;
};

Creates /etc/named/standalone-trust-anchors-named.conf

# File: /etc/named/standalone-trust-anchors-named.conf
# Date: 20213512/25/21 0935"
# Title: trust-anchors clause of named configuration file
# Description:
#   Formerly 'managed-keys' clause, which got obsoleted in v9.15.0

trust-anchors {
. initial-key 256 3 14 "PQWIHBpNGYQC2JN+IhgHQ4mRNWJ5jPX41F2vm+feGvduZwQbEMmNx/7G";
. initial-key 257 3 14 "NWQBQo0pFDp/bk+WqkHMTwd2valrF5qwUvJUKRY4hRGkOL3HP32ey6F/";
};

creates the View and Zone:

# File: /etc/named/standalone-view-recursive-zone-root-named.conf
# Date: 20213512/25/21 0935"
# Title: View 'recursive' and 'root' zone

view "recursive" IN {
    match-clients { any; };
    allow-query { any; };
    recursion yes;

    allow-recursion { any; };

    // Tony Finch recommends 'no' at global, but 'auto' within 'view's.
    dnssec-validation auto;

    # can only choose one: 'update-policy' or 'allow-update'
    # update-policy local;
    allow-update {
        !{ !{ localhost; 10.10.0.1; }; any; };
        // only localhost got past this point here
        // no one can update except localhost RNDC
        key "rndc-key"; // only RNDC on localhost or 10.10.0.1

        };
    zone "." {
        type master;
        file "/var/named/db.root.standalone";
        check-names fail;
    };
};

and lastly, creates /etc/named/standalone-key-named.conf:

# File: /etc/named/standalone-key-named.conf
# Date: 20213512/25/21 0935"
# Title: key clause for 'rndc' of named configuration file

include "/etc/rndc.key";

References:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .