The EDJX Platform can serve as your content delivery network (CDN),
making the transmission of your content more efficient for your customers.

Before You Begin

Make sure you have noted your domain’s registrar before you use the EDJX platform to create records.

Issue the following command from a Linux terminal:

~ # whois
Domain Name: EDJX.IO
Registry Domain ID: D503300000212345678-LRMS
Registrar WHOIS Server:
Registrar URL:
Updated Date: 2020-09-15T06:39:21Z
Creation Date: 2018-10-15T02:10:12Z
Registry Expiry Date: 2021-10-15T02:10:12Z

This page consists of the following topics:

Domain Types

The EDJX platform supports the following domain types:

Full Domain

A fully qualified domain name (FQDN) where the user must write the records on the DNS provider to transfer the record to the EDJX platform.
create domain

CNAME Domain

A canonical name (CNAME) domain allows multiple records to be mapped from one hostname to another host or to a FQDN.
create domain cname
The CNAME domain type can only have A or AAAA records configured, and records with name @ are not allowed.

To create domains:

DNS Record Types

EDJX supports the following DNS record types per domain type:

Full Domain
  • Multiple A records are allowed per name.

  • AAAA and A records can exist together.

  • Multiple AAAA records are allowed per name.

  • AAAA and A records can exist together.

  • Only one CNAME record is allowed per name.

  • Co-existing with any other record is not permitted.

  • Recursive CNAMEs (pointing to oneself) are not permitted.

  • Multiple MX records are allowed per name.

  • Co-existing with NS records is not permitted.

  • Co-existing with A, AAAA, MX, or TXT records is not permitted.

  • By default, there are three NS records created when you add a Domain to the Platform.

  • Creation of NS record for root DNS record is not permitted.

  • Multiple TXT records are allowed per name.

  • Co-existing with NS records is not permitted.

CNAME Domain
  • Recursive CNAMEs (pointing to oneself) are not permitted.

  • Records are not allowed to have @ as the name.

  • A and AAAA records are allowed.

To create domains:

EDJX Proxy Server

The EDJX platform can be your proxy server for any or all of your domain records.

When you enable the EDJX platform to be your proxy server, EDJX IP addresses are returned instead of your original IP address.

When a record has proxy enabled, the EDJX platform:

  • Caches data, speeding up common requests

  • Stores HTTPS certificates on the EDJX servers

To set EDJX as your proxy server for a domain record:

Request Routing Rules

Request Routing Rules can be added to redirect or rewrite request to alternative servers.

To create rules:

Routing Match Types

Routing match types work as follows:

  • Exact Match — Matches each parameter within the MATCH VALUE text field.
    That is the scheme, host, and port of the HTTP request will be matched exactly when specified in the MATCH VALUE text field.
    The path and query parameters will have strict matching even if they are not explicitly specified.
    If path is not specified, it will be treated as an empty string or a backslash / value.
    Similarly, for query, if not specified, matching checks for empty parameters in the incoming request.

  • Pattern Match — Matches wildcards for host and path request parameters.
    For example : https://* or *
    For scheme and port parameters, the HTTP request will be matched exactly when specified in the MATCH VALUE text field.
    The host parameter will be matched against the wildcard host value. If the path and query parameters are not specified, no strict matching will be applied.
    The path parameter can contain the following options:

    • At the end, for a prefix match (/prefix/*)

    • At the beginning, for a suffix match (*.suffix)

    • On both sides, for a substring match (*/contains/ *)

    • In the middle, for a globular match (/accounts/*/info)

Routing Action Values

The EDJX platform supports the following routing actions:

  • Redirect Rule — The EDJX Server sends a 302 temporary redirect response with the Location header in the response.

  • Rewrite Rule — You may want to use this Rule Action for the following reasons:

    • One or more path or query parameter is rewritten.
      The EDJX Server will rewrite the URI parameter of the HTTP request.

    • One or more host, port, or scheme parameter is rewritten.
      The EDJX Server acts as a proxy to the target server.
      For example for HTTPS URLs: →
      In the example, all requests for the given match value, as per matching policies, will be served from the target server.
      NOTE: The scheme parameter is compulsory in the routing destination. Make sure your target server support TLS verification for the requesting domain.

Routing Destinations

The following placeholders are supported:

  • {scheme} — Used for the same scheme of incoming request for the routing target destination.

  • {host} — Used as the host value of the incoming request.
    It can be used to retain the same host.

  • {port} — Used to capture values (including :) of the incoming request port number.
    By default, for HTTP and HTTPS requests (port 80 and 443, respectively) leave this placeholder blank.

  • {path} —  Used to capture the path value (including /) of the incoming request.
    NOTE: Add a backslash (/) before the placeholder if you are using {path} without a prefix; otherwise, parsing issues could occur for the provided value.

  • {query} —  Used to capture the raw query value (without ?) of the incoming request.

Custom Domain Certificates

The EDJX platform allows you to add SSL/TLS certificate.

To add custom certificates:

Consider the following when using custom domain certificates.

Certificates must be a valid X.509 Certificate.
You can copy and paste this content from the certificate .pem file.
This input is validated based on the following parameters:

  • Common Name - Certificate should be the same or should be a sub-domain of the domain name of which the user is uploading the certificate.

    • Expiry - Certificate should not be expired.

  • Issuer - Certificate should not be self-signed.

Chains contain all the intermediate Certificates up to the root Certificate.

Private keys contain the secret key of the certificate, which will be used by the Web server when it makes an SSL/TLS connection.

SSL Certificate Chain Order

The EDJX Platform will validate the Chain of trust, starting from the Certificate provided in the certificate you added up to the root certificate.
While validating the Chain of trust, the EDJX Platform validates the intermediate Certificates as follows:

The SSL certificate chain order consists of root certificates, intermediate certificates, and the end-user certificate.
Root CAs are a trusted source of certificates.