So, I originally added my server to the pool using its DNS FQDN; it had one IPv4 address and one IPv6 address and both were added to the pool with the same DNS name. They have been operating fine for several days now (score 20). Today I had to change the IPv6 address for the server (the old address will continue to work for a while until I disable it). So I added (and verified) the new IPv6 address and the score for that is now slowly increasing but of course the server details do not include the FQDN as I added it by IP. Is there a simple way (an âedit serverâ function) to add the FQDN? If not what is the least disruptive way to get both IP addessses (v4 and v6) associated with the FQDN?
No, thereâs no âeditâ function.
Delete the new IPv6 address from the pool. Once it has been deleted (it will take a minimum of a few days) re-add the server with the FQDN, assuming you have changed the DNS entry by now. The system will notice that the IPv4 entry is already there, and only add the IPv6 with the FQDN.
Yes, this means your new IPv6 address wonât be in the pool for a few days, but thatâs ok from the pool point of view. Other servers will serve the IPv6 NTP requests in the meantime.
No need to wait, it is possible to add the new address, with the same domain name, while the old one is expiring, or remains active in parallel.
As I see it, the problem here is that the new IPv6 address has already been added. I think it must be deleted first to get the FQDN in place.
In any case, try and see what happens. You canât irreversibly break things.
No, it can be added right away once the server is scheduled for deletion. Same the other way round, i.e., when the domain name shall be removed.
I did what @MagicNTP suggested and it worked fine. Also, deletion of my newly added IPv6 address occurred immediately (I guess because the score hadnât become high enough for it to be added to the pool yet).
Thanks folks!
Hmm, what do you mean by that? That right upon what usually is just the scheduling of a serverâs deletion at least a few days ahead of deletion time actually complely removed the address from your list of servers (rather than just adding the note the server is scheduled for deletion)? That would be interesting.
Adding and shortly thereafter deleting an address again is a somewhat frequent event for me, but Iâve never seen that a server would be gone completely right away, before the scheduled deletion date has come.
But I also never paid that much attention to something like this happening, so I might just have missed it. (Often, I delete an address to re-add it right away based on domain name, or to pull in changed geolocation info, without explicitly checking the kind of deletion status in between (scheduled for later, or really gone right then and there), just âblindlyâ re-adding the entry.)
Will pay more attention to this going forward to see whether I can reproduce this. Would be interesting.
While nothing prevents an operator from effectively making a server unavailable at any time, and without notice (or some unforeseen event causing this), the system allowing only the scheduling of the deletion at least a few days ahead of time* is intended to encourage the operator to allow the withdrawal to happen more gracefully. E.g., at least stop assigning new clients to the server ahead of its removal.
When the server never actually was in the pool, i.e., netspeed greater 0 and score greater 10 (like seems to have been the case for you), that would obviously not be relevant. But not sure that case is explicitly considered, and handled accordingly, on the pool side.
* I think right now, a server can be scheduled for removal at the earliest by the end of the second full day after the deletion request. E.g., today, August 1, the earliest a server can be scheduled to be removed by is at the end of day August 3 - i.e., itâll be gone starting August 4.
Yes, that is exactly what happened. My original server that had been serving clients for several days is listed as âscheduled for deletion on August 4â but my newly added server, whose score was slowly increasing but had not yet reached 10, was deleted immediately. No idea if that is meant to happen but to does seem kind of reasonable since it had never started serving any clients.
Ok, thanks! Was just unexpected to me, so just wanted to make sure I hadnât just misunderstood something.
Donât know, either, just have never seen this happen for me before, thatâs all.
Agree, I just hadnât expected that this special case would have been explicitly covered by the implementation (again, my expectation maybe/likely biased by my not having seen this before).
Anyway, interesting to see, thanks for mentioning it!
Anyhow, desire for something like an âedit serverâ feature has been voiced in this forum before, with different scopes. E.g., add/remove a domain name, switch/add/drop zones, âŚ
But itâs definitely more towards the end of my personal wish list, with various other topics more pressing.
You could have just opened a ticket and we could have added the DNS name for you if you like. Thatâs always an option as well.
You are both right!
- In the UI you are scheduling a deletion date in the future
- A server can be added again as long as it has a deletion date; it can be in the future too.
- The server is removed from the pool when the deletion date is less than 14 days in the future (so effectively âright awayâ in most circumstances).
Really the âschedule in the futureâ UI is just there to reinforce that the server wonât stop getting queries right away and to encourage planning ahead when possible.
If you email the server-owner-help address someone can update the hostname. In the new UI itâd be easier to add that for everyone actually, so Iâll add that to the todo for the beta site.
Editing the zone leaves too much room for people to do dumb things. Maybe some day we have enough monitors that we can use âworks well from this countryâ as the inclusion criteria instead of the explicit list; or let operators choose zones and the monitoring system decides whatâs good enough from each country rather than only globally.