Monthly Archives: January 2019

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Best regards,
Michael Herman (Toronto/Calgary/Seattle)

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Companion Articles

• Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM)
• End-to-end Path from id (DID) to a Real-Life Something

DID Data Model

Figure 1. Simplest DID Data Model

Narration

1. [Informative] A DID Entity is a data structure comprised of a collection of key-value pairs with keys such as: id (DID), service (endpoints), authentication, publicKey, @context, etc.
2. A DID Document is a JSON-LD serialization of a DID Entity.
3. A DID Document has a set of attributes such as the following:
   • id (DID)
   • service (endpoints)
   • authentication
   • publicKey
   • @context
   • etc.
4. The id (DID) attribute is the unique identifier or key for the DID Document.
   • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
   • id (DID) are used to index, find, and retrieve DID Documents from the Technology Layer. id (DID) exists as an attribute of a DID Entity (and by implication, as an attribute of DID Document, the JSON-LD serialization of the corresponding DID Entity).
5. When DID Documents, in turn, are serialized to the Indy Ledger by Indy Ledger Nodes, they are stored as a series of Indy Ledger Transactions.
6. Edge Agents and Cloud Agents call an Indy Ledger Node to persist a DID Document to the Indy Ledger. DID Documents, specifically, are written to the Indy Ledger by the Indy Ledger Nodes using Indy NYM and Indy ATTRIB transactions.

IMPORTANT: Don’t read this version of this article about the “DID” ARM.  It’s incorrectly named – this article remains as a tombstone for the many places where this URL has been posted.  Please read: Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (ARM). (click here).

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Overview

The purpose of the DID Comprehensive Architecture Reference Model (DID ARM) is provide a complete, reliable, precise, visual reference for the concepts presented in the draft Decentralized Identifiers (DIDs) specification (link). The primary audience for this article are: software people (software architects and developers), enterprise architects, and anyone new to the Hyperledger Indy project or the field of self-sovereign identity (SSI) looking to find a fast on-ramp.

The goals of the DID ARM are:

1. Create a reliable, precise, comprehensive, visual model depicting Decentralized Identifiers (DIDs), DID Entities, DID Documents, and the companion Hyperledger Indy ecosystem of software projects, software components, and data elements.
2. Enable software people to become more knowledge about and productive with the Hyperledger Indy software platform (and Sovrin governance framework) as quickly and as easily as possible.
3. Provide a common language of discourse for describing the current state architecture as well as potential future state architectures for the DID ecosystem and community (with particular focus emphasis on the needs and requirements of software people).

The guiding principles for the DID ARM are:

• Provide reliable documentation: timely, accurate, visual, and complete
• Save as much of a software person’s time as possible
• Leverage open source modeling specifications and tools like ArchiMate and Archi, respectively
• Leverage enterprise architecture concepts to explain Decentralized Identifiers and Entities in a way doesn’t detract from the adoption of the DID ARM

The drivers for the DID ARM are:

• The initial driver for the DID ARM is the create a reference model to help correct a series of issues found in the draft DID specification and documented in the project’s GitHub issues list (Fall 2018).

NOTE: Some of the elements depicted in the DID ARM have been influenced by the Verified Credentials project – particularly, the business roles and processes in the Business architecture layer (1) and the Credential Registry Agent Node (39) in the Technology architecture layer (30).

Companion Articles and Other Resources

• Vision: Trusted Digital Web
• In Practice: End-to-end Path from id (DID) to a Real-Life Something
• Modeling Specification: The Open Group ArchiMate 3.0 Specification
• Modeling Tool: Archi, the open source ArchiMate modeling platform

DID ARM Version 0.8

Horizontally, the DID ARM is partitioned into 4 perspectives:

• Projects and Distributions (A)
• Software Architecture (B)
• Data Model (C)
• Principles (D)

Vertically, the DID ARM is divided into 3 architecture domains that span the 4 perspectives:

• Business architecture (1) and (8)
• Applications architecture (23) and (12)
• Technology architecture (30) and (15)

The DID ARM is illustrated in the following “all in” view/projection of the DID reference model. The ARM is an actual queryable model – it is not a drawing (e.g. a Visio diagram).

The Narration section that follows the graphic includes a description of each of the numbered bullets.

Click on the graphic to enlarge it in a separate browser tab.  Suggestion: Drag the new browser tab onto a second monitor if you have one.

Figure 0.8: DID Comprehensive Architecture Reference Model (ARM) v0.8

NOTE: Physically, the DID ARM is approximately 60 cm x 50 cm in size – but it is quite readable when printed on a regular sized paper – with glasses.

Narration

1. Business Layer of the DID ARM. “The Business Layer depicts business services offered to customers, which are realized in the organization by business processes performed by business actors.” [ARCHIMATE]
   • The following Actor Roles are depicted in this version of the ARM: Issuer, Holder (x 2), Inspector, and Verifier. These roles are not formally defined in the draft DID specification; for the time being, they have been borrowed from the documentation related to the Verified Credentials project.
2. An Issuer causes a self-sovereign identity for a Something for be Issued; e.g. a Purchase Order (3). In this example, the SSI is for a Thing (10); in particular, a completed and approved Purchase Order (3). The Purchase Order is issued to a Holder. Both the Issuer and the Holder work for a fictitious company called Acme Corporation.
3. SSI for a Something (a Purchase Order) issued by the Issuer @ Acme (2).
4. The Holder @ Acme accepts the SSI for the Thing (a Purchase Order) from the Issuer (2). In turn, the Holder @ Acme presents the SSI for the Purchase Order to a Holder at Baker Limited. The Holder @ Baker receives the SSI for the Purchase Order from the Holder @ Acme (4).
5.  An Inspector @ Baker may request that the Holder @ Baker present the SSI for the Purchase Order to him/her/it. The Inspector @ Baker receives the SSI from the Holder @ Baker.
6. The Inspector @ Baker (or any Holder) can ask for the SSI for the Purchase Order to be verified by a Verifier.
7. There is a set of Business Services (e.g, Issue, Store, Request, Verify, Register, etc.) that support the above processes.  These Business Services are supported by services exposed by the Applications Architecture Layer (23).
8. Business Layer – Data Model captures the key business-level model elements such as Actor (9), Things (10), and Business Processes (37).
9. An Actor is “a business entity that is capable of performing behavior.” [ARCHIMATE]
   • Examples of Actors include Persons, Organizations, and Software Agents.
10. A Thing is inanimate entity. Things and Actors are mutually exclusive (P3). A Thing has an Owner (P2). An Owner is an Actor (P2).
    • Examples of Things include Pets, Cars, Houses, Business Documents, Products, Assemblies, and Parts.
    • The software component of a Software Agent is a Thing. If you’re talking about Software Agent as a business entity capable of performing behavior, then the Software Agent, in this context, is an Actor.
    • A slice of a particular kind of Toast is not a Thing because it is fungible. A slice of Toast can be a Thing in the future when each slice of bread has its own bar code or serial number. A photo of a slice of Toast is a Thing because it is non-fungible (most photographs are non-fungible and hence, are Things).
    • A living cell (skin cell, blood cell, etc.) would not be considered an Actor (or a Thing). It is not a business entity nor a Non-Fungible Entity (within a single body of DNA) ..at least, not for the foreseeable future.
11. Business Processes. Actors (Persons, Organizations, and Software Agents) participate in Processes. A Process acts on/accesses Things (e.g. a Pet, Car, House, Business Document, Product, Assembly, Part) to perform work.
12. Application Layer – Data Model captures the key application-level model elements such as id (DID) (12) and DID Entity (13).
13. id (DID) exists as an attribute of a DID Entity (13) (and by implication, as an attribute of DID Document (15), the JSON-LD serialization of the corresponding DID Entity).
    • The id (DID) attribute is given the nickname “DID” (aka Decentralized Identifier) for convenience; but more importantly, to clarify what a DID specifically refers to (as well as to clarify what the term DID specifically does not refer to). “DID” should only be used to refer to the id (DID) attribute of a DID Entity (or DID Document).
    • id (DID) are used to index, find, and retrieve DID Documents from the Technology Architecture layer (28/14).
14. A DID Entity is the in-memory, application-specific object that represents a de-serialized DID Document (15). (P4)
    • DID Entities have a set of attributes such as the following:
      • id (DID)
      • service (endpoints)
      • authentication
      • publicKey
      • @context
      • etc.
15. Technology Layer – Data Model captures the key technology-level model elements such as a DID Document (15).
16. A DID Document is a JSON-LD serialization of a DID Entity.
    • The id (DID) attribute is the unique identifier or key for the DID Document.
    • id (DID), aka a DID, is used to index, find, and retrieve a DID Document (also see (12)).
17. When DID Documents (16), in turn, are serialized to the Indy Ledger (36) by the Indy Ledger Nodes (37) and (17), they are stored as a series of Indy Ledger transactions. DID Documents, specifically, are written to the Indy Ledger by the Node Agent Nodes (36) and (37) using Indy NYM and Indy ATTRIB transactions.
18. Technology Layer – Projects and Distributions highlights the Hyperledger (and potentially other) open source projects that design, build, and supply software components to both the Applications and Technology Architecture Layer.
19. The Hyperledger Indy-SDK project includes two key software components used to implement an Indy Wallet (25) and (32):
    • libIndy (lower-level)
    • libVCX (higher-level)
20. The Hyperledger Indy-Agent project is used to implement the Indy Agent functionality in the:
    • Edge Agent App (24)
    • Edge Agent Web App (28)
    • Edge Agent Lightweight App (29)
    • Cloud Agent Node (31)
    • Ledger Agent Node (35), and
    • Credential Registry Agent Mode (39)
21. The Hyperledger URSA project is a utility that provides implementations of the cryptographic functionality required across all of the Hyperledger projects.
22. The Hyperledger Indy-Node project is used to implement the Indy Node functionality in the: Ledger Agent Node (35).
23. Applications Layer of the DID ARM. “The Application Layer depicts application services that support the business, and the applications that realize them.” [ARCHIMATE]
24. The Edge Agent App 1 is an end-user application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). This is typically a mobile or a desktop app.
25. The Edge Wallet is a mobile or desktop application component that supports the Edge Agent App’s requirements (24) for managing actual self-sovereign identities it owns.
26. Edge Agent App 2 is an example of another Edge Agent App in the ecosystem. Communication between Edge Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (27).
27. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
28. The Edge Agent Web App is an Edge Agent implemented as a server-hosted web application.
29. The Edge Agent Lightweight App (EAPA) is a mobile or desktop application that doesn’t use a local Edge Wallet. Instead, the EAPA relies on the services of a Cloud Agent and Cloud Wallet.
30. Technology Layer of the DID ARM. “The Technology Layer depicts technology services such as processing, storage, and communication services needed to run the applications, and the computer and communication hardware and system software that realize those services.” [ARCHIMATE]
31. The Could Agent App 1 is a cloud or server-based application for interacting with the self-sovereign identities an Actor owns: personal, organizational, as an Owner of Thing, or as a Guardian of another Actor (9) and (10). The Cloud Agent App is an alternative to using an Edge Agent App (24) and Edge Agent Wallet (25).
32. The Cloud Wallet is a cloud or server-based technology component that supports the Cloud Agent App’s requirements (31) for managing actual self-sovereign identities it owns.
33. Cloud Agent App 2 is an example of another Cloud Agent App in the ecosystem. Communication between Cloud Agent Apps takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (34).
34. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
35. Ledge Agent Nodes support the requirements of Edge Agent (24) and Cloud Agent (31) applications for persisting, managing, and interacting with DID Documents (16) persisted to the Indy Ledger (36) and (17).
36. The Indy Ledger is the distributed ledger technology that supports the persistence, management of DID Documents (16) persisted to the Indy Ledger as Indy NYM and ATTRIB transactions (17).
37. Ledge Agent Node 2 is an example of another Ledge Agent Node in the ecosystem. Communication between Ledge Agent Nodes takes place using the Indy Agent-to-Agent Protocol (A2A Protocol) (38).
38. The Indy Agent-to-Agent Protocol (A2A Protocol) is the protocol used for communication between Edge Agent Apps (24) and (26), Cloud Agent Nodes (31 and 33), and Ledger Agent Nodes (35) and (37).
39. Credential Registry Agent Node is a repository for persisting, managing, and interacting with Verified Credentials. It’s implementation is based on technologies similar to those used to implement Cloud Edge Agents.
40. DID Resolver Node is a key component that is used by Edge Agent (24) and Cloud Agent (31) applications to resolve a id (DID) (13) into a specific DID Document (16) (assuming the DID Document has been persisted to the Indy Ledger (36) and (17)).

Best regards,

Michael Herman (Toronto/Calgary/Seattle)

IMPORTANT: Don’t read this version of this article.  The official (draft) has moved to github: click here INDY-ARM: Appendix E – DID Resolution: Path from a DID to a Real-life Something

Michael Herman (Toronto/Calgary/Seattle)
Hyperonomy Business Blockchain Project / Parallelspace Corporation
January 2019

Draft document for discussion purposes.
Update cycle: As required – sometimes several times in a single day.

Companion Articles

• What is a DID?
• Hyperledger Indy/Sovrin Comprehensive Architecture Reference Model (INDY ARM)

DID End-to-end Path Version 0.3

The following graphic illustrates the path (flow) of a client app trying to: a) communicate/interact with, and/or b) access the metadata about a real-life something by using a Decentralized Identifier (id (DID)).

That is, in (almost) 10 steps or less, how to you get from an id (DID) attribute on the left to a Real-Life Something on the right?

2019-01-08 NOTE: The ultimate goal is to synthesize a simple(r) data model – not a more complex one.  However, the interim analysis phase (tearing things apart) is expectedly going to result in a data model that is visually more complex. From this analysis model, we can hopefully synthesize a data model that is simple(r).

NOTE: Click on the graphic to enlarge it.

Figure 0.3. DID End-to-end Path v0.3

Narration

• 0.  A DID Document contains an id (DID) attribute which is the unique identifier or key for a DID Document.
  • A Real-Life Something can be associated with more than one DID Document (and by implication, more than one id (DID)).
  • A DID Document (and its id (DID)) can only refer to one Real-Life Something.

1. Client App (or Service) is interested in either:
   • Communicating or interacting with a Real-Life Something.
   • Gaining knowledge about a Real-Life Something. (Let’s refer this knowledge as Metadata about the Real-Life Something.)
   • NOTE: A Real-Life Something can be either a Real-Life Actor or a Real-Life Thing.
2. Client App calls DID Resolver to retrieve the DID Document that corresponds to a particular id (DID).
3. DID Resolver uses the id (DID) as a key (unique identifier) to retrieve the corresponding DID Document from a DID Document Repository (14).
4. DID Resolver, in turn, returns the DID Document to the Client App.
5. The DID Document contains a service (endpoint) attribute that points to the Software Service Endpoint for the entity where:
   • Client App can communicate or interact with a particular Virtual (Real-Life) Something (primary use case).
   • Client App can retrieve additional information about a particular Real-Life Something (aka Metadata about the Virtual (Real-Life) Something) (secondary use case and, potentially, a sub-case of the primary use case).
6. Client App calls Software Service Endpoint to either: a) communicate/interact with, or (b) retrieve metadata about a Virtual (Real-Life) Something.
7. [Primary Use Case] Software Service Endpoint enables Client App to communicate or interact with a particular Virtual (Real-Life) Something.
8. Virtual Actor is a Virtual (Real-Life) Something that is associated with a Real-Life Actor (9).
9. Real-Life Actor is a Real-Life Something that is associated with a Virtual (Real-Life) Actor (8).
10. Virtual Thing is a Virtual (Real-Life) Something that is associated with a Real-Life Thing (11). A Virtual Thing has an Owner. The Owner of a Virtual Thing is a Virtual Actor.
11. Real-Life Thing is a Real-Life Something that is associated with a Virtual (Real-Life) Thing (10). A Real-Life Thing has an Owner. The Owner of a Real-Life Thing is a Real-Life Actor.
12. [Secondary Use Case] Client App retrieves Metadata Document about Virtual (Real-Life) Something from the Metadata Document Repository (15) by calling Software Service Endpoint. As in the primary use case, the Virtual (Real-Life) Something can be a Virtual Actor or a Virtual Thing.
13. Software Service Endpoint returns the Metadata Document for the particular Virtual (Real-Life) Something to the Client App; that is, the knowledge about the Virtual (Real-Life) Something that the Client App was originally interested in Step 1.
14. DID Document Repository is a repository of DID Documents indexed by each document’s id (DID).
15. Metadata Document Repository is a repository of Metadata Documents.

Additional Notes

1. An Actor is simply defined as being different from a Thing because an Actor is “a business entity that is capable of performing behavior” [ARCHIMATE].
2. A Thing has an Owner.
3. The Owner of a Thing is an Actor.

Questions

Please click here to provide an answer to any of the following questions or use the Indy-Semantics Rocketchat channel.

Please reference this URL in your answers: https://hyperonomy.com/2019/01/04/the-path-from-a-id-did-to-a-real-life-something/

1. Can the data from the Metadata Document (6) be merged into/placed inside the DID Document (0)?  If so how?
   • Daniel Hardman (2019-01-07): A DID Document can contain additional sections besides those required by the spec – but I am not aware of a way to describe those sections in an interoperable way. So adding extra metadata to the DID Document would require a new convention or standard to be described.
2. Related but separate from the first question, where does the Indy Schema effort/project artifacts (e.g. Schema Documents) fit into the above graphic?
   • Daniel Hardman (2019-01-07): “Schema” is currently used mostly to describe credentials. We could apply the concern more broadly (e.g., to A2A messages), but there is not a common understanding of anything broader.
3. Is there a third repository (Schema Document Repository) that needs to be added to the graphic? …or is schema stored as “just another” DID Document in the DID Document Repository?  If so, in the most likely scenario, is there a separate DID Document Repository that acts as a global Schema Document Repository.  Are Schema Documents resolved through the same DID Resolver (2)?
   • Daniel Hardman (2019-01-07): Schemas for credentials are stored on the ledger – not in DID Documents, but in separate SCHEMA transactions. A schema lookup is a ledger lookup, but not a DID Document lookup. Schemas are not indexed by DID, since they do not require an endpoint or key rotation construct–but rather by an identifier that helps the ledger walk its own state trie with maximum efficiency
4. Is the extended data for an entity stored in the original DID Document (0) (based on the Extensibility feature of a DID Dcoument) and can/does this feature explicitly rely on Schema?

Appendix A – Older Versions of the (draft) DID Data Model

Version 0.2

Figure 0.2. End-to-end DID Data Model v0.2

 

 

Thoughts to think about:

• What’s more important? …the name of something or the something?
• Under what conditions might the relative importance change?
• What is the difference between a name, an identifier (see below for a definition), and a label?

Here’s a few examples to ponder. The discussion follows at the end of this article.

Examples

Apple (A-p-p-l-e) and Apples

Name: apple (a-p-p-l-e)

 

 

Figure 1. Somethings: (a) real apple, (b) ceramic apple, (c) apple candle, and (d) a bad apple 😉

House Numbers and Houses

Name: A specific house number

 

 

Figure 2. Somethings: (a) house with a specific numeric house number, and (b) house with script house number with a specific value

Addresses and Houses

Name: A specific address

 

 

Figure 3. Somethings: (a) house with specific numbered street address, (b) property with a specific numbered street address, and (c) house specific numeric house number and a specific numbered street address

Domain Names and DNS Resource Records

This (and the following) example are important because they represent 2 completely different, independent databases indexed/keyed by the same name: an Internet domain name.

Name: Domain name microsoft.com

 

 

Figure 4. Somethings: DNS Resource Records for microsoft.com:
(top) single “A” record (default), (middle) all “A” records, and (bottom) all resource records

To learn more about DNS, read DNS (Domain Name Service): A Detailed, High-level Overview.

Domain Names and WHOIS Database Records

This (and the previous) example are important because they represent 2 completely different, independent databases indexed/keyed by the same name: an Internet domain name. Thank you goes to Daniel Hardman for suggesting this one.

Name: Domain name microsoft.com

Figure 5. Somethings: WHOIS Database Record for microsoft.com

Github Project Respository Names

Name: https://github.com/mwherman2000/indy-arm.git

Read Git repository internal format explained  for a detailed explanation of the structure of the .git folder that is created in the local file system when a GitHub project repository is cloned using, for example:

git clone https://github.com/mwherman2000/indy-arm.git

Several additional references (links) are also included in the article.

Figure 6. Somethings: GitHib Project Repository .git Local Folder

Discussion

TODO

Roles of a Name

• noun: a-p-p-l-e
• a partial identifier/address: a house number
• a more complete identifier/address: the address of a house
• a more complete identifier/address of a related entity: the address of a property that has house
• a unique identifier: a domain name (although domain names can be used to index completely different collections – e.g. DNS Resource Records and WHOIS Database Records)

TODO

What a name is, what it is interpreted to be, and what it actually is can be are completely different things.

Possession of a something vs. control of something aren’t necessarily the same thing.

TODO

What is an “identifier”?

Figure 6. Identifier: Definition

 

 

Copyright (c) 2019 Michael Herman (Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
https://creativecommons.org/licenses/by-sa/4.0/legalcode

How’s that for a confuding title?  In a recent email discussion, a colleague compared the Decentralized Identifier framework to DNS …suggesting they were similar.  I cautiously tended to agree but felt I had an overly simplistic understanding of DNS at a protocol level.  That email discussion led me to learn more about the deeper details of how DNS actually works – and hence, this article.

On the surface, most people understand DNS to be a service that you can pass a domain name to and have it resolved to an IP address (in the familiar nnn.ooo.ppp.qqq format).

domain name => nnn.ooo.ppp.qqq

Examples:

1. If you click on Google DNS Query for microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate domain name microsoft.com.
2. If you click on Google DNS Query for www.microsoft.com, you’ll get a list of IP addresses associated with the Microsoft’s corporate web site www.microsoft.com.

NOTE: The Google DNS Query page returns the DNS results in JSON format. This isn’t particular or specific to DNS. It’s just how the Google DNS Query page chooses to format and display the query results.

DNS is actually much more than a domain name to IP address mapping.  DNS is an extensible name resolution framework and set of protocols for performing lookups of any name mapping the name to a collection of any type of data – any collection of name-value pairs (aka a collection of claims). This (and the fact that DNS servers and protocols have been in every day use by billions of computers around the world for several decades) makes DNS exceedingly well suited for managing any type of credential data (collections of claims).

DNS Resource Records

There is more to the DNS Service database than these simple (default) IP addresses.  The DNS database stores and is able to return many different types of data (in addition to service-specific IP addresses) for a particular domain name.  These data records are called DNS Resource Records. Here’s a partial list of the most common resource record types from http://dns-record-viewer.online-domain-tools.com:

• Address Mapping records (A) – the default/common type (see the previous Examples)
• IP Version 6 Address records (AAAA) – newer version of the above
• Canonical Name records (CNAME)
• Mail exchanger record (MX) – mail server IP address
• Name Server records (NS) – authoritative DNS server for this domain
• Reverse-lookup Pointer records (PTR)
• Start of Authority records (SOA)
• Text records (TXT)

Most APIs only support the retrieval of one Resource Record type at a time (which may return multiple records (e.g. IP addresses) of that type). Some APIs default to returning A records; while some APIs will only return A records. Caveat emptor.

To see a complete set of DNS Resource Records for microsoft.com, click on DNSQuery.org query results for microsoft.com and scroll down to the bottom of the results page …to see the complete response (aka authoritative result). It will look something like this:

Figure 1. DNS Resource Records for microsoft.com: Authoritative Result

NOTE: The Resource Record type is listed in the fourth column: TXT, SOA, NS, MX, A, AAAA, etc.

UPDATE: The complete list of allowable value ranges for RR (resource record) types (QTYPEs) can be found here: IANA: Resource Record (RR) TYPEs.

DNS Protocol

The most interesting new information/learnings is about the DNS protocol itself.  It’s request/response …nothing new here.  It’s entirely binary …to be expected given its age and the state of technology at that time. Given how frequently DNS is used by every computer on the planet, the efficientcy of a binary protocol also makes sense. The IETF published the original specifications in RFC 882 and RFC 883 in November 1983.

The interesting part of the protocol is that a DNS client typically doesn’t “download” the entire authoritative set of DNS Resource Records all at once for a particular domain, the most common API approach is to request the list of relevant data (e.g. IP addresses) for a particular Resource Record type for a particular domain.

The format of a sample DNS request is illustrated in the following figure:

Figure 2. Sample DNS Request [CODEPROJECT]

It’s binary. The 16-bit QTYPE field (purple cells on the right side) defines the type of query. In this case 0x0F is a request for an MX record; hence, this is a request for the data that describes microsoft.com’s external email server interface.

NOTE: The fact that the QTYPE field is 16-bit implies that DNS is designed to support many more than the few dozen Resource Record types in current use.

NOTE: The “relevant data” isn’t always an IP address or a list of IP addresses. For example, response may include another domain name, subdomain name, or, in some cases, simply some unstructured text (as far as the DNS specification is concerned).

Here is a typical response for the above sample request:

Figure 3. Sample DNS Response [CODEPROJECT]

The response in turn is also binary. In this case, DNS has responded with 3 answers; that is, 3 subdomain names: mailc, maila, and mailb – each with a numerical preference (weight).

ANY Resource Record Type

There is also a “meta” Resource Record Type called ANY that, as you might guess, requests a collection of all of the different Resource Record type records for a specific domain.  This is illustrated in Figure 1 above.

DNS Extensibility

DNS is also a general-purpose, extensible framework and existing, accepted, deployed software platform and network for creating, managing, finding, and retrieving what are, in effect, Credentials associated with a Universal Digital Identifiers (DID) (aka hierarchical domain name). A credential in turn is a set of Claims where a claim is a name-value pair associated with the particular DID.  Here’s some examples.

Figure 4. Universal Digital Identifier Example: DNS Binary Protocol

Figure 5. Universal Digital Identifier Example: UDID Credential (DID Document)

Figure 6. Universal Digital Identifier Example: DNS over HTTP Response (Credential/DID Document)

For more information on how DNS can be extended to support products like the Trusted Digital Web, checkout Trusted Digital Web: Whitepaper.

Best regards,
Michael Herman (Toronto/Calgary/Seattle)