To be clear, TCP will get less of an issue once https://pagure.io/fedora-infrastructure/issue/9422 is done. The new algorithm has even smaller signatures than the old one.

The problem is getting there because the transition state has two signatures, making replies much bigger and requiring TCP.

As for TTLs, https://00f.net/2019/11/03/stop-using-low-dns-ttls/ sums up the problem. Obviously it's always a compromise.

Maybe even some of the potentially dynamic records can do with longer TTLs. E.g. NS records you mentioned are used exclusively by DNS resolvers, and resolvers are well equipped to handle non-responsive servers and do fallback as needed.

This is not to say stale data should be kept indefinitely, I'm just trying to find a middle ground. I would have to know more about your load balancing/proxying to provide a more useful recommendation. Ping me if you are interested.

It seems pointless to me to keep signed zone files in history. Ensure unsigned zone data are stored with all keys used, but not always changing signatures itself. ldns-read-zone -s can be used to drop DNSSEC data from the zone. Inline signing might be used on the server to create signatures, just ensure it has enough of random entropy. Or save a deploying script, which would create signed zone from unsigned and keys.

The current infrastructure for making DNS work is the following:

an admin makes changes to the files in the DNS repository. they then run commands like the following function:

dnscommit ()
{ 
    local args=$1;
    cd ~/dns;
    git commit -a -m "${args}";
    git pull --rebase && ./do-domains && git add built && git commit -a -m "Signed DNS" && git push
}

The do-domains script does some checking and then runs the jinja2 templates on the various files and then does all signatures (though not correctly with 2 sets of keys). Private keys are stored on batcave in a limited use location.

Once named checkzone says its ok, the commits happen and there are git triggers which do some work.

Each of the Fedora dns servers usually do a regular checkout of the git repository on batcave to get an updated tree. If there was a git update then named reloads to get the changes. A force push can be done from batcave which basically forces the git update on each client. Changes to this will need either a parallel tooling or refactoring of the current system.

ok, so we have the new signatures now.

Do we still want to move away from el8 bind?

We do need to clean up the git repo.

If moving from el8 bind, then move to what instead? Fedora's bind? Something else?

As a side note, moving away from the current 2 commit system would close a potential attack I noticed today.
If someone make a change, commit (not push), run do-domains, and then take the signed DNS file and never push them, that person can use it to do a DNS MITM attack.

Now, MITM is rare and not trivial, DNSsec is not really verified by default (afaik), HTTPS already protect most web applications, and only trusted people have access to the DNS repo, so I do not think there is a big risk.

However, ssh rely on DNS for verification (https://weberblog.net/sshfp-authenticate-ssh-fingerprints-via-dnssec/), and afaik, lets encrypt do verification when there is a request, and avoid MITM is kinda why DNSsec is here, so the current workflow is not optimal.

Wanted to stoke a flame back to this and see where this landed and if their was an outcome to this or what?

So, I think we can close this now.

We have moved at least one of the nameservers to rhel9... and others will move soon.

We need low TTL because we use that to add/remove proxies from our round robin dns setup.

It's anoying to clean out the git history from time to time, but it's handy to distribute things with git. If someone would like to design a new setup for dns, they can make a proof of concept and open a new ticket to sell it to us. ;)

If I missed anything here, please feel free to reopen.