skip_name_resolve is not set in my.cnf: MySQL's default behavior is to perform a reverse DNS PTR lookup for every incoming connection. In cloud environments where the connecting IP is a dynamic Azure or AWS address, there is often no PTR record, so the lookup stalls until it times out.. DNS server unreachable from the MySQL host: The MySQL server cannot reach its configured DNS resolver (e.g., 8.8.8.8 or an internal resolver) because of firewall rules, a misconfigured /etc/resolv.conf, or a transient network partition. All connections block until the lookup times out.. High-latency DNS responses: Even when a PTR record exists, a slow DNS server (>5 s response time) can exceed MySQL's internal timeout for name resolution, causing sporadic 1042 errors that appear non-deterministic and are hard to reproduce locally.. GRANT statements use hostnames instead of IPs: If skip_name_resolve is already set on a replica or read-only node but not on the primary, and grants were created with hostnames (e.g., 'etl_user'@'adf-shir.internal'), the grant will never match because MySQL ignores hostnames when skip_name_resolve is active, resulting in a connection refused that manifests as 1042 on some nodes and a different auth error on others.. Self-hosted integration runtime (SHIR) or Spark cluster with ephemeral IPs: ADF's Self-Hosted Integration Runtime and Azure Databricks clusters receive a new private IP on each restart. If your DNS zone has no wildcard PTR record for the subnet and MySQL does not skip name resolution, every cold-start connection attempt fails until DNS catches up or the lookup times out.. MySQL container or VM restart cleared the hosts file: When MySQL runs in a Docker container or cloud VM, /etc/hosts may be reset on restart, removing any static hostname-to-IP mappings that were used as a workaround. After the restart, lookups that previously resolved via /etc/hosts now hit DNS and fail.. Connection pool recycling at high frequency: Connection pools (e.g., SQLAlchemy, HikariCP) that aggressively recycle connections force a new TCP handshake and therefore a new DNS lookup for each recycled connection. Under load, the burst of simultaneous PTR queries can exhaust DNS resolver capacity, causing a subset of connections to time out with 1042.

Step 1 — Verify the root cause by checking the MySQL error log and testing DNS from the MySQL host: `sudo tail -n 100 /var/log/mysql/error.log | grep 1042` and `dig -x +time=2` (replace with the IP of your ADF SHIR or Spark driver). A timeout in dig confirms the DNS path is broken.. Step 2 — Add skip_name_resolve to [mysqld] in /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu/Debian) or /etc/my.cnf (RHEL/Amazon Linux): `echo 'skip_name_resolve' | sudo tee -a /etc/mysql/mysql.conf.d/mysqld.cnf` — then restart MySQL: `sudo systemctl restart mysql`. For managed services like Amazon RDS or Azure Database for MySQL Flexible Server, set the parameter skip_name_resolve = ON in the Parameter Group or Server Parameters blade and apply without a full restart (flexible server supports in-place apply).. Step 3 — After enabling skip_name_resolve, audit all existing GRANT statements for hostname-based entries that will silently stop matching: `SELECT user, host FROM mysql.user WHERE host NOT REGEXP '^[0-9%]';` — any row with a non-IP, non-wildcard host needs to be migrated. Run: `RENAME USER 'etl_user'@'adf-shir.internal' TO 'etl_user'@'%';` (or to the specific CIDR if you want to scope access). Then flush: `FLUSH PRIVILEGES;`. Step 4 — If you cannot set skip_name_resolve (e.g., shared managed service with the parameter locked), add a static PTR record for the connecting IP in your DNS zone. In Azure Private DNS: go to the reverse lookup zone (e.g., 10.in-addr.arpa), add a PTR record pointing to the SHIR hostname. Verify with: `nslookup ` from the MySQL host.. Step 5 — As a fast interim fix without a MySQL restart, add the client IP to /etc/hosts on the MySQL host so the OS resolves it locally before hitting DNS: `echo '10.0.1.42 adf-shir.internal' | sudo tee -a /etc/hosts`. This survives until the next container/VM restart and is not suitable as a permanent fix.. Step 6 — For ADF pipelines, increase the connection timeout in the Linked Service to give DNS more time: in the ADF Linked Service JSON, set `"connectionTimeout": 60` (seconds) under typeProperties. This does not fix DNS but prevents ADF from marking a run as failed during a slow PTR resolution — useful while you arrange the DNS fix.. Step 7 — Verify the fix by running a test connection from the SHIR host or Spark driver node: `mysql -h -u etl_user -p -e 'SELECT 1;'` — if it returns without a 1042, the fix is effective. Then trigger a manual ADF pipeline run and confirm all activities succeed before closing the incident.

Medium severityconnection

MySQL Error:
1042

Impact

Every ADF pipeline run that opens a fresh connection to MySQL can fail at the TCP handshake phase — before any SQL runs — leaving downstream tables completely stale. If the DNS timeout is long (default 30 s), your pipeline doesn't just fail fast: it blocks for 30 s per connection attempt, inflating run time and burning ADF DIU hours before the error surfaces.

Error 1042 fires at TCP handshake time, before any SQL is executed. This means no rows are read or written — the destination table is left with its previous data or, on a truncate-and-reload pattern, can be left empty if the truncation ran before the connection failed. In ADF, the activity is marked Failed immediately, halting dependent activities and leaving the entire dataset stale. If the DNS timeout is 30 seconds and the pipeline opens multiple parallel connections, total blocked time can reach several minutes per run, consuming Integration Runtime concurrency slots and pushing downstream refresh windows past their SLA.

What does this error mean?

MySQL error 1042 occurs when the server cannot resolve the connecting client's IP address to a hostname via reverse DNS (PTR lookup). By default, MySQL performs a reverse DNS lookup for every new connection to match against GRANT statements that use hostnames. When the DNS server is unreachable, slow, or has no PTR record for the client IP, the lookup times out and MySQL refuses the connection with error 1042. In data-pipeline contexts this typically surfaces as a failed ADF activity, a dbt run that cannot open a connection, or a scheduled ETL job that intermittently errors during peak network load. The engineer sees the pipeline marked failed — often with no rows written — before any SQL is executed.

Common causes

1skip_name_resolve is not set in my.cnf: MySQL's default behavior is to perform a reverse DNS PTR lookup for every incoming connection. In cloud environments where the connecting IP is a dynamic Azure or AWS address, there is often no PTR record, so the lookup stalls until it times out.
2DNS server unreachable from the MySQL host: The MySQL server cannot reach its configured DNS resolver (e.g., 8.8.8.8 or an internal resolver) because of firewall rules, a misconfigured /etc/resolv.conf, or a transient network partition. All connections block until the lookup times out.
3High-latency DNS responses: Even when a PTR record exists, a slow DNS server (>5 s response time) can exceed MySQL's internal timeout for name resolution, causing sporadic 1042 errors that appear non-deterministic and are hard to reproduce locally.
4GRANT statements use hostnames instead of IPs: If skip_name_resolve is already set on a replica or read-only node but not on the primary, and grants were created with hostnames (e.g., 'etl_user'@'adf-shir.internal'), the grant will never match because MySQL ignores hostnames when skip_name_resolve is active, resulting in a connection refused that manifests as 1042 on some nodes and a different auth error on others.
5Self-hosted integration runtime (SHIR) or Spark cluster with ephemeral IPs: ADF's Self-Hosted Integration Runtime and Azure Databricks clusters receive a new private IP on each restart. If your DNS zone has no wildcard PTR record for the subnet and MySQL does not skip name resolution, every cold-start connection attempt fails until DNS catches up or the lookup times out.
6MySQL container or VM restart cleared the hosts file: When MySQL runs in a Docker container or cloud VM, /etc/hosts may be reset on restart, removing any static hostname-to-IP mappings that were used as a workaround. After the restart, lookups that previously resolved via /etc/hosts now hit DNS and fail.
7Connection pool recycling at high frequency: Connection pools (e.g., SQLAlchemy, HikariCP) that aggressively recycle connections force a new TCP handshake and therefore a new DNS lookup for each recycled connection. Under load, the burst of simultaneous PTR queries can exhaust DNS resolver capacity, causing a subset of connections to time out with 1042.

How to fix it

1Step 1 — Verify the root cause by checking the MySQL error log and testing DNS from the MySQL host: `sudo tail -n 100 /var/log/mysql/error.log | grep 1042` and `dig -x <client_ip> +time=2` (replace <client_ip> with the IP of your ADF SHIR or Spark driver). A timeout in dig confirms the DNS path is broken.
2Step 2 — Add skip_name_resolve to [mysqld] in /etc/mysql/mysql.conf.d/mysqld.cnf (Ubuntu/Debian) or /etc/my.cnf (RHEL/Amazon Linux): `echo 'skip_name_resolve' | sudo tee -a /etc/mysql/mysql.conf.d/mysqld.cnf` — then restart MySQL: `sudo systemctl restart mysql`. For managed services like Amazon RDS or Azure Database for MySQL Flexible Server, set the parameter skip_name_resolve = ON in the Parameter Group or Server Parameters blade and apply without a full restart (flexible server supports in-place apply).
3Step 3 — After enabling skip_name_resolve, audit all existing GRANT statements for hostname-based entries that will silently stop matching: `SELECT user, host FROM mysql.user WHERE host NOT REGEXP '^[0-9%]';` — any row with a non-IP, non-wildcard host needs to be migrated. Run: `RENAME USER 'etl_user'@'adf-shir.internal' TO 'etl_user'@'%';` (or to the specific CIDR if you want to scope access). Then flush: `FLUSH PRIVILEGES;`
4Step 4 — If you cannot set skip_name_resolve (e.g., shared managed service with the parameter locked), add a static PTR record for the connecting IP in your DNS zone. In Azure Private DNS: go to the reverse lookup zone (e.g., 10.in-addr.arpa), add a PTR record pointing to the SHIR hostname. Verify with: `nslookup <client_ip> <dns_server_ip>` from the MySQL host.
5Step 5 — As a fast interim fix without a MySQL restart, add the client IP to /etc/hosts on the MySQL host so the OS resolves it locally before hitting DNS: `echo '10.0.1.42 adf-shir.internal' | sudo tee -a /etc/hosts`. This survives until the next container/VM restart and is not suitable as a permanent fix.
6Step 6 — For ADF pipelines, increase the connection timeout in the Linked Service to give DNS more time: in the ADF Linked Service JSON, set `"connectionTimeout": 60` (seconds) under typeProperties. This does not fix DNS but prevents ADF from marking a run as failed during a slow PTR resolution — useful while you arrange the DNS fix.
7Step 7 — Verify the fix by running a test connection from the SHIR host or Spark driver node: `mysql -h <mysql_host> -u etl_user -p -e 'SELECT 1;'` — if it returns without a 1042, the fix is effective. Then trigger a manual ADF pipeline run and confirm all activities succeed before closing the incident.

Example log output

2026-05-11T08:14:03.412Z [ERROR] ADF Activity 'Copy_MySQL_Orders' failed. ErrorCode=UserErrorFailedToConnectMySqlServer, Message=Cannot connect to MySQL server. Error: Host '10.0.1.42' is not allowed to connect to this MySQL server. MySQL error code: 1042.2026-05-11T08:14:03.415Z [ERROR] MySQL: ERROR 1042 (HY000): Can't get hostname for your address2026-05-11T08:14:33.901Z [WARN] dbt: Database Error in model stg_orders (models/staging/stg_orders.sql) — (1042, "Can't get hostname for your address") — retrying (1/3)

Frequently asked questions

MySQL 1042 fix: do I have to restart MySQL to apply skip_name_resolve?

On self-hosted MySQL (5.7, 8.0) yes — skip_name_resolve is a static variable that requires a server restart to take effect. On Amazon RDS and Azure Database for MySQL Flexible Server you can apply it via the parameter group or Server Parameters blade; Flexible Server supports a no-downtime apply, while RDS may require a maintenance window reboot depending on the instance class.

Will enabling skip_name_resolve break existing user accounts?

Only accounts whose host column contains a hostname (e.g., 'user'@'myserver.corp') will stop matching — MySQL will no longer resolve that hostname during auth. Accounts using an IP address ('user'@'10.0.1.42'), a wildcard ('user'@'%'), or a CIDR range are unaffected. Run `SELECT user, host FROM mysql.user WHERE host NOT REGEXP '^[0-9%]';` before enabling to see which accounts need migration.

MySQL 1042 retry: will ADF automatically retry after this error?

ADF retries a failed activity according to the retry count and interval set on the activity (default: 0 retries). Because 1042 is a connection-level error that happens before any query executes, ADF treats it as a transient failure and a retry will sometimes succeed if DNS recovered in the meantime. Set retry count to 3 with a 60-second interval in the activity settings as a short-term mitigation — but fix DNS or enable skip_name_resolve to stop the root cause.

Can I get MySQL error 1042 on Amazon RDS or Azure Database for MySQL?

Yes. On RDS the parameter is called skip_name_resolve and defaults to 0 (disabled) on older parameter groups. On Azure Database for MySQL Flexible Server the parameter is skip_name_resolve and can be toggled in Server Parameters without a full restart. Both managed services still perform reverse DNS lookups by default, and connections from services with dynamic IPs (Azure Databricks, ADF IR) regularly trigger 1042 if the parameter is left at its default.

Source · dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html