Blog
UDS

Tech Talk – Domain Extensions

Regulation of the future web via domain extensions classification will keep services in check .

If a social network curates its content to the point of becoming a publisher then the domain ext must reflect that change. Example from .social to .publisher or if a site is delivering spam/malware/viruses instead of legitimate content then its domain extension should reflect this and be altered to .spam.

Domain extensions should act as a form of strong categorization.

This form of domain law brings a new order to the #galaxy that is the Wild Wild West aka the World Wide Web.

A #NewRepublic can’t exist while chaos remains unchecked and malicious activity is abound.

 

If a service is a store which sells electronic equipment like @Newegg an appropriate domain extensions would be .store. A site like @Apple could still operate under .company but a better option would also be .store for selling products. This design makes it so that purchasing multiple domain extensions for specific services offered by a single company is a logical choice. This is also better for security purposes, customers, and staff. Staff may login via .company while a customer may login to .store.

From a security standpoint I can now take more specific precautions for each domain extension as to reflect their intended purposes. Its main use case is to keep services categorized and working within the parameters that define that domain extension. A benefit of this is that it provides the Web as a whole with a quick way to control the flow of spam and malicious programs. At the same time this preserves your freedom of speech as the content is still accessible but under a more specific extension. None the less a mechanism for censoring illegal content exists to ensure the network can remain ethical and law abiding. If a service is caught intentionally delivering illegal content it may be fined and or blocked. If a service is found to be lawful and working within its domain extension’s parameters it may be listed as verified. This protects users & networks and brings a #NewOrder to the web.

Twitter thread – https://twitter.com/tommarchi/status/1176434601516044288

 

Want to know more about The Universal Domain System?

 

Universal Domain System

The Universal Domain System has 3 components being: Domain Registrar, Domain Information System, and Domain Certificates. The Domain Registrar provides services to register & manage domains. The Domain Registrar also provides the Domain Information System with real-time domain information. Any changes to a domain such as ownership, routing, or cryptography will automatically notify the DIS. Another important feature of the Domain Registrar is signing domain certificates.The Domain Information System hosts all domain certificates and serves them on request. Clients send requests to the DIS to retrieve a domains routing information and cryptographic details in order to establish a UDSP stream. The Domain Information System takes in a hostname and responds with the corresponding certificate.Domain certificates provide hostname routing and cryptographic details. Clients use a D.C. to establish a UDSP stream with a destination domain.

Domain Registrar

The Domain Registrar (DR) is used to buy a domain, register a domain, and manage domain certificates. The DR also signs the certificates associated with the hostname and provides upload access for the public certificates. The DR ensures that an Identity Certificate is provided and connected to the account which is used to purchase the domain with VIAT. The Domain Registrar is the management side of the Domain Information System. The DR provides the DIS with the certificates used to respond to incoming hostname information requests.

The DR functions much like a real-time solution like cloudflare. Owners can update certificate details in real-time and they can instantly be pushed to DIS servers around the globe. Any cryptographic updating or routing information changes can be done through the DR similar to how one would alter details on platforms like cloudflare.

Domain Information System

Domain Information System on the Sentivate Network encompasses similar functionality as DNS.

The Domain Information System (DIS) is responsible for returning domain-specific information from human-readable hostnames. The DIS encompasses the functionality of DNS on the Sentivate network. There are a few important differences between DIS & DNS. The DIS is encrypted by default via UDSP. The DIS also returns the domain’s certificates which include cryptographic details & routing information. By including the hostnames cryptography along with routing information, 0-RTT is possible without requiring the client to have visited the domain prior. This is a unique advantage over TLS 1.3 in that 0-RTT is available by default where as in TLS 1.3 one would need to of visited the site prior.Before clients connect to a website they must first query the DIS with a human-readable hostname. The DIS will then respond with the domain’s cryptographic details and routing information. The DIS can also return geocentric routing information allowing clients to take advantage of a host’s potentially geographically distributed global network. Clients can then quickly use the fastest route to the host’s servers in respect to their location. This feature abstracts geographical load-balancing allowing hosts to rely less on their own load-balancing infrastructure.

Domain Certificates

Domain Certificates are documents which hold the routing, cryptography, and additional details for the hostname. The routing information is the destination’s IP address. The cryptography is the Master and Ephemeral keypairs to validate and initiate a bi-directional UDSP connection to the origin server. Additional details such as the hostnames which are assigned to the document, cross-origin policy, 0-RTT support, Geo-location based IP, and others are available.

Read more about the Universal Domain System – https://sentivate.com/network/universal-domain-system/

Sentivate Network Whitepaper – https://github.com/sentivate/Sentivate-Network-White-Paper/blob/master/WhitePaper.md