Thanks @Sebhoster (and @bjh21)
I added the wget and curl options; and I added a new feature to do verification without using the same IP (but from an IP on the same network).
2 Likes
The IPv4 address validation of 156.106.214.48 was successfull with the nearby IP HTTPS access. Thanks.
1 Like
You do seem to acknowledge in other posts that mode 6 is a security issue, albeit small.
Just saw the button on my server management page in the production system. Is this now an open beta? Or finished?
Thinking about the case where you have an embedded system (for example: LeoNTP) in a network you don’t control. How about this as an alternate authorization method:
- Require a reverse DNS record
- Take the reverse DNS hostname (say, ntp1.example.com) and add a prefix (_verifyntp.ntp1.example.com)
- Require a TXT record with that hostname to be created with your random challenge text
My reasoning for this:
- We need a way to show “I am responsible for the NTP at this IP address”
- In shared environments, usually you can only put a PTR record on your IP address
- Having a PTR record pointed at your domain it is reasonable to assume that the domain owner is responsible for that IP address
- Being able to add TXT records to a domain it is reasonable to assume you have authority over that domain
- Being able to change domain records linked with the IP address it is reasonable to assume you have authority over that IP
4 Likes
Yes; it’s on the production system too now! I haven’t implemented any requirements to verify yet, but so far it seems to go okay for those who’ve tried it and the only UI is the (pretty subtle …) “X”. Honestly I’m surprised anyone found it and clicked on it. 
There was a bug that made non-TLS requests not work; it has been fixed.
4 Likes
@ddrown Yeah, I think modifying in-addr.arpa zones would be a reasonable verification method (though I’d just make it having a TXT record on _ntppool.123.2.0.192.in-addr.arpa).
I don’t know if it’s really practical though. How many people running LeoNTP also can update their reverse DNS? I know a lot of the servers I run I have limited ability to update it. Certainly I couldn’t talk my ISP at home into doing so (but my home internet is otherwise capable of running an NTP server just fine).
Why not keep it simpler?
The NTP server IP has a PTR, lets say “ntp.company.tld”.
In that case having a TXT record like “allowntppool” under “ntp.company.tld” would be sufficient to validate that the owner is happy with having it added to the NTP pool. Also, you would not have any problems adding non-standard records to the PTR.
3 Likes
Hi,
While you are right that this would stop people from adding arbitrary NTP servers that they have no authority over, there are many people who do not have any control over their PTR record, so if this were to be adopted it would need to be only one of several verification methods.
Yes, I thought of it as an additional mechanism aside the HTTP request method.
1 Like
Thanks, Ask! Great to see work in this area!
Happy to see that you’ve implemented source-ip checks. I think anyone should be capable of doing a singluar HTTPS-request from their NTP-server without their security officer noticing… 
The DNS-type validations fail to actually confirm IP/NTP-machine ownership.
2 Likes
A few recommendations:
- The “X” symbol is confusing as I though this button is for removing the server from the pool without reading this thread. It’s recommended to change it to “Unverified” and “Verified” for clarity.
- Please consider how server operators who have IP addresses solely mapped to dedicated NTP servers without http or command line capabilities (e.g. LeoNTP) could complete the verification.
@ddrown Yeah, I think modifying in-addr.arpa zones would be a reasonable verification method (though I’d just make it having a TXT record on
_ntppool.123.2.0.192.in-addr.arpa).I don’t know if it’s really practical though. How many people running LeoNTP also can update their reverse DNS? I know a lot of the servers I run I have limited ability to update it. Certainly I couldn’t talk my ISP at home into doing so (but my home internet is otherwise capable of running an NTP server just fine).
The amount of people who can add a TXT record to a reverse zone is going to be pretty small. Most ISPs and hosts that give you automated tools to manage reverse DNS on your IPs will only let you add a PTR record. Which is why I was thinking a TXT record on a regular zone pointed to by the reverse zone.
2 Likes
Indeed. Servers are added to the pool by IP address, not host names. One could concoct a host name for an IP address that he didn’t control and pass a DNS validation.
Such appliances do pose a difficulty. However, if they are behind IPv4 NAT, any other host behind it can be used to verify the IPv4 address. Otherwise and for IPv6, perhaps the only possibility is to temporarily assign the appliance’s address to another host to perform the verification.
As is, the “indirect” method of verification fails to verify that one controls the server, for I could “verify” the address using my phone on the cellular network.
I think you may have missed the part where a reverse lookup via PTR record is used to link a hostname to the IP address before the hostname is used for verification purposes.
Thank you Ask.
All the verification worked like a charm. Software Server without problems and also our hardware appliance have been verified with a connection from the same subnet 
1 Like
No, I didn’t. PTR records are often neglected and one could still pretend control a server through DNS records.
Can you elaborate on that? The reverse name space is delegated alongside the address space. What can happen is that records aren’t populated for some space, or statically populated, e.g., by an ISP to point to some generic name. That is why this will obviously only work in some circumstances, as previously mentioned. But how do you theorize that a reverse record delegated to the holder of the IP address space but maybe not populated by the owner of the delegation could be highjacked by someone else?