Skip to content
Control Plane Labs
Search

EUI64 record

Stores an IEEE EUI-64 link-layer identifier in DNS for controlled private-namespace mappings and device operations.

Written and maintained by Ben Ennis

Last reviewed July 27, 2026 · How we verify this

Zone-file example

sensor.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a

Typical uses

  • Representing a managed device's 64-bit link-layer identifier
  • Supporting restricted inventory or access-network correlation
  • Providing a standard value format for private DNS tooling
  • Keeping device identity data separate from ordinary address records

When it breaks, check

  • Presentation format is exactly eight two-digit hexadecimal fields separated by hyphens
  • The RR does not cause a client to synthesize an IPv6 address or perform address resolution
  • Conflict handling for multiple values belongs to the consuming application
  • Public publication can create a stable, trackable identifier and should be avoided

What the EUI64 record does

EUI64 is the eight-octet companion to EUI48. It lets a private DNS system represent a device identifier in a predictable record rather than encoding the value into a label or an opaque TXT string. The record can support inventory, access-network, or managed-device workflows in which another system separately maps the identifier to an address or service.

The value is stored in network byte order and displayed as eight hexadecimal pairs separated by hyphens. EUI64 does not prove that a device owns the identifier, does not replace DHCP or an asset database, and does not create an A or AAAA answer. A consumer that receives multiple records must apply an explicit conflict policy because DNS ordering is not an inventory authority.

Zone-file and wire format

EUI64 RDATA is a single eight-octet address. The presentation form uses eight two-digit hexadecimal fields separated by hyphens, with either case accepted for hexadecimal digits. The field is encoded in network order. This example is illustrative; do not copy a real device identifier into a public zone.

sensor.example. 86400 IN EUI64 00-00-5e-ef-10-00-00-2a

Common uses

Use EUI64 in a private namespace when a controlled operational system needs to publish or query a stable device identifier. Keep the DNS zone access-controlled and document which inventory, DHCP, or access system is authoritative for the mapping. For service connectivity, link the device to separate A, AAAA, or PTR data instead of expecting EUI64 to perform resolution.

Troubleshooting

Validate the eight hyphen-separated fields before investigating the resolver. Compare the record with the inventory source and confirm that the query reaches the intended private authoritative server. Check TTL and update logs when the identifier appears stale, then inspect the separate address mapping. If a consumer treats an EUI64 as an IPv6 address, fix that integration rather than changing the DNS record. If the value leaked into public DNS, remove it, restrict the zone, and review exposure because stable identifiers can persist in caches and logs.

dig sensor.example EUI64 +noall +answer

# Query the private authoritative service directly.
dig @ns1.example.net sensor.example EUI64 +norecurse +noall +answer

The defining RFC

EUI64 is defined by RFC 7043, section 4, which specifies the eight-octet encoding and presentation format. The privacy and security guidance is in section 8. See the IANA DNS Parameters registry for the assigned type.

Reference and tooling

Every record type and its assigned numeric value is listed in theIANA DNS Parameters registry. To query a live zone from the browser, use theDNS lookup tool. If the record you are chasing is TLS-related, the TLS inspector andCertificate Transparency lookup are usually the next two stops.

Other record types