SRV, DNSSEC, DNS library
Hal Murray
halmurray at sonic.net
Sun Mar 29 10:51:57 UTC 2026
There seem to be 3 topics. Are they tangled? If you can split one off,
please start a new thread for it and maybe we can come back to the others
after we have established some background.
Is the new library a package supported by most OSes/distros? Or some code
out on the web where we can grab a copy and build it from source? (like
we do for libaes_siv) If the latter, does the API feel good? Have you
looked at the code? ...
SRV allows us to specify a port. That would be helpful for bypassing ISP
blocking of port 123. How much of a problem is that? We can do that
already for traffic protected by NTS.
I think the NTS-KE code allows host:port. I don't know if that works for
the non NTS path. If not, it would be easy to fix. That doesn't help the
pool. How much trouble is the pool having with blocking port 123? Are
they interested is supporting SRV records and/or non-standard ports?
[Their forum to email stuff doesn't work so I don't see their discussion
unless something else points me at their archives.]
I haven't paid attention to DNSSEC. How widely deployed is it? Is there
an API where we can turn it on and off? Or some flag in the API that says
must have or did have?
Do we need to clutter up our code with any knowledge of DNSSEC? (rather
than just let the OS set a global parameter) We have 2 alternatives for
getting started without decent time. One is to run RoughTime before
firing up ntpd. The other is to use self signed certificates with long
lifetimes. [I'll write a note about this if that will help. Where should
it go?]
The idea of do-everything-without-time-checks, and after you get the
answer go back and see if the checks-would-have-passed turns into a lot of
ugly code. I'm not very interested in that option.
--
These are my opinions. I hate spam.
More information about the devel
mailing list