DK Hostmaster-transforms

In this section we detail how the transforms interacting with DK Hostmaster are designed and implemented.

DK Hostmaster has the full registry of all registrars, owners and nameservers of .dk-domains with name, address and contact information for the two former. All this data are referenced by a “handle”, which is the unique descriptor of the accounts. One entity can have several handles/accounts, but a handle can only point to one entity. The handles can be either personal, private companies, public organizations or an association; the transform shall be able to return data on all of these.

DK Hostmaster’s API offers look-ups for domains, handles and nameservers. The API also lists a method fordomain lists, but currently (July 2017) this entry is unfinished in the documentation.

All three methods are relevant to code transforms for, as they fulfill the requirement of being useful to a wide audience. As the look-up of nameservers are also contained within regular domains, only two are needed.

For both transforms, we assert that the resultset from DK Hostmaster is following the documen-tation, that is it only returns a HTTP 200-message if the resultset is correct. Thus we only have to handle errors on the input.

4.1.2.1 Domain-transform

As input for this transform, we can rely on the pre-existing entitymaltego.Domain and return an error, if the domain is not a.dk TLD. A researcher will be very likely to use this entity if he wants to investigate a domain.

The output from the API is extensive. The method returns full information on the domain’s admin and the registrant (including handle), creation and expiration date and nameservers

5Confirmed through extensive e-mail communication with their support.

(including handle)⁶.

From the results returned by the API, we determine that the relevant information to return to the user is:

• Administrator & registrant (name, contact info, address, handle, account type)

• Expiration date (“paid until-date”)

• Nameserver(s)

• Nameserver(s) contact (handle)

The only excluded information is the use of DNSSEC and the creation date, which is less relevant to know, but could easily be implemented. Not all information is present on all domains, which has to be taken into account when coding.

The above information can be contained in the following entities, of which only three are custom, but all inherits from standard entities. They are named in an identifiable manner as required by [44].

For all returned entities, we mark the origin of the data in them (domain, handle, role) appropri-ately with the addDisplayInformation-method for easy reference. If two entities are identical, the display information is also joined, so it is still evident that it originates from two origins.

thesis.dkhostmaster.handle Inheriting frommaltego.Phrasethis entity contains the handle of administrator, registrant or nameserver contact as main property and handle and account type (if found present).

thesis.location An address; inheriting frommaltego.Locationwith appropriately added fields for what DK Hostmaster returns (zip code, street address line 2 and 3 and a “attention”-field). The displayed property is the address, zip and city of the handle, but the main property is the city and country (due to an error in Maltego explained below).

thesis.expiry A date⁷ showing when the domain expires; inheriting from maltego.Phrase. maltego.PhoneNumber To display landline/fax numbers (if present).

maltego.PhoneNumberMobile To display mobile phone number (if present).

maltego.DNSName Contains the hostname of the nameserver(s).

maltego.Person From determining the account type (if it is Personal), we can decide on returning the name of the admin/registrant as a separate entity to enable further search of the individual associated with the account.

6Seehttps://github.com/DK-Hostmaster/whois-rest-service-specification#domain

7Surprisingly not an entity existing in Maltego!

As all three custom entities inherits from existing entities, we avoid “dead-ends”. The handle-entity can even be used as input to the handle-transform. We only create the strictly necessary entities as [44] endorses, but we still extract all useful information from the resultset and present it appropriately.

We note that the naming of the custom entities are in line with the requirements of the Maltego guidelines.

As the main property is used to run further transforms on an entity, we put the primary important information here. Only the two first entities have several properties, were the main property has to be selected appropriately to ensure further search.

The only entity where design could have been done differently is thesis.location, where a Maltego bug meant we were forced to use a concatenation of city and country as the main property. This is not optimal for either future search or distinguishing entities.

In Danish context we would normally use the street address, the zip code and the city to uniquely identify an address meaning we would put that into the main property.

However in maltego.LocationPaterva overwrites the main property with the contents of the city- and country-property, which developers cannot change. Alas, when using a custom entity, we only have the option to choose either the same main property the parent entity has or properties of the custom entity, so we have to create a property only for the display purposes; in this we can concatenate street address, zip and city as desired.

This was one of the major problems found during development; it is explained further in Section 5.1⁸.

We could also have chosen to use the name associated with the handle as display value. It does not make a big difference as all data are still present in separate properties for the researcher to extract himself, but the street, zip and city conveys more information at a glance than the name only.

4.1.2.2 Handle-transform

Input for this transform can be done either with a generic entity like maltego.Phrase or a custom entity. The guidelines dictates not to create too many custom entities, but the handles are used a primary identifier by DK Hostmaster and as output from the domain-transform, so it does make sense to use as input. We return an error if the handle does not exist.

The method returns all information on a given handle⁹, but not a list of domains it administers (the methoddomain listshould perform this, but its entry is unfinished).

It would be nice to instead add information to the input-entity, but Maltego does not make that possible.

The relevant information to return to the user from this API-method is:

8See also an excerpt from the e-mail conversation in App. A.2.1.

9See

• Handle name, contact info, address, account type

We contain this information in the following entities, where only one is custom (and inherits from a Maltego entity):

thesis.location As for the domain-transform, contains address of the handle. The displayed property is the address, zip and city of the handle, the main property is the city and country (as explained above).

maltego.PhoneNumber To display landline/fax numbers (if present).

maltego.PhoneNumberMobile To display mobile phone number (if present).

maltego.Person The name of the admin/registrant (only if the account type isPersonal).

maltego.Phrase The type of the account behind the handle (if not a Personal).

The only difference from the entities of the domain-transform is that we add the account type as a separate entity. For a personal account, we add can add the name of the account as a person, which it enables a whole other group of transforms to be used to search for individuals. If the account is not personal, we just note this in a phrase-entity, because it is an important piece of information, but it does not belong in any of the other entities or as a custom entity.