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