Removing this allows the handle to be changed and everything seems to work perfectly fine.
The question is what is the reason for this restriction?
For *.example.com it makes sense because you can change the handle normally that way and those hostnames are automatically managed by pds, but it does not seem possible to create a user with handle @example.com without hacking the code.
Also, this prevents using *.*.example.com as handles, even though the automatic handles can only be on one subdomain level.
It is only needed for *.example.com to prevent making an unnecessary HTTP request to itself when it already knows it's not in db. Cause there's no reason an admin would put verification manually.
Suppose PDS hostname is example.com, you are @user.example.com and you want to change handle to @example.com
This code assumes @example.com must be in the database and prevents verification by DNS or HTTP with "Unable to resolve handle" error.
https://github.com/bluesky-social/atproto/blob/27ff43b223e3d55133e2d475921c9bbdb7f45727/packages/pds/src/api/com/atproto/identity/resolveHandle.ts#L26-L32
Removing this allows the handle to be changed and everything seems to work perfectly fine.
The question is what is the reason for this restriction?
For *.example.com it makes sense because you can change the handle normally that way and those hostnames are automatically managed by pds, but it does not seem possible to create a user with handle @example.com without hacking the code.
Also, this prevents using *.*.example.com as handles, even though the automatic handles can only be on one subdomain level.
It is only needed for *.example.com to prevent making an unnecessary HTTP request to itself when it already knows it's not in db. Cause there's no reason an admin would put verification manually.
So I think it should be changed to this