• Quick Installation Guide
  • Step by Step
  • Admin User Guide
01. Introduction
  • Presence of the Machine
02. Hardware Requirement
03. Acquire the Software
04. System Configuration
05. Recover System via RAID
06. FAQ

The Presence of the Running Machine on the Internet

Everything has a start, and has an end.

Deploying a server over the Internet is different from setting up a local server without being revealed to outside people. For a server to be unknown on the Internet by fully-qualified hostname, it requires some registration processes. Furthermore, since the server is known to the public, some security measures should have been taken to avoid the abuse of the server.

This package includes basic elements for network operation, for example, DNS, FTP, firewall, backup storage server, VPN (Virtual Private Network) and Email .

We start from the introduction on Domain name registration with the following diagram:

1. Purchase domain name from the “vendor for domain name registration”

The “Domain Name Registration Vendor” usually will provide a Web interface for you to query your desired domain name. You may find some of the domain names you like have been acquired by other people. It is necessary for you need to find a domain name that is not being occupied. And then make the purchase of the domain name from the “Domain Name Registration Vendor” to complete this step.

2. Purchase Internet bandwidth and obtain “static” IP addresses from your local ISP (internet service provider).

Usually, the ISP will give you a set of IP addresses that may include a list of public IP addresses, the netmask, and the default Gateway. This IP information will be used when you install the software and configure your server. You shall keep the information in a safe place once you obtain that from your ISP.

3. Find a legitimate “DNS host provider”

It is to host your domain name (which you get from step 2) and the associated static IP address (which you get from step 3) record so that everybody on Internet can use your domain name to reach your server. Usually, the “DNS host provider” will provide a Web interface to allow you to input your domain name and the mapped IP address record into their hosted server. This step is completed after you have entered the data into the web page.

4. Update the record at the “Domain Name Registration Vendor” server with the IP addresses of the “DNS host provider”.

At this step, you need to access the website provided by “Domain Name Registration Vendor”. If you do not know the DNS server’s IP addresses of your “DNS host provider”, you can do as follows at your Windows command prompt (the command prompt is reached through Start > Run > cmd), issue the command

  C:\>nslookup DNS-server- name-from-your-provider

The system will respond with the IP address of your “DNS host provider”. Usually, you need to find two IP addresses of the two DNS servers provided by “DNS host provider” (one is called primary DNS host server, the other is secondary DNS host server). The two IP addresses will be entered into the record in the place of “Domain Name Registration Vendor”. We suggest using primary DNS server and secondary server from different places. The Azblink server package also provides DNS server. But to allow people all over the world can query your domain, you should have your domain name placed in different DNS servers to alleviate the load.

5. Wait until it is in effect.

In general, it needs 24 hours to 72 hours to have your domain name record of the server populated across the world so that people can use domain name to access your server.
Those are the general steps as long as you want to have your own private server(s) on Internet.

TOP

Basic Web Setting

After the system installation be finished, take the CD out, reboot the machine, and then start the basic network setting for the system.

There are two modes to configure the host, one is console mode on the local host, and the other is Web interface mode on Client. You can choose the one you like or just by the network environment of that time.

Console Mode --- configure on local host

A. Input account and password to login into console configuration interface.

 login:reset
 Password:root123

B. You will see 7 options after login in

 1. IP Address:192.168.19.185
 2. Netmask:255.255.255.0
 3. Default Gateway:192.168.19.1
 4. Save and Reboot
 5. Reset to CD setting (DHCP) and Reboot
 6. View Current Active Values
 7. Exit without Saveing Changes

C. Is there any fixed ip ready for configuration?

  Yes, type fixed IP address, Netmask and Default Gateway into option 1.2.3. severally. You can use up
  and down arrow to choose the option who needs edit, and then press enter to configure. After option 1.2.3
  be correctly configured, you can use option 4 to save these changes and reboot the machine. (If you have
  no idea about the Netmask and Default Gateway, you can just refer to the Completion List provided by your
  ISP.)

  No, if there is a DHCP server providing the IP assignment services in your network, you can just use option6
  to check the IP address assigned by the system. After checking eth0, please write down the IP address, and
  remember to use option 7 to quit the Console interface.

D. By the IP address you set or the one obtained from DHCP, you can view the configuration page of the
   system host via Web browser on remote Client.

※ DHCP server exists in your network, but if you find eth0 shown as IP 1.2.3.4 when you check current system value, please check if your network cables plug into wrong place (eh0 and eth1 may been exchanged), or if there are some problems on other equipments. (Refer to Q&A in the manual)


Web interface Mode --- configure at sub-network

A. Is the host, which you installed system on, connected by other hosts?

  Yes, please confirm the host is the only DHCP sever (that is to say the network should not have other
  DHCP servers, e.g. IP distributor), and then start from C.

  No, please complete basic network configuration according to B’s instruction.

B. A network cable makes host’s eth1 port and the Hub connected. And use another cable to connect to
  Hub, let the other end of this cable link to a common Client computer.

C. Choose one Client computer from the sub-network which connected to the system host.

D. Open command prompt on the Client (suppose it’s a Windows machine), type “ipconfig” and then press
 “Enter” button, check whether the Default Gateway is 172.16.9.1 or not?

  Yes, just close the command prompt, enter into next step.

  No, type “ipconfig/release” to release the old IP in your computer, and then type “ipconfig/renew” to get
  new assigned IP.
  (If you are still unable to obtain new IP, please check if the network has other DHCP sever or not, or maybe
  TCP/IP of this Client does not use the mode of “Obtain an IP Address Automatically”.)

E. Open your Browser, and type http://172.16.9.1 at the address bar to link. When you visit the page at the
  first time, you will see 4 items;

  Host Name:Please set Host Name for this host.
  Admin Password:Default password is admin123.
  New Admin Password:Please set new password.
  Confirm Password:Please confirm your new password.

F. After you enter into system page, go to System>>Network, choose Internet or PPPoE depending on the
 situation.

  Choose Internet. At the Internet Interface, mostly, you should set the values for IP address / Netmask /
  Default Gateway and then submit, restart your machine and you will find it already connected to Internet.

  Choose PPPoE. If you use PPPoE, remember to check the checkbox of “Turn on PPPoE”. Fill in the account
  and password provided by ISP and submit, reboot your computer, then you can connect to the network.
  (Please refer to the sections of Configuration and Q&A in Quick Installation Guide if you have any questions.)

TOP

Overview

The term “Email Authentication” we use here is to refer all of the methods for checking the validity of Email servers; it is mainly referring to authenticate sender’s domain name via DNS;  it is different from Email content filtering or authors’ digital signatures.   Here we only give a brief introduction of those Email Authentication schemes so that people can establish enough knowledge to use those features provided on the Email solutions. However, for more detailed information, please check their respective specification documentation.

The schemes SPF( Sender Policy Framework), SenderID, DomainKeys, and DKIM (DomainKeys Identified Mail)  are designed to verify sender’s domain name associated with emails.  The simplest method for Email authentication scheme is “reverse DNS lookup” plus “forward DNS lookup” to check if the IP addresses of  incoming emails are matched with those domain names.  However, simple “reverse DNS lookup” and “forward DNS lookup” are not flexible enough; they are not designed for Email authentication originally. Why those verification schemes are proposed can date back to the protocol design of SMTP (Simple Mail Transfer Protocol) and the prevailing email forgery by faking a domain name to send out emails.  Thus, Email authentication schemes are come up to resolve those issues.

Operation of DomainKeys and DKIM

The principles of  DomainKeys and DKIM are similar.  DomainKey is originally proposed by Yahoo. Later on, people adopt that concept and propose DKIM. The idea behind is: generating the pair public key and private key.  The private key is used by “sender machine” to put a signature on the outgoing emails; when the emails arrive at the “receiver machine”,  the receiver machine uses the public key by issuing  an query from DNS server to verify the validity of the signatures.



The philosophy of this mechanism is: the Public Key is used for “verifying” the signature and Private Key is used for “signing” the signatures; furthermore, people can not guess “Private Key” from “Public Key”.  So, when the signature does not pass the verification, it could imply the email is sent out without going through the correct signing process; it could be a forgery email.



-----BEGIN RSA PRIVATE KEY-----

MIICXQIBAAKBgQC+2og5sex8zeXAZonl2/vnzVjsUHLKUv0DSoZeWgpQrB5FQgf7Ttd18w1FT
jAmv8hK4GtYOSRtoBZFUCVMwmBB9Tkx60EHckp+Fb494OZYbenL8hJL7XLuS5ux4tokwGW
//3dBUxIHnTxIRt+aJ7Ik96GIr90lUt0oqe3FbAE6/wIDAQABAoGADpcCJvb1Dy1mTOkJzaqdfUD
zdU1JGTJy6Rd/YiMb+sLNpZnApnOGgRvNfejWQYATvbWePyZPJJpCWZYg49dQKFiS8/wA7fd
qodAlyAOS5vhFmUBdcJh45mbHLRElwVfDGIx1tkFlwxGZLvIUP08Q2i7mneO9i421FOKLTEl3p
rECQQD78J1N5GcnUor3yt8diBJOyJm1UPG31bUtTidXw980tjlnIlcZntIgg0q9VIYooJZhjs0O9aeA
5aw1TZBW5N6LAkEAwe3njHPtoyH9zsUROsnBg48UtGQZ1KgC3nPFL+LxxRjfoU/Ew54bdcKr0
Ye8p3qM3IwZ1aqES/SyVO+SJL/33QJBAPkYXJ9v7WGephH7fn/3UoqcogT4hBWL8bdap2GKIz0
90iGbfVyyf/Vvek0Zrg+rPyQ0CaD512SFMK//AXA4l6MCQFu+TLhpb5apUgUrvYbuQ5oValocsQ
uloBXU9wg8eNwhdEpADnnsplkDi31Ilbs1gsYjkWU/ke7NCECeRakVGBECQQD4Cjs2CWSZotij
yPab/dG0ynP7Wsdw3EcHlml1kO2JHdwYOD0DfUetikKhBDq5f5arkgBSzCpQjmf7CVmmdy93

-----END RSA PRIVATE KEY-----



-----BEGIN PUBLIC KEY-----

MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+2og5sex8zeXAZonl2/vnzVjsUHLKU
v0DSoZeWgpQrB5FQgf7Ttd18w1FTjAmv8hK4GtYOSRtoBZFUCVMwmBB9Tkx60EHckp+Fb4
94OZYbenL8hJL7XLuS5ux4tokwGW//3dBUxIHnTxIRt+aJ7Ik96GIr90lUt0oqe3FbAE6/wIDAQAB

-----END PUBLIC KEY-----


Public key shall be published in DNS.  It is with the following format in TXT record of DNS:

selector._domainkey.example.com.   IN  TXT   "g=*; k=rsa;  p=MIGf...DAQAB "

where “selector” is the Selector used by DKIM or DomainKeys indicated in the outgoing emails in the signatures. And the part “_domainkey” shall be kept as it is. Usually, if you give full name by adding domain names in DNS records, it usually ask you to put a trailing dot.  The public key is placed at the place “p=….  “ . The record shows it is using RSA algorithm. If you just want to test it, you can add “t=y” in the record.

When  an email arrives at a receiver machine, it needs to know which public key to use.  For example, if each of your machines is using different key to sign the outgoing emails, you might have multiple public keys in DNS. By specifying different selectors, the receiver machine will know which public key to query from DNS server:

beta1._domainkey.example.com.   IN  TXT   "g=*; k=rsa;  p=MIGf...DAQAB "
beta2._domainkey.example.com.   IN  TXT   "g=*; k=rsa;  p=MIGf...FAFAB "

If you can see the Email Headers on a receiver machine, you might find out the header would contain the field “DKIM-Signature” or “DomainKey-Signature”. This means that email was signed by “DKIM” or “DomainKey”. And the authentication result will be placed at the field “Authentication-Results”.

Operation of SPF and SenderID

SPF and SenderID are different standards. Originally, SenderID was proposed by Microsoft and later it was forced by IETF’s suggestion to be compliant with SPF.  Thus, to play safe, we suggest only placing SPF record in DNS.  In DNS, the SPF record should look like

mydomain.com.   IN  TXT  "v=spf1 a +mx +ip4:130.207.0.0/16 -all"

Please note that “a” or “mx” here means “A record” and “MX record” in DNS respectively.  For those “+” and “-“,  they are referred as “qualifier” in SPF. They have the following meaning:

+ : PASS result, this can be omitted, +mx is the same as mx.
? : NEUTRAL result interpreted like NONE (no policy).
~ : SOFTFAIL, a debugging aid between NEUTRAL and FAIL.
- : FAIL, the mail should be rejected

Each line shall be read from left to right; if the previous condition matches, the rest of the conditions will be ignored.

SenderID is with a few addition on SPF, it replaces “v=spf1” with either one of the following:

1. spf2.0/mfrom
2. spf2.0/mfrom,pra
3. spf2.0/pra,mfrom
4. spf2.0/pra

However, when it sees “v=spf1”, it needs to fall back to SPF.



The operation of SPF and SenderID is indicated in the diagram above.  A DNS record is placed on the DNS server associated with that domain name to indicate which machine is legitimate to send out emails on behalf of that domain.  When an email arrives at a machine, the receiver machine might issue a query to DNS server to know if the IP address is allowed to send out emails from that domain.  If it does not match the policy specified in DNS record, it implies that this is a forgery email.

After familiar with the work flow above, we start to put them into action.

Key Generation for DKIM and DomainKey

The Key Generation Process can be done via navigating through “Email->Authentication->Key Generation”:



By pressing the “Submit” button, they system starts to generate the pair Private Key and Public Key for the use of DKIM or DomainKey.   Private Key will not be displayed on Web UI for security sake. And Public Key can be displayed by pressing “Display” button on the right.  Later on, the public key shall be used to fill in the record in DNS server.

DKIM/DomainKey Signing and Verifying

To sign the outgoing emails or verifying incoming emails on DomainKey or DKIM signatures, the following setting should also be set in advance:



It can be found via “Email->Authentication->DKIM & DomainKey”.  And Selector and domain name shall be entered as well. The email system will put the name of Selector on DKIM and DomainKey signatures so that the other end can verify the received emails.

Selector for signing Outbound Emails:  selector1
Domain List to sign:  mydomain.com

Please note that the system will only sign the DKIM/DomainKey signatures for the domain in the list with the selector label entered here.  In other words, it will not sign the domain that is not on the list. Thus, if you use this machine to send out emails by using different domain names intermittently, you should choose the domains you want to sign and enter them into the field “Domain List to sign” by separating them in “,” :

Selector for signing Outbound Emails:  selector1

Domain List to sign:  mydomain.com,mydomain2.com,mydomain3.com

If you want to sign the outbound emails, do not start DKIM/DomainKey processing until you fill in the associated DNS record. Even right after you fill in the corresponding DNS record, the DNS record will not populate around the world so quickly.  Thus, you might expect some failure results in the authentication result on the other hand due to no record in DNS initially.   By the time DNS record to be published into other DNS servers, those signatures can be correctly verified.

You can choose not to sign the outbound emails by letting the system only verifying the inbound emails only.  It can be done by click the checkbox

Only verifying Inbound Emails without signing Outbound Emails

When you click this box, the rest of the options will be ignored. It only verifies the incoming emails without signing outgoing emails.

By default, the system will verify DKIM and DomainKey signatures on incoming emails and only sign DKIM signature for outgoing emails.  You need to click those options on this configuration screen to change its behavior. 

For example, to add DomainKey signature, you need to click the box

-“Add DomainKey-Signature in Outbound Email headers in addition to DKIM-Signature

Do not forget to add the associated DNS record if you want to sign the outgoing Emails.  We will mention it later if you use the DNS server on this machine as well.

SID (SenderID) and SPF

As we mention previously, the verification will be done on Email server for SenderID and SPF.  For the other end to know which IP address(es) can send out Emails on behalf of your domain, you need to put the associated records on DNS server.



To turn on SPF and SID verification, just go to “Email->Authentication->SPF & SID” to submit the request. 

The Corresponding DNS records for SPF, DKIM, and DomainKey

If you use Azblink’s DNS configuration system, you can do as the following steps indicated.

Navigating via “DNS->Domain Zone->Zones Manager” and click the domain you have created, you will find different items for DNS there.  Press “SPF”, and you will find the following screen.



Just select the mechanism you want to have for SPF by clicking those checkboxes and it will generate the SPF record thereafter.

If you want to handle this in more sophisticated way, you can press “TEXT” to deal with TXT record directly:



And it gives the flexibility to adjust your setting along with different requirements.



For DKIM and DomainKey, we deal with TXT record directly.



Remember the “selector” needs to match with the one you use for Email server, and the public key needs to be copied here.

TOP