Score:0

How Do I Fix My DNSSEC? I never got DNSSEC working and have probably worsened the problems

cn flag

My attempt to DNSSEC has not been successful. To help understand DNSSEC I have read many online articles, man pages for rndc, dnssec-*, viewed dnsviz.net and dnssec-analyzer.verisignlabs.com/. Most of the information explains DNSSEC in great detail but I need to know WHAT to do and how to FIX the problems.

For example, dnsviz.net/allenintech.com indicates, "no valid DNSKEY records are provided by the authoritative name server to match the DS record published by the TLD name server".

HOW is a DNSKEY record provided by the NS to match the DS record published by the TLD? Is there a configuration I am missing? Are there rndc or dnssec-* commands to accomplish this?

System Ubuntu 20.04 BIND 9.16.1-Ubuntu (Stable Release) Apache/2.4.48 (Ubuntu)

named.conf Zone Files To trouble shoot the problems all except a few zones were retained. I thought reducing the zones would better help diagnose and fix the problems.

Notice Two views: inside and outside IP Local Server: 10.0.0.1 (inside view) Static IP Server: 99.93.25.17 (outside view) Secondary NS: 51.38.99.90

options{
        directory "/etc/bind/zoneFiles/";

        listen-on port 53 { 127.0.0.1; 10.0.0.1; 99.93.25.17; };
        allow-transfer { none; };
        dnssec-policy default;
        bindkeys-file "/etc/bind/zoneFiles/bind.keys";
};

acl "mylo" {
        127.0.0.1;
};
acl "mylan" {
        10.0.0.0/24;
};
acl "mywireless" {
        192.168.1.0/24;
};
view inside {
        match-clients {"mylan"; "mylo"; "mywireless";};
        recursion yes;

        zone "." {
                type hint;
                file "/etc/bind/zoneFiles/root.hints";
        };
        zone "allenintech.com" {                                                         
                type master;  
                file        "/etc/bind/zoneFiles/insideView/allenintech.com.inside/db.allenintech.com.inside";
                key-directory "/etc/bind/zoneFiles/insideView/allenintech.com.inside";   
                allow-transfer {51.38.99.90;};                                           
        };                                                                               
};                                                                                       
view outside {      

        recursion no;
        match-clients {any;};
        allow-query {any;};
        #---------------------------------------------
        zone "."  {
                type hint;
                file "/etc/bind/zoneFiles/root.hints";
        };
   
        zone "allenintech.com" {
                type master;
                file          "/etc/bind/zoneFiles/outsideView/allenintech.com.outside/db.allenintech.com.outside";
                key-directory "/etc/bind/zoneFiles/outsideView/allenintech.com.outside";
                allow-transfer {51.38.99.90;};
        };
};

Inside View

$ORIGIN **allenintech.com.**
$TTL      86400
@       IN      SOA ns2.allenintech.com. besus.allenintech.com. (
                        2022030750  ; Serial
                        28800       ; Refresh
                        120         ; Retry
                        1209600     ; Expire
                        86400       ; Minumum
)               
        
; Name servers
@                       IN      NS      ns2.allenintech.com.
ns2                     IN      A       10.0.0.1
                
; Web Services  
www                     IN      A       10.0.0.1
@                       IN      A       10.0.0.1

Outside View

$ORIGIN **allenintech.com.**
$TTL      86400
@       IN      SOA ns1.allenintech.com. besus.allenintech.com. (
                        2022030725  ; Serial
                        28800       ; Refresh
                        120         ; Retry
                        1209600     ; Expire
                        86400       ; Minumum
)               
        
; Name Servers 
@               IN      NS ns1.allenintech.com. ; primary
ns1             IN      A 99.93.25.17           ; primary
                
                        NS fns2.42.pl.          ; secondary
        
        
; Web Services  
www             IN      A 99.93.25.17
@               IN      A 99.93.25.17

**Current Images

DNSVIZ

DNSSECANALYZER

Old images dnsviz dnssec-analyzer.verisignlab

Old Images https://dnssec-analyzer.verisignlabs.com/allenintech.com

dnsviz.net/allenintech.com

djdomi avatar
za flag
isnt Insideview an admin panel? please share the zonefile
cn flag
insideview is not an "admin panel". Yes, I will post the zonefile. However, before posting the zonefile, I need to edit the post to update the two images: https://dnssec-analyzer.versignlabs.com/allenintech.com and https://disviz.net/allenintech.com
Score:1
jp flag

There is a mismatch between the DNSSEC keys used to sign the zone (13/61524) and the DS records signed by the parent zone (com. has 13/51277). Please update your DS records at your registar.

The dnssec-signzone command should have created a file named dsset-allenintech.com containing the correct DS records:

allenintech.com.    IN DS 61524 13 1 ****************************************
allenintech.com.    IN DS 61524 13 2 ******************************************************** ********
cn flag
(A) Are these the correct steps to implement your, (i.e. Esa Jokinem's), suggestion to “Update your DS record at your registrar”? I am using the ARM for 9.16.1 at https://downloads.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch04.html#generating_dnssec_keys to implement the suggestion. Go to (B)
cn flag
(B) 1) Zone Signing Key (ZSK) - cd to key-directory - rm *.key *.private *.jnl *.state - cp fresh zone configuration file to key-directory - dnssec-keygen -a ECDSAP256SHA256 -n ZONE allenintech.com - output Similar to the following:  - Kallenintech.com.+013+12345.key and Kallenintech.com.+013+12345.private. - allenintech.com zone is updated with DNSSEC records. Go to (C)
cn flag
(C) 2) Register update DS record 3) Key Signing Key (KSK) - After the DS record has been updated by the registrar - Note: Key signing is automatic with option: “dnssec-policy default” - rndc reload - output - Two output files similar to the following will be produced: Kallenintech.com +013+12345.key and Kallenintech.com.+013+12345.private, maybe as well as *.state, as well as allenintech.com.signed, keyset and dsset. Thanks!
cn flag
What is the best way to enable DNSSEC with BIND with automatic signing? I need assistance, please. I am using the ARM for 9.16.1 at https://downloads.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch04.html#generating_dnssec_keys to implement the suggestion: “Update your DS record at your registrar” as suggested by @Esa Jokinen
cn flag
1) What is/are the command(s) to generated the DS record to be updated at the registrar? Specificity would be appreciated. @Esa Jokinen
cn flag
2) In regards to the DS record, where are the DS data located? Are the DS data located in a file and/or are there command(s) to see/view the DS data to be sent to the registrar? @Esa Jokinen
cn flag
3) In named.com, dnssec-policy is set to “default”. So according to ARM 9.16.1, automatic signing is enabled. What are the steps and commands to implement automatic signing? Is the dnssec-signzone command necessary when dnssec-policy is default? Will dsset-allenintech.com be produced without issuing sign-zone command? @Esa Jokinen
cn flag
@Anthon The `dnssec-signzone` command is an old alternative for manually signing a zone file, it serves no purpose if `dnssec-policy` (or `auto-dnssec maintain`) is in use. The latter automatically maintain the necessary signatures.
cn flag
Thanks @Hakan Lidqvist! I have discovered what you have said. I posted the solution with the understand of dnssec-policy (and auto-dnssec maintain)
Score:0
cn flag

Here is the solution: Bind9 is set up with "dns-policy default" as depicted in the option section above. This is important and very cool. Most of help and documentation do not address "dns-policy default" but addresses "dns-policy default" in terms of previous, older and even deprecated methods.

1.Comment out all zones configurations in named.conf except one, for example example.com.

zone "example.com" { type master; file "/.../example.com.outsideView/example.com.outside"; key-directory "/.../zoneFiles/outsideView/example.com.outside"; };

a) file is the location of example.com zone file. I separate inside and outside views and make clear which view the zone file represents, thus example.com.outside.

b) key-directory is the location where the DNSSEC keys will be written and where a copy of example.com is placed. It is important to keep separate the zone file, example.com, in bind9 configuration, name.conf ie. file and the zone file, example.com, copied to key-directory as given as the name.conf option. You will modify the zone file, example.com, in file as needed. It is the working copy. The copy of zone file, example.com, in key-directory will be modified or "signed" by DNSSEC "dnssec-policy default".

2.Once the bind9 options for the zone configuration file are set with file and key-directoy then, a) Restart bind with "systemctl restart bind9" or "rndc reload". "rndc reload" will reload the configuration files and zones. When the interaction of DNSSEC with bind and zone configurations was not understood I used "rndc reload". As things became clear then "systemctl restart bind9" was sufficient. b) Once bind9 has been successfully restarted cd to key-directory. There will be the zone file example.com.outside, .jnl and K.(key|state|private) file like these:

example.com.outside

example.com.outside.jnl

Kexample.com.+013+12345.key Kexample.com.+013+12345.state Kexample.com.+013+12345.private (013 - algorithm number, 12345 - key)

3)Extract the DS record from the key using the following command and save the output

a) dnssec-dsfromkey Kexample.com.outside+013+12345.key > DSkeyexample.com.outside.

b) DSkeyexample.com.outside will contain the DS record for the zone example.com in the file example.com.outside, for example, cat DSkeyexample.com.outside produces:

example.com. IN DS 12345 13 2 1234adb69784efc7528746dab15432abfd78764cd543cccd5432123abcdef123

c) Send the DS record to the ISP or input this DS record into the ISP's DNSSEC interface.

4)Signing the zone, example.com (filename example.com.outside). Remember, the zone example.com is located in two places: file and copied to key-directory. example.com located in bind configuration "file" is for changes and modifications. Zone file example.com copied to bind configuration "key-directory" is signed by DNSSEC.

a) Initially, both zone files will be the same small size i.e. identical of course, for example 8KB. When signing takes place the zone file in key-directory will double quadruple in size, for example from 8KB to 24KB. Also, using an editor, open the zone file located in key-directory. Notice the signing data. Signing the zone is when DNSSEC rewrites the zone file in key-directory. "dnssec-policy default" signs and maintains the zone.

b) Zone signing does not always take place immediately. Use "systemctl status bind9" to observed the next key update to get an indication when the zone maybe signed.

5)Making changes/correction to the zone file a) Do not change or modify the signed or unsigned zone file in key-directory. Change and modify the zone file in file and save it and remember to increment the Serial number. Then copy or save-as the changes to key-directory. Yes, the signed or unsigned zone file will be over written. b) restart bind9: systemctl restart bind9.

6)Forcing the zone to sign. When bind9 is running and there are no errors but the zone will not sign.

a) remove/delete the *.jnl file and increment the serial of the zone file located in file. Then copy/save-as to key-directory. Then systemctl restart bind9.

b) Using rndc command to force signing. See man rndc

rndc flush - Flushes the server's cache.

rndc flushname name [view] - Flushes the given name from the view's DNS cache and, if applicable, from the view's nameserver address database, bad server cache and SERVFAIL cache.

rndc flushtree name [view] - Flushes the given name, and all of its subdomains, from the view's DNS cache, address database, bad server cache, and SERVFAIL cache.

managed-keys (status | refresh ) [class [view]]

c) The commands above seems to work better in conjunction with rndc freeze and rndc thaw. First use rndc freeze, issue the above command(s), then rndc thaw. After rndc thaw, I redundantly issue systemctl restart bind9. Because it seems to work better.

7)Check DNSSEC using https://dnsviz.net/ and https://dnssec-analyzer.verisignlabs.com/

When the first zone is DNSSEC uncomment another zone and work through the steps. The write up is much longer and harder than actually going through the steps to get DNSSEC working.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.