Fair enough. Yet, one may own a domain zone, but the reverse DNS zone may be owned by a hosting service or ISP, for example. Which makes it unfeasible to verify with PTR records.
Ok, but that was already clear and mentioned previously, that it will not work for everone. But the same is true, maybe to a different degree, for the HTTP-based approach implemented so far, as also discussed previously.
So the point is to offer different options of verification with the goal to enable as many servers to be verified as possible.
Yeah, that was just intended for the first beta testing! It’s a little clearer on the beta site since sometime this weekend (and the beta site handles servers that are deleted and re-added now, too).
For most doesn’t the “indirect” verification handle this?
Oh, I totally missed the extra indirection! I will consider this as an option if people report not being able to verify with the current implementation (and those people say that the PTR → forward DNS special record method would work).
Getting the verification link has to be from the NTP server (or one on the same /24 or /64). Then logging into the manage site with that URL can be from any IP. Did you see something else? If you can reproduce it, please send me the traceparent: header from the HTTP request to the validate service. (I don’t see any signs of this happening in the list of validated servers).
1 Like
The current approach for the verification process seems sensible. Is the plan to make it mandatory for all the servers, new and existing? That would allow the pool to be culled of unauthorized server additions. That could be perhaps be accomplished in a year in a handful of phases.
However, at the moment, a server has to first be added in order to be verified, which will have to be modified. Verifying new servers is something that may be added as soon as the current approach is deemed tested.
/24 and /64 are probably fine for now, but I myself get a /60 address. The network mask may have to be a parameter input when adding a server. Of course, masks shorter than perhaps /20 and /56 should not be allowed, as usually only large operations get them. Then again, how could someone like Cloudflare add its servers to the pool?
Another option would be to let new servers get the “Monitoring only” state and only enable setting the netspeed after verification. With some sort of pruning that removes servers not enabled after some time.
I get why prefix-wide verification exists but even with “only” a /24 or /64 this in principle enables adding server from outside your own control. If I host a dedicated server in a datacenter, I control one IP adress there but could add any of the 254 potential servers around me if any of them happened to host an NTP server. While this is unlikely, it still undermines the intent of verification. Further increasing the netsize or making it a parameter would only make this worse.
The goal is to enable verification from at least one other adress in your control, not to enable verification from any adress possibly in your control.
I think organizations at that scale probably have their servers scattered over enough network spaces that finding a common subnet is not feasible anyway. And to reiterate - the need for neighbourhood-verification is only there if your NTP server can somehow not send http requests over its public IP adress in the first place.
Yeah, probably over time and likely for a while on an account by account based on some “does this seem weird” sanity check. Every change is intentionally slow here (partly because my available time and partly in the name of overall stability and caution).
If you are in the situation that your NTP server can’t do an outbound HTTP connection, I imagine you can have some other device (temporarily) use an IP on the same /64 as the NTP server.
They can email us and we’ll figure it out; or I’m sure they have many mechanisms to manage their IP addresses in a way that’d make it work. 
Yeah, we’re sorta half ways there in that you can’t increase the netspeed anymore until after the server is verified. Next steps would be to make the netspeed lower, maybe all the way to zsero (or the server otherwise “paused”) until the server is verified.
/24 for IP4 seems reasonable, for IPv6 I’ve got a /48 at home personally, though granted I’m not normal running servers from home and all, but it could come up.
I like the idea of having this as an additional method for those who can. Ironically I could do this to any of my IP except the two in question from my other post but this could be a good method to verify appliance’s.
What about an option to allow inbound to a redirected port? Say if you can’t make a call out from an IP, maybe verify to an alternate port? So if I have an IP that I can’t get on the same network behind a firewall, let’s say the system picks a random port like 8675 and says open it to your NTP server to allow us to verify over an additional port?
Just out of curiosity: Are you then really using the entire /48 subnet?
Typically, one indeed gets more than a /64 from an ISP. But if one doesn’t setup a “complex” network structure based on that, with multiple subnets, then the local net directly connected to the Internet router typically only uses the first /64 out of a /56 or /48, or whatever your ISP hands out. And the remaining address space is just there so that those who need it can build a more complex network structure with multiple subnets, if desired.
In any case, I would expect there to be more than a single host in the same /64 as the NTP server to be verified. In the worst case, even if the NTP server is the only host in the /64 subnet, I’d expect that in the majority of cases, it should be possible to temporarily attach another host to that subnet to effect the “indirect” verification, as also noted by @ask. A /64 on a point-to-point link might be one exception coming to mind.
This! It wouldn’t be unreasonable to give 24 h for new servers to be verified before they are deleted.
I tried to indirectly verify a server from a different network and it failed with:
server ip not in client ip network
trace: 289dd739f91237afc0cb5ad0ea88684f
1 Like
Instead of just a flag in the database, is it possible to store the verification method that is used to verify a given server?
If later on we realize that a verification method is broken, it would be easy to set only those server to “unverified” state that used the broken method.
2 Likes
Well, thanks for deeming our account unusual. I just had to urgently drop netspeed in Hong Kong and it would not let me because it forced me to very 40 servers first.
Not cool.
Pretty sure I was logged into prod. not beta pool.ntp.org: the internet cluster of ntp servers and faced with a forced verification of 40-50 assets. 
Ok it’s a bit work and what else ? It’s the same work which have new users have.
I think it’s legit and by the way i verfired ours too… Took some time but it’s done.
2 Likes
Existing accounts in good standing should not be locked out from making modifications to net speed on server A until they verified servers B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q in prod, without notice.
2 Likes
I agree with you that there a) should be a news post or a mail to the server operators about this now that it is in prod, and b) that reducing netspeed of existing servers should be possible even without verification.
I’m not sure how “existing accounts in good standing” could be defined objectively and automatically so I don’t think that should be taken into account
1 Like
ah, yeah!
Right now there’s just one check (basically “do you have more than X unverified servers” that “locks” certain changes. I will change it so you can modify the netspeed on verified servers even with a number of unverified servers remaining.
Thanks for going through and verifying your servers though!
6 Likes
@ask
Currently i am unable to increase the bandwidth on some of the IPv6 servers i operate. Since these are appliances (Meinberg) i believe there is no way to have these reach out to http addresses.
How am i to verify these?