Canausa

No they do not.

Google lists out all of the ip address that it owns and then follows with a ~all, which means soft fail spf on anything else.

Though this is a great idea ( similar to one I had created in the past) there is a major problem I think users should be aware of, concurrency.

Usually using a ID generating system is used when data needs to be shared or asking for an ID from a database is just not an option. It is not typically used in small environments.

I think this solution has an upper bar of effectiveness that is just to low for the problem this is trying to solve. The use of a pseudo random number generator ( python's random module) is too vulnerable to not generating "random" numbers and so many collisions can occur at high concurrency.

Most pseudo random number generators usually are seeded with the time on the host system. As stated in the docs, the best way to use simpleflake is to setup NTP so all the servers times are in sync, the random module on all the servers/processes could be seeded with the same time ( like after a code push). If all the servers get seeded with the same time and the objects being operated on take a uniform time the probability of collisions go up and slow down all processes trying to interact with the objects, as they generate new IDs. As new Ids are being generated you lose the time sort that you originally wanted by including the time in the ID.

I do not mean this to be insulting. I am speaking from experience from having debugged a problem caused the the ID generator at the company I formerly worked for. We used a similar generation technique to identify messages passing through the system, but we included more meta data in our IDs such as sender and recipient of the message and even the server name. With all of that when we ran 150 processes on a 4 core server, there was a .01% of collisions, but that jump significantly once the servers were upgraded to 16 core machines and at that point in the process there was no way to regenerate a new ID, the data was simply dropped out of existence.

This issue is common among DNS providers and is difficult to solve. I formerly worked for a major DNS company as a developer and this problem came up all the time.

The issue is a problem with how DNS works at the basic level. As a reminder there are 2 types of DNS servers. Authoritative DNS servers serve requests for domains assigned to them. Recursive DNS servers will search out the answer for a domain request by talking to root and Authoritative DNS servers.

Now a user trying to access a site could potentially use a recursive DNS server that is located close to them but most people have the option to change who their DNS provider is. In countries where ISP recursive dns servers are slow or fail regularly many users opt to change their recursive dns server. When a user chooses to do so they could pick a recursive dns server that is used in an anycast dns server setup ( As a reminder anycast is an ability to trick the internet in to thinking that alot of servers in many locations look like 1 server and requests are routes to the closest server in anycast ie alot of servers in many data centers all respond to dns requests to the ip address 8.8.8.8).

Now with Route53's latency based routing Amazon tracks that the 8.8.8.0/24 subnet could respond fastest in US-East and so any one using google's recursive dns service will be give the dns record corresponding to US-East regardless of the clients IP address ( Amazon only sees a dns request coming from google's ip address not the client ip address). With the dns response the client with that ip address will then connect to the ip address returned from Amazon through google.

There are DNS products that can bust through this issue.