When examining DHCP lease files (/var/lib/dhcp/dhclient.leases), you might notice hostname transmission behavior that doesn't match your explicit configuration. Here's what's happening under the hood:

# Typical lease entry showing hostname transmission
lease {
  interface "eth0";
  fixed-address 192.168.1.100;
  option host-name "fozzie";
  option domain-name-servers 8.8.8.8;
  renew 2 2023/05/16 12:34:56;
}

Modern Linux distributions (including Ubuntu) often ship with a modified dhclient-script that automatically sends the system hostname even without explicit configuration. This happens through these mechanisms:

1. The DHCP_HOSTNAME variable in /etc/sysconfig/network (RHEL/CentOS)
2. The send host-name = gethostname() logic in dhclient hooks
3. The /etc/dhcp/dhclient-enter-hooks.d/ scripts

The variation between your VirtualBox and Xen environments occurs because:

# VirtualBox NAT interface typically doesn't process DHCP options
VBoxManage modifyvm "VM Name" --natdnshostresolver1 off

While enterprise DHCP servers (ISC DHCPd, Windows DHCP) actively request and store hostnames:

# ISC DHCPd server configuration that requests hostnames
option domain-name "example.com";
option domain-name-servers 8.8.8.8, 8.8.4.4;
option host-name = option host-name;

The DHCP protocol specification (RFC 2132) states that the hostname option (12) should contain only the first label of the FQDN. This explains why fozzie.our.domain becomes just fozzie in the lease file.

To explicitly control hostname transmission, create or modify /etc/dhcp/dhclient.conf:

# Explicit hostname configuration
interface "eth0" {
  send host-name "custom-hostname";
  send fqdn.fqdn "custom-hostname.domain.com";
  send fqdn.encoded on;
  send fqdn.server-update off;
}

Use these commands to diagnose hostname transmission:

# View raw DHCP traffic
tcpdump -i eth0 -vvv -s 1500 'port 67 or port 68'

# Check dhclient debug output
dhclient -d -v eth0

# Verify system hostname
hostnamectl status

During recent network troubleshooting, I observed an interesting DHCP behavior where my Ubuntu server automatically transmitted its hostname to the DHCP server despite no explicit configuration in dhclient.conf. Let's break down what's happening under the hood.

The standard DHCP client (dhclient) on modern Linux distributions typically includes these default behaviors:

# Default dhclient.conf behavior (Ubuntu/Debian)
send host-name = gethostname();
interface "eth0" {
    send host-name = gethostname();
    request subnet-mask, broadcast-address, time-offset, routers,
        domain-name, domain-name-servers, host-name;
}

Even without explicit configuration, most DHCP clients will:

• Use the system hostname (from /etc/hostname) when available
• Strip domain portions when sending to DHCP servers
• Follow distro-specific default configurations

The observed difference between your VirtualBox and Xen environments likely stems from:

# VirtualBox DHCP typically doesn't request hostnames
VirtualBox DHCP server: 
    option domain-name-servers 8.8.8.8, 8.8.4.4;
    option domain-name "local";
    default-lease-time 3600;
    max-lease-time 7200;

# Enterprise DHCP servers usually support hostname options
ISC DHCP server:
    option domain-name "example.com";
    option domain-name-servers ns1.example.com;
    ddns-update-style interim;
    ignore client-updates;
    allow client-hostname;

The DHCP client automatically truncates the FQDN to just the hostname portion through this process:

# Pseudocode of what happens internally
def prepare_dhcp_hostname():
    fqdn = socket.gethostname()      # "fozzie.our.domain"
    hostname = fqdn.split('.')[0]    # "fozzie"
    dhcp_option_set('host-name', hostname)

To explicitly control hostname transmission:

# /etc/dhcp/dhclient.conf
send host-name "custom-hostname";
send fqdn.fqdn "host.example.com";
send fqdn.encoded on;
send fqdn.server-update off;

# Debug DHCP transactions
sudo dhclient -v -r eth0  # Release current lease
sudo dhclient -v eth0     # Get new lease with verbose output

Check active leases and hostname transmission:

cat /var/lib/dhcp/dhclient.leases
grep -i "host-name" /var/lib/dhcp/dhclient.eth0.leases

Understanding this automatic hostname propagation helps with:

• DNS record automation in enterprise environments
• Troubleshooting duplicate IP/hostname issues
• Security audits of DHCP transactions
• Virtual machine migration between environments