Uniformity across domain name breakdown fields

[ebeahan]

Summary

The following 3 domain name breakdown fields should be consistently presently where necessary:

• registered_domain (mydomain.co.uk)
• top_level_domain (co.uk)
• subdomain (www)

This PR addresses the current inconsistencies:

Fieldset	registered_domain	top_level_domain	subdomain
source	✅	✅	❌
destination	✅	✅	❌
client	✅	✅	❌
server	✅	✅	❌
url	✅	✅	❌
dns	✅	✅	✅

[ebeahan]

@dainperkins @webmat this is intended to address the domain name inconsistency portion of #797

[dainperkins]

@ebeahan I think @webmat wanted to pull the host portion out for a separate review.

Checking thru the csv some of the examples are still half completed (I think that was the last update I actually pushed)

I based the fields from the current DNS convention and applied to source, destination, client, server, url

Field	Example
x.name	www.east.mydomain.co.uk**
x.registered_domain	mydomain.co.uk
x.subdomain	www.east* or east*
x.top_level_domain	co.uk
x.host	www *

4 Items I think we should give some thought to:

1. *While I can only think of 1 internal dns tracking use case that would really make use of this (large, distributed organization) I think there should be a field to split out the hostname portion of the domain, as in the case above the www is the host portion **. Theres definitely some complexities to normalizing these but its correct, and has at least 1 use...

2. **client/server.name is already there so we would likely need to specify "name" is the fqdn (with some guidance potentially for understanding e.g. pqdn and default domain suffix's...) or consider if "name" would be best replaced with fqdn, which would involve breaking changes eventually to dns.question, but could be handled, particularly if "name" is maintained and just guidance for use is modified

3. guidance that filling out dns domain information would typically only be done for those events which actually reference DNS resolutions (protocol connection TO a fqdn, logs/connections with source dns info (client cert, smtp functions that require names/certs match mx records, and federated sip invites come to mind as possibilities)

4. a CNAME lookup effectively has a built in recursive lookup (if looking for an A record) which should be normalized, either as an intrinsic question & response, or normalized as above (dns.answers.name/tld/sub/registered, etc)

DNS Response frame from nslookup www.spotify.com:

Queries

  www.spotify.com: type A, class IN
Answers
    www.spotify.com: type CNAME, class IN, cname edge-web-split-geo.dual-gslb.spotify.com
        Name: www.spotify.com
        Type: CNAME (Canonical NAME for an alias) (5)
        Class: IN (0x0001)
        Time to live: 236 (3 minutes, 56 seconds)
        Data length: 31
        CNAME: **edge-web-split-geo.dual-gslb.spotify.com**
    edge-web-split-geo.dual-gslb.spotify.com: type A, class IN, addr 35.186.224.25
        Name: edge-web-split-geo.dual-gslb.spotify.com
        Type: A (Host Address) (1)
        Class: IN (0x0001)
        Time to live: 119 (1 minute, 59 seconds)
        Data length: 4
        Address: 35.186.224.25

[ebeahan]

@ebeahan I think @webmat wanted to pull the host portion out for a separate review.

Synced with @webmat and he concurred. Removed the host field sets from this change.

[webmat]

client/server.name is already there

But client/server.name are not already in ECS 🙂 That's the work we'll need to do, when adding host/fqdn or perhaps name fields. This should be done separately.

This PR is simply meant to add the missing .subdomain fields where we had the other domain name breakdown fields, but where .subdomain was still missing.

[webmat]

LGTM other than the changelog adjustment

[webmat]

LGTM