This article provides answers to common error messages on Robot.
To use Robot, you need to configure your browser needs to accept cookies.
When I submit an order, everything seems to be OK, but nothing happens (confirmation emails, entry under domains/CHProv (KK) orders)!
Most likely, you entered an invalid email address on your Robot account. To fix this, go to Robot and click on the user icon in the top-right corner. Then click on
Email interface. -> Then enter a valid email address at
Robot order confirmation address. You need to enter a valid email address here for Robot to function properly.
Handles are always tied to the respective domain ending (TLD). For example, only .de handles can be used for .de domains.
The last column of the handle list (Menu item
Handles) specifies which roles you can use the handle for. H stands for holder, A for admin-c, T for tech-c and Z for zone-c.
Company handles can only be used as holder (except for .at). All other roles (admin-c, tech-c and zone-c) require a person handle.
To be able to use a .de handle for a particular role, the following optional fields should be completed:
- Admin-c: Phone and email
- Tech-c: Phone, fax and email
- Zone-c: Phone, fax and email
Here is an example of such an error message:
--- status: failed transaction: RO20110726111619-018731200-167488 message: - text: Illegal operation on own domain. argument: your-server.de level: error code: 399 reference: 167488
The domain is already hosted by Hetzner, so you can't start a domain transfer. Instead, you need a Hetzner internal domain transfer for the domain.
This error message usually occurs with .com/.net/.org/.info/.biz domains. Here's an example of such an error message:
--- status: Object status prohibits operation. code: failed transaction: RO20110804191323-007996000-168158 reference: 168158
This message means that a transfer block has been placed on the particular domain concerned (
clientTransferProhibited or something similar). You can check on this by doing a whois query, for example.
The current provider/registrar needs to remove the transfer block. Then you can restart the domain transfer via the Hetzner Registration Robot.
This error message usually only occurs with .de/.at domains. Here's an example of such an error message:
--- status: failed transaction: QRO20100831152413-021702400-812318t2 message: - text: Required glue record is missing. argument: ns1.your-server.de. level: error code: 318 - text: Required glue record is missing. argument: ns2.your-server.de. level: error code: 318 reference: 812318
If the hostnames of the nameservers are located within the new domain, then you need to enter glue records into the
Primary Nameserver und
Secondary Nameserver input fields:
In the example below, the relevant nameservers
<18.104.22.168> for the domain
<yourserver.de> should be
You need to fill out the fields
1. Nameserver and
2. Nameserver on Robot as follows (Hostname + space + IP address):
ns1.yourserver.de 22.214.171.124 ns2.yourserver.de 126.96.36.199
Should the glue record also yield an IPv6 address as well as an IPv4 address, the entries must read as follows:
ns1.yourserver.de 188.8.131.52 12ab:23cd:34ef:0:0:0:0:1 ns2.yourserver.de 184.108.40.206 12ab:23cd:34ea:0:0:0:0:1
For .com/.net/.org/.info/.biz/.eu domains, you need to register the nameservers via Robot instead of specifying the IP address.
This error message usually only occurs with .de domains. Here's an example of such an error message:
--- status: failed transactionID: QRO20100831152413-021702400-812318t2 message: - text: Nameserver error. argument: 'ERROR: 902 Timeout (target) (ns1.your-server.de/220.127.116.11:53)' level: error code: 319 - text: Nameserver error. argument: 'ERROR: 902 Timeout (target) (ns2.your-server.de/18.104.22.168:53)' level: error code: 319 reference: 812318
Here, you probably forgot to create the corresponding DNS entry for the domain on the nameservers specified for the domain.
If you want to use Robot nameservers a domain, you can create the DNS entry via the menu item
DNS entries ->
New DNS entry. You should do this before starting the domain registration/domain transfer.
This error message usually occurs with .de domains. Here's an example of such an error message:
--- status: failed transactionID: QRO20100831152413-021702400-812318t2 message: - text: Nameserver error. argument: 'ERROR: 118 Inconsistent set of NS RRs (IP, NS host names) (ns1.your-server.de/22.214.171.124, [ns1.your-server.de, ns3.your-server.de])' level: error code: 319 - text: Nameserver error. argument: 'ERROR: 118 Inconsistent set of NS RRs (IP, NS host names) (ns2.your-server.de/126.96.36.199, [ns1.your-server.de, ns3.your-server.de])' level: error code: 319 reference: 812318
This message means that the nameserver entries (NS records) in the DNS entry for the corresponding domain do not match the nameservers specified for the domain. You either need to adjust the zone file or the entries on Robot.
In the example above, the nameservers
<ns2.your-server.de> are specified for the domain. However, only the NS records for
<ns3.your-server.de> have been placed in the DNS entry.
Nameserver not found in database and/or
Host YourNameserver.de not found on domain registration/-transfer/-update
If you want to specify your own nameservers for .com/.net/.org/.info/.biz/.eu domains, you need to register these first via the Domain Registration Robot (Menu item
DNS entries ->
Registered nameservers). When you have done that, you can then re-try the domain update /transfer/registration.
You will receive this kind of abuse message if your server is sending us packets with source-MAC that we do not permit.
Therefore, this issue is caused by outgoing traffic only!
The following MACs are allowed:
- MAC of your physical NIC
- MAC of iDRAC/KVM (if present on your server)
- virtual MACs generated on Robot for additional single IPs
Our system policy prohibits using MACs that we do not allow:
- Manually changing the hardware address (MAC)
The majority of customers affected by this kind of abuse are running some kind of virtualization where the system can generate new MACs on the fly.
Some servers also redistribute traffic that was not meant for them, for example, broadcasts.
We analyze the MAC addresses we learn at your server's switchport, and if there is a discrepancy with our records, you receive a mail like this one.
If you are using virtualization with additional IPs, you need to check your configuration.
There are two types of possible configurations:
- Bridged setup You should use this configuration with additional single IPs which have their own virtual MAC address. The virtual NICs of your VM can be in the same virtual switch/bridge as your physical NIC. You can create virtual MACs for your additional single IP via Robot (Server -> IP). The maximum number of single IPs is 6 per server.
- Routed setup You should use this configuration with additional subnets. It is not possible to generate virtual MACs for your additional subnets, because subnets are routed onto one of your server's IPs. Therefore, you should also route these IPs within your server. Please make sure to place these VMs in a different virtual switch/bridge than your physical NIC.
Certain outdated ESXI versions can cause a MAC with the suffix
::C4:70 to appear in your abuse report. If that is the case, please update ESXI immediately as this MAC appears in conjunction with an unpatched remote code execution vulnerability. After the update, you need to reboot the server so the fix can take effect.
Please see these security advisories: https://www.vmware.com/security/advisories/VMSA-2021-0010.html https://www.vmware.com/security/advisories/VMSA-2021-0002.html
Some Proxmox systems may have an entry in PVE-FW, which sends a TCP/RST reply on port 43 if they receive broadcasted traffic not addressed to this host.
This causes our switch to learn the MAC of the broadcasted traffic and generate this mail. The solution is to update Proxmox and reboot the server. If this is not possible for some reason, you can block outgoing port 43 with a local firewall as a rough fix. But we highly suggest keeping your systems always up-to-date.
Here are some links where this issue is being discussed:
https://forum.hetzner.com/index.php?thread/28368-abuse-meldung-bzgl-mac-adressen/&postID=279208#codeLine3fea0f3 https://forum.proxmox.com/threads/proxmox-claiming-mac-address.52601/page-3#post-416219 https://forum.proxmox.com/threads/proxmox-generate-2-mac-address-visibile-on-the-switch-not-allowed-by-the-data-center.95946/#post-417099
- vSwitch - You are allowed to use any MAC within the VLAN of your vSwitch. Please make sure that you are using these MACs only with the correct VLAN and not at your untagged "normal" uplink.
- VPN adapter - If you are using Layer-2 VPN/tunnel adapter, please make sure it is not in the same virtual switch/bridge as your physical NIC.
Please monitor your outgoing traffic with tcpdump or Wireshark. It often helps to leave tcpdump running for quite some time and for each (virtual) interface.
Please also use a negative filter to dump only the traffic that is problematic.
tcpdump -Q out -ni %interfacename% ether host not %allowedMAC% and ether host not %allowedMAC%
If you are still unsure how to proceed, please open a support ticket via Robot.