Reverse name lookup is broken for current hostname in ubuntu VMs

[lhotari]

Description

Reverse name lookup is broken for the current hostname. This leads to odd issues. Here are some reports from GitHub Community:

• https://github.community/t/github-action-and-oserror-errno-99-cannot-assign-requested-address/173973
• https://github.community/t/volatile-local-ip-addresses-during-action-run/174362
• https://github.community/t/github-actions-timeout/174533

This is a problem report in apache/pulsar: apache/pulsar#10232
and workaround in apache/pulsar apache/pulsar#10233

I have suggested this general workaround to the problem:

- name: Add the current IP address, long hostname and short hostname record to /etc/hosts file
  run: |
     echo -e "$(ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1)\t$(hostname -f) $(hostname -s)" | sudo tee -a /etc/hosts

Question, Bug, or Feature?: Bug

Virtual environments affected

• Ubuntu 16.04
• Ubuntu 18.04
• Ubuntu 20.04
• macOS 10.15
• macOS 11.0
• Windows Server 2016 R2
• Windows Server 2019

Expected behavior

hostname -i, nslookup $(hostname -s) and nslookup $(hostname -l) should return the IP address of the current hostname.

Actual behavior

hostname -i, nslookup $(hostname -s) or nslookup $(hostname -l) returns an IP address that changes and the IP address doesn't belong to the current host.

Repro steps

Add this command to some action and run it ip a; while [ 1 ]; do nslookup $(hostname); sleep 3; done

Example output

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0d:3a:11:ff:4c brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.35/16 brd 10.1.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::20d:3aff:fe11:ff4c/64 scope link 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:b1:57:12:f2 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.1.83

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.1.83

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.1.83

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.1.83

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.0.37

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.0.37

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.0.37

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   fv-az132-427.w5jmtgevnbgefpdoz44oxoejwc.bx.internal.cloudapp.net
Address: 10.1.0.37

In the above case, the reverse lookup returns addresses 10.1.1.83 and 10.1.0.37 which aren't the ip addresses of the current host. The address of eth0 is 10.1.1.35 .

[Darleev]

Hello @lhotari,
Thank you for the detailed report.
We are investigating the issue.

[iemejia]

Can somebody here please confirm when this is done so we can remove the workarounds?

[miketimofeev]

@iemejia it should be finished by now

[iemejia]

Thanks @miketimofeev it works like a charm now!

[miketimofeev]

@lhotari I'm going to close the issue since the root cause is fixed. Please feel free to contact us if you have any concerns.
Thank you!

[lhotari]

@lhotari I'm going to close the issue since the root cause is fixed. Please feel free to contact us if you have any concerns.
Thank you!

@miketimofeev Sounds good. Thanks for resolving the issue.