SRV, DNSSEC, DNS library

[James Browning]

Hal Murray posted on GitLab:
| | If I say more than about five words in a row, the stupid
| | makes people's brains melt out of their ears.
|
| Well, we'll have to work on that.  If you don't say enough so
| that I can understand it, I'm not going to aprove it.

I hope I succeed in the eventual goal.

| I'm hoping others will contribute too.

Wake up, everyone!

Hal Murray <halmurray at sonic.net> wrote:
> 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.

I can split them up a bit. Most of the code needs to be there
before anything works. The simplest case would be (Why are we
doing this?) non-Srv, non-DNSSEC, just be getaddrinfo but
jankier. So, which comes first?

> 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?  ...

It is supported on Linux, macOS, and FreeBSD. Their git
repository is at [1], and packages are available for Alpine,
Arch, Debian, Fedora, Gentoo, Nix, and other distributions. I'm
ineffective, so most application programming interfaces feel
odd. I haven't looked at the code.

[1] https://github.com/getdnsapi/getdns

> 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've connected to several NTS servers where three-fourths of
queries automatically fail. The pool would quickly filter out
complete failure. I've seen interest in SRV from the pool. There
is interest in alternative ports; the IETF NTP WG shot it down.

> 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?

getaddrinfo() doesn't ask for or use it AFAICT. There are at
least two domains where it is deliberately broken. There are
some domains that don't have it, notably "ntp.org". There is a
flag in the DNS wire protocol that asks for it. Then it gets
parsed, or it's just dead weight.

> 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?]

Ideally, we'd retrieve it from getaddrinfo() or a similar
function. I want something that provides some possible states:
DNSSEC valid now, DNSSEC valid between times, not DNSSEC
secured, DNSSEC invalid, timeout, no such name, and sundry other
failures.

> 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.

It shouldn't (in theory) be that hard. Time restrictions only
apply to the signatures. The public keys and their digests are
timeless. Having 'notBefore' and 'notAfter' variables, then
setting them to the greatest and least values in the chain. The
above could be done while iterating from "." to the sought name.