What's a UUID?



I. Introduction

When working with DNSDB or Security Information Exchange (SIE) DNS-related channels, you may occasionally see domain name labels with a very distinctive "dash-separated pattern" such as the following:


That is, the bolded portion of each of those names all follow the pattern:

  • Eight hexadecimal digits followed by a dash
  • Four hexadecimal digits followed by a dash (repeated two additional times)
  • Twelve hexadecimal digits

These names are almost certainly "Universally Unique Identifiers," or "UUIDs".

There are RFC4122 and non-RFC4122 UUIDs. The four main types of RFC4122 UUIDs are:

  • Type 1 UUIDs (a value derived from the host's hardware address and the current time)

  • Type 3 UUIDs (an MD5-hashed version of a namespace identifier and a corresponding namestring (such as a domain name or URL or ISO OID or X.500 DN))

  • Type 4 UUIDs (essentially a pseudo-random value), and

  • Type 5 UUIDs (a SHA1-hashed version of a namespace identifier and a corresponding namestring (such as a domain name or URL or OID or X.500 DN)).

II. RFC4122 Type 4 UUIDs

Let's experiment a little with some UUIDs using Python3's uuid library.

We'll begin by starting an interactive Python3 shell, and importing the Python uuid library:

$ python3
>>> import uuid

We can then try creating some RFC4122-format UUIDs. For example, if you ever need a unique random identifier (perhaps to use as a transaction identifier or as part of a temporary filename), RFC4122 Type 4 UUIDs may be just the ticket. Each Type 4 UUID you create will be unique:

>>> uuid.uuid4()

>>> uuid.uuid4()

>>> uuid.uuid4()

As we will later see in actual traffic, RFC4122 Type 4 UUIDs tend to be the most commonly seen.

III. RFC4122 Type 1 UUIDs

Let's now look at a type of UUID that's a little more complex, the RFC4122 Type 1 UUID. We'll get a Type 1 UUID and assign it to a variable called myuuid (bolding added in the following output by me):

>>> myuuid=uuid.uuid1()
>>> myuuid

If we "re-request" that Type 1 UUID, we can see that the last (bolded) field of the Type 1 UUID doesn't change:

>>> myuuid=uuid.uuid1()
>>> myuuid

If we compare the last field of that UUID to the system's hardware Ethernet ("MAC") address, retrieved using

$ ifconfig -a


$ ip a 

we can see the last part of the Type 1 UUID is set to the default interface's hardware address (albeit without the colon formatting that's normally part of a hardware Ethernet address):

link/ether a0:36:9f:71:07:41

If we wanted to, we could programmatically verify that the Type 1 UUID is an RFC4122 Type 1 UUID (and get the host's Ethernet MAC address) by saying:

>>> myuuid.variant
'specified in RFC 4122'
>>> myuuid.version
>>> hex(myuuid.fields[5])

The above confirms that the (last part of a) Type 1 UUID has the potential to act as a persistent host identifier (although beware of the impact of things like Ethernet adapter replacement).

IV. RFC4122 Type 3 and RFC4122 Type 5 UUIDs

Now let's consider the RFC4122 Type 3 (MD5) and Type 5 (SHA-1) UUIDs. These are hashed values produced from a namespace identifier and a corresponding namestring (such as a domain name, URL, ISO OID, or X.500 DN). The two hashing functions (MD5 vs SHA1) yield different values, but the principle's the same.

Note that neither MD5 nor SHA-1 are considered particularly cryptographically robust against well-funded opponents these days, but both are pragmatically adequate for the purposes for which most UUIDs get used.

Let's create a Type 5 (SHA-1) UUIDs as an example. Part of making a Type 5 UUID is specifying a namespace (the namespace declares the type of namestring being processed). In the notation of the Python UUID library we're using, those name spaces are defined as:

uuid.NAMESPACE_DNS	         Domain name
uuid.NAMESPACE_URL	    	 Web URL
uuid.NAMESPACE_X500  	 	 X500 Distinguished Name (DN)

For example, to build a Type 5 UUID (SHA-1) for the domain name www.farsightsecurity.com, we'd say:

 uuid.uuid5(uuid.NAMESPACE_DNS, 'www.farsightsecurity.com')

If we re-run that Type 5 UUID call for www.farsightsecurity.com, note that we get the same UUID result:

 uuid.uuid5(uuid.NAMESPACE_DNS, 'www.farsightsecurity.com')

A natural question when thinking about a Type 5 UUID is, "Can I 'decode' a UUID in order to extract the domain name that was used to construct that UUID?" The answer is that no, you can't, at least not algorithmically.

However, data-driven approaches should also be considered. Remember that if you re-run a Type 5 UUID, it will yield the same result every time it is run with the same input. Thus, conceptually, you could build a "dictionary" mapping billions of known namestrings to their corresponding Type 5 UUIDs, and then use that table of "precomputed" Type 5 UUIDs to "lookup" the corresponding "encoded" namestring.

For that reason, please be careful when it comes to assuming that Type 5 UUIDs are "strictly one way" or are "absolutely non-reversible" – that may not always be true, particularly if the set of potential namestrings is known and finite.

V. UUIDs in Security Information Exchange (SIE) Channels

Farsight SIE channels are used to share near-real time security traffic, including DNS traffic. For example, SIE Channel 204 contains "Data from Farsight’s global sensor array that has been deduplicated, filtered and verified." (A list of available channels can be found here.

We pulled ten million Channel 204 records from a leased SIE blade server using nmsgtool, saving just the RRnames that have the appropriate pattern.

This took less than ten minutes, and yielded 14,348 records (0.143% of the total observations we pulled):

$ time nmsgtool -C ch204 -c 10000000 -J - | jq -r '.message.rrname' | \
egrep '[0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{12}' > \
real	9m21.825s
user	6m7.292s
sys	0m37.948s

$ wc -l uuid-pattern-rrnames.txt 
12351 uuid-pattern-rrnames.txt

We then visually confirmed that those names were of the expected UUID-containing pattern:

$ more uuid-pattern-rrnames.txt

Top effective 2nd-level domains that were seen in 50 or more RRnames looked like:

$ 2nd-level-dom < uuid-pattern-rrnames.txt | sort | uniq -c | sort -nr
   6141 fastly-insights.com
   1088 bugfender.net
    401 permutive.app
    348 aadrm.com
    303 wix-code.com
    272 verkada-lan.com
    231 mts.ru
    168 seondnsresolve.com
    158 elliq.co
    153 filesusr.com
    139 msappproxy.net
    135 azure.com
    124 mysimplestore.com
     99 godaddy.com
     91 lever.co
     88 rlets.com
     85 thirdptop.com
     85 cloudflareresolve.com
     79 pipedrive.email
     60 petzila.com
     53 brightspace.com

There were at least few comment-worthy things to note:

  • 451 domain names from remotewd.com had UUID-format names. Given that, you might wonder why remotewd.com does not appear in the list of top-effective 2nd-level domains show above. To understand that behavior, note that remotewd.com appears in the PSL (Public Suffix List) and thus is an effective top-level domain in its own right. This means that those 451 remotewd.com domains are all tallied separately rather than being aggregated into a single effective 2nd-level-domain large enough to get listed in the top table.

  • Some UUIDs had been "customized" or "encapsulated" by having text pre- or post-pended to the UUID. For example, we saw unusual-looking domains that looked like the following:


All of the domains of this sort that we checked in DNSDB appear to point at

What do we see if we dig into the UUIDs themselves? Are they all of a particular type, for example?

We'll extract just the the apparent UUIDs from the file by saying:

$ grep -oP '([0-9a-f]{8}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{4}\-[0-9a-f]{12})' \
uuid-pattern-rrnames.txt > just-uuids.txt

We'll then check the status of each of those UUID with a little Python3 script:

import sys
import uuid


myvariant2=myvariant.replace("specified in RFC 4122","4122")



For example:

$ ./checkit.py 3ee99252-8700-414d-a1ef-e3d4e77a63f3
3ee99252-8700-414d-a1ef-e3d4e77a63f3 , 4122 , 4

Considering all 12,351 UUIDs in our sample, 12,292 (99.5% of our sample) were RFC4122 Type 4 "random" UUIDs (the remaining 0.5% consisted of sundry other UUID type). Clearly "random" UUIDs dominate the UUID usage we observed.

VI. Conclusion

We hope you've found this little introduction to UUIDs to be of some interest.

We encourage you to explore all the interesting and unusual phenomena waiting to be discovered in Farsight's Security Information Exchange and DNSDB!

Joe St Sauver, Ph.D. is a Distinguished Scientist and Director of Research for Farsight Security, Inc..