Job For .local Domain Fails When Using Ubuntu-based VMware Backup Proxy
Get weekly article updates
By subscribing, you are agreeing to have your personal information managed in accordance with the terms of Veeam's Privacy Notice.
Oops! Something went wrong.
Please, try again later.
Challenge
Backup of VMware VMs fails when using an Ubuntu-based Linux VMware Proxy, and the VMware environment is added to Veeam with an FQDN ending in .local (e.g., esxi.somedomain.local).
In the Task Log, errors related to NFC connectivity can be found:
Processing <vm-name> Error: NFC storage connection is unavailable. Storage: [stg:datastore-#,nfchost:host-#,conn:vc.domain.local]. Storage display name: [<datastore-name>]. Failed to create NFC download stream. NFC path: [nfc://conn: vc.domain.local,nfchost:host-#,stg:datastore-#@<vm-name>/<vm-name>.vmx]. Agent failed to process method {Transfer.FileToText}.
In the source agent logs on the Ubuntu proxy, hostname resolution can be observed:
nfc | Opening NFC session with the specified ticket [<guid>]... nfc | Establishing connection with the host [vc.domain.local]. Port: [902]. nfc | Resolving host name (vc.domain.local) to IP address... nfc | Resolving host name (vc.domain.local) to IP address... Failed. nfc | Establishing connection with the host [vc.domain.local]. Port: [902]. Failed. nfc | Opening NFC session with the specified ticket [<guid>]... Failed. nfc | Connecting to NFC session. Target host: [vc.domain.local]. Storage: [<datastore-name>]. VI SOAP connection ID: [vc.domain.local]. Failed. | ERR | Failed to initiate NFC session. Target host: [vc.domain.local]. VI connection ID: [vc.domain.local]. Storage MOID: [<datastore-name>]. | ERR | Failed to resolve name: vc.domain.local. Error: Name or service not known | >> | Lookup of the host name has failed. Host name: [vc.domain.local]. | >> | Cannot establish connection with the host. Host: [vc.domain.local]. Port: [902].
Cause
This issue occurs because .local is only intended for multicast DNS (mDNS), and Ubuntu's default configuration prevents the use of .local for unicast DNS. As a result, the Ubuntu-based machine does not contact the network's DNS server when attempting to resolve .local servers.
Solution
The appropriate solution is to comply with networking standards and not use .local for unicast DNS.
Per RFC 6762 (2013), .local is a special-use domain name, and the advice from the Internet Engineering Task Force (IETF), "we [IETF] recommend against using ".local" as a private Unicast DNS top-level domain."
For more information, review:
More Information
Support Statement
The following proposed workaround is an OS-level modification to alter behavior that is as designed by the developers of the Ubuntu distro. Veeam does not directly support this modification, and the information is only shared here as a stop-gap workaround. Customers are strongly encouraged to ensure their networks comply with networking standards.
Based on an investigation by Veeam's RND team, we have determined that it is possible to work around this limitation by forcing resolved to recognize .local as a valid unicast domain by adding local to the Domains= value in /etc/systemd/resolved.conf and then reboot.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Thank you!
Your feedback has been received and will be reviewed.
KB Feedback/Suggestion
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please, try again later.