On 1/30/19 2:37 PM, Gary E. Miller via devel wrote: > Sure there is, we now have a choice that did not formerly exist, and I > can see uses for both: > > 1. If we do not get desired server: fail > 2. If we do not get desired server: use the offered one instead > > #2 is new to NTS. > > For an unattended server, I would want #2. For testing, or a closely > watched server, I would want #1.
There's another complication too. The server can send back a name or an IP address. What happens if the client request contains a name and the server's response contains an IP? That might be a match (e.g. if the client performs an A/AAAA lookup for the name it requested, it gets back that IP in the response) or it might not. I wonder if a pool server might do this. You ask for "us.nts.pool.ntp.org" and it gives you back a particular IP to connect to. In that case, you'd want to follow the referral. I think it would be useful to understand the use case(s) for the client requesting a specific server vs the use case(s) for a user configuring the client to request a specific server. Or, you can punt this all to the user by offering both choices: nts nts-ke.example.org ^^ Accepts whatever is returned. nts nts-ke.example.org ask ntpd.example.org ^^ Sends an explicit request. Accepts whatever is returned. nts nts-ke.example.org require ntpd.example.org ^^ Sends an explicit request. If not mirrored back exactly, stop. Here's another wrinkle. Does the first example, "nts nts-ke.example.org", send a request for "nts-ke.example.org"? I think it should. -- Richard
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
