MySQL warning "IP address could not be resolved"

Solution 1:

When you create a MySQL user [email protected] MySQL has to do a reverse lookup on every IP address connecting to it to determine whether they are part of

Of course, there's no restriction on creating reverse lookups, so I can quite happily ask my provider to set the reverse lookup for my IP address to be if I want... or if I happen to know that's what the users in your database have. This won't let me in, as MySQL then does a forward lookup on the returned domain to make sure it matches the same IP address that's connecting.

You can switch this off with skip_name_resolve in your my.cnf. There are many good reasons for doing this.

The reason you are getting this error is that the IP address in question has no reverse lookup at all.

You also have malicious attackers from China trying to brute force their way into your database. That should be your top priority.

Solution 2:

I think it's a very very bad Idea to expose your database servers directly on the internet.

If you are replicating to a remote host and need internet access to achieve that, I suggest you setup a VPN between the two networks and bind your MySQL servers to listen only to the local network.

If both of your hosts are on the same local network, you will be safe to bind your mysql servers to that network.

Solution 3:

Just got caught by this as well on Amazon RDS. I only wanted to connect to my test database instance (following is definitely not recommended for production databases):

The security groups in Amazon RDS works bit differently than the normal firewall rules for the EC2 instances. If you open MySQL port for the specific IP the IP must be recognized by your MySQL server. If not the connection is refused. The temporary solution is to create new security group i.e. anyone_can_connect_to_mysql with just a single item - allow inbound connection MySQL/Aurora anywhere from the internet and attach this security group to your database.

| MYSQL/Aurora | TCP | 3306 | |

This removes the IP check from client connections so you're free to connect. Don't forget to detach the anyone_can_connect_to_mysql policy from the database once the resolution problems are over.