Geo dns is a way of serving different responses to querying clients based on their apparent country of origin. Geo dns on the CloudfloorDNS platform can be enabled for any domain during the dns setup process by ticking the 'Enable GeoDNS' box. Use this method also for existing domains. It will not overwrite data unless you request that during setup.

To assign specific geo records, add them in the normal way as shown below. You will note there is a new 'Geo' column. Use this to add the appropriate 2 letter ISO country code you wish to apply to your record. You can specify multiple country codes separated by commas, for example, GB, DE, for Great Britain and Germany. Multiple records with different country codes and the same name can be added. Multiple A records with the same name and country code will server as a load balancing group for the specified country.

You can also update existing records to add the country codes to the if you wish.

For visitors from unknown or non-matching regions, the default record will be supplied. The default record is the record with the same name but no country codes listed.

Country code matching can currently be used with A records.

CloudFloorDNS offers simple to implement 'one-click' dnssec where we provide the necessary key management. If you prefer to sign your own zones locally and provide us with a pre-signed DNSSEC zone for distribution to our servers, please follow the following procedure.

Login to your account

Proceed to the DNS editing page for the domain you wish to sign.

Expand the 'Zone file in bind format' section towards the bottom of the page. From this section you can cut and paste or download your zone file in the common bind format that most signing tools will recognise.

Sign your zone locally .

Return to the dns editing page and expand the 'DNSSec' section.

Expand the 'Advanced settings' panel

Using the 'Import self signed zone file :' option shown below, browse to the file on your hard drive.

Click the link/button to 'sign this zone'.

Note : Only the dnssec record types are imported. Other common records are ignored. It is essential that you sign the file you downloaded from ClourFloorDNS and not a similar file. Unless the file you upload contains records the same as the file you downloaded (exactly) the signatures will not match and dnssec verification will fail.

Incorrect configuration of dnssec can cause your domain name to fail. CloudFloorDNS takes no responsibility for the issues incorrect dnssec entries may cause, but we will endeavour to assist you in resolving any issues.

In order to use this facility, you must enable the POP collection service on your backup email service queue. You can do this from the backup email management panel, by clicking the 'options' link. You will need to enable the 'enable POP collection of the backup queue' and ensure a valid password is assigned to the service. Once you have done this, you will need to configure any standard POP3 client with the following parameters

account name : your backup mx queue domain name, e.g. yourdomain.com

password : the password you assigned on the backup email options page

port : 110

pop3 mail server : bmxpop.mtgsy.net

outgoing email server : your local ISP or other outgoing email server (do not put bmxpop.mtgsy.net here)

WARNING: Most pop clients delete email once it is downloaded. If you let this happen, then your email queue will be deleted as it is downloaded by the pop client! If you do not want this to happen, make sure you enable the option similar to 'leave mail on server'. This will ensure that your pop client does not delete email from the backup email queue, and it will still be delivered to your main host when it comes back online.

Notes: On some mail clients like 'Outlook Express', there is a very short timeout of 30-60 seconds. Due to the fact there can often be thousands of mails in the backup email queue we recommend this timeout be increased to the maximum possible. In outlook express this is done in the advanced options of the email account by sliding the timeout slider all the way to the right.

Please do not ask us to supply epp keys via email or telephone etc. as we cannot do this for security reasons.

To enable this feature you need to configure a custom alert profile for your client. When configuring the profile, tick the 'Email alert to client' option. This will expand to allow you to design a html email which will be sent to your client when the monitored service changes status. The following is an example of a brief message that includes both up and down responses to the client.

"Dear Client,

$DOWNThere would appear to be a problem with some of your network services at the moment.

Please be advised that Microtech engineers are already aware of the issue and are investigating.
$DOWN.$UP
We are pleased to inform you that the issue with your network has been resolved.
$UP.

Thank you.

XYZ Limited. "

The text between the $DOWN and $UP will be removed as appropriate.

Multiple email addresses in the email address box can be separated by commas if you wish to alert several addresses to the issue.

There is no chanrge to move domains between accounts.

keywords : domain, transfer, move, account

Microtech have implemented an advanced 'redirect' dns type on the dns editing page for your domain. Using the 'redirect' dns type you can create advanced forwards that automatically take care of the issues forwarding sub domains, naked domains, etc.

To create a redirect record, simply add a new dns record using the 'REDIRECT://' record type. This is a special type of record that configure our web servers to forward your requests to another web site. In the data column put the full url you want to forward to, for example, http://www.mydomain.com. To forward the naked domain, leave the 'name' column empty. To forward a sub domain, put the name of the sub domain in the 'name' column, for example 'support'.

There are different types of redirects such as 301, 302, hidden frame, etc. These different types of redirects can be implemented by specifying an 'aux' value for the record. In most cases, leave it as zero.

Aux value set to 2 = 301 redirect type, moved permanently. We suggest you do not use this without good reason as a 'permanent' redirect is just that. It will be cached by search engines and users browsers directly and you may have no way to disable the forward at a later date as this data is stored locally on end users machines, not on our systems.

Aux value set to 1 = stealth forwarding - keeps your url in the browser url bar rather than showing the real url

Add 10 to the aux value to disable 'explicit' forwarding. Explicit forwarding is the default and will make www.yourdomain.com go to www.myotherodmain.com. It will also make www.youdomain.com/subdirectory go to www.myotherdomain.com. If you require that www.yourdomain.com/subdirectory go to www.myotherdomain.com/subdirectory, then do not use explicit forwarding.

keywords : http, redirect, forwarding, 301, 302, redirects

To view a zone file as it was when a backup was taken, expand the 'Previous versions (backups)' section, find the backup you wish to view and click the icon to view the backup. The historical copy will open in a new browser tab/window.

To restore a zone file to a previous version, click the icon. This will restore the zone as it was at the time the backup was taken. Backups are preserved for a certain period even after your zones are deleted, so accidental deletions and recoveries can be made using this feature.

Depending on your account, space for backups may be limited.

keywords : dns, backup, zone file, undo, recover, undelete

You can also view your queue via the webmail service. See here for more How to access your backup email queue via webmail

This includes all popular email servers such as Microsoft Exchange, Smartermail, MDeamon, Sendmail, Imail, Zimbra, Kerio, and many more.

Contact us is you have any concerns, but if your mail server works on the internet to communicate with others publicly, it will work with the backup email service.

We queue email for a default period of 10 days. This would then be bounced back to the sender as undeliverable. Should you need to queue mail for longer than this you can change this setting in your configuration options.

In order to use this facility you must first enable the POP collection service on your backup email service queue and assign a password to the service. This service is disabled by default for security reasons. You can enable the service from the backup email management panel by clicking the 'options' link. You will need to tick the 'enable POP collection of the backup queue' option and ensure a valid password is assigned to the service. Once you have done this you will be able to login via the dedicated web mail interface here.

The login information required is

Email : This is used as the return address for any email you respond to. Ensure it is valid and appropriate

Login : This will be your backup email domain name, or if per user logins are allowed as with the business service and mailscan, your full email address.

Password : The password you assigned to the service in the options.

Once logged in you should be able to view your email and perform other operations such as delete, forward, reply, etc.

Setting the TTL inappropriately for your domain can have significant side effects in terms of dns traffic and web site performance.

This document is intended to suggest reasonable TTL's (time to live's) and give some information on best practices for your domains.

Why is the TTL important?
The 'time to live' of a dns record specifies the amount of time other dns servers can cache your IP address before checking with us to see if it has changed again. DNS servers at users ISP's generally provide a lookup service that is more local to the user, and hence generally faster to respond. The use of caching enables other users of the ISP that lookup the same record to retrieve the information directly from a very close source generally at a much greater speed. If there was no cache, every single time a web site URL was requested a dns query would need to be made to the servers that run dns for that domain. This can only take 20-50 milli seconds or so, but bear in mind a page may refer to a url lots of times on a page resulting in multiple dns lookups. On many sites as many as 20-30 times a page. Having a local cache prevents repeat lookups for information that is unlikely to have changed. If your TTL is set at 1 hour, the local ISP can cache that record locally and provide the information to other users from it's local cache. Users PC's also cache the information right on their own desktop meaning even faster access after that initial lookup.

The downside of a long ttl
The downside of having a TTL set at 24-48 hours as most larger ISP's and web hosts do is that if you do have to make a change to your domains dns it can take up to the TTL to fully propagate around the world. This means that with your TTL set at 24 hours, some ISP's could still be serving the old information 23 or so hours later. This is worst case, but you can see that it would be important to have both the old and new IP addresses both answering queries for the domain for some time to prevent some users being unable to access them.

The benefit's or a short TTL
If your TTL is short it should be cached for a shorter duration by other internet systems. This means that should an IP address change as a result of a server move or network re-configuration, users pick up on that change and things start working again more quickly.

Finding a balance
The answer is to find a reasonable balance between lower TTL in case you need to make a change to your dns, and less dns traffic/better performance experienced with longer TTL's. At first thought it might seem like a good idea to simply reduce all your TTL's to 10 minutes or so, but not only is this incredibly wasteful of internet resources it can cause performance issues for your web site possibly affecting sales and search engine rankings. Studies have shown that even small delays you would think barely susceptible to humans can make a difference when a user is making an opinion about your web site. In the event of an issue with your dns service, it also means your web site goes off-line faster. Some adsl routers struggle and even become unstable with sub 60 second TTL's, so if your intended web site visitor is a home shopper, bear in mind if their router crashes when surfing your site, they are unlikely to buy!

Some dns records rarely if ever change. Mail servers and name servers are prime examples. It makes good sense to set these records at 24 hours or more. Some registries will even insist on it.

Below are some recommended minimum TTL's for various record types. Set them longer if you can, but no so absurdly long that they take weeks to change if you do change them.

Note, these are recommended minimums. If you can set your TTL longer, then do so. It will improve your sites performance globally for many users and reduce the load on worldwide dns infrastructure. As of 2009, the dns infrastructure of many ISP's is overloaded. This has been mostly caused by the social networking phenomenon that has erupted over the last few years. Some organizations such as the department of defense have even blocked these sites completely to preserve resources. A single myspace page can have 100 or more dns lookups. Some larger ISP's have reported 10% of the dns capacity taken by myspace alone. Many ISP's have struggled to maintain high performance dns lookup service with this rapid increase in dns traffic. Setting your TTL's longer will help avoid performance issues for users accessing your sites. Setting your TTL's lower than 3 minutes for an 'www' record for example is pointless. Internet explorer will internally cache a dns lookup for 30 minutes, and Firefox for 3 minutes. These 2 browsers account for the vast majority of all web browsers. New visitors will of course get the new dns record quicker, but people surfing your site at the moment it changes will probably not.

Make use of the dns traffic graphs on Microtech's web site if you are using Microtech's dns services to see the affects of changing your TTL's. If the traffic shows no real difference, then live with the benefits of a reduced TTL perhaps. If your dns traffic shows a dramatic reduction, seriously consider keeping the longer TTL to improve performance.

Preparing for a move.
What if one of your servers is moving or you have a change in supplier and need to change an IP address? The best way to go about this is to reduce the TTL on the records you want to change before the planned move. If your TTL is normally 24 hours, consider reducing it to 10 minutes a day before the move. This should mean that when you change your record it will be almost immediate. Once changed you can restore the TTL to the original setting. The below graph is a real-world example of a popular domain that changed the www record to 10 minutes rather than the usual 1 hour for an ip change. The change has a dramatic affect on dns traffic as you can see, so don't forget to increase the TTL again later!

Not all ISP's allow you this sort of granular dns access or reporting. Microtech's DNS service gives you full control over individual DNS records TTL's and provides very detailed reporting on dns usage enabling you to performance tune your domains dns.

Setting the TTL inappropriately for your domain can have significant side effects in terms of dns traffic and web site performance.

This document is intended to suggest reasonable TTL's (time to live's) and give some information on best practices for your domains.

Why is the TTL important?
The 'time to live' of a dns record specifies the amount of time other dns servers can cache your IP address before checking with us to see if it has changed again. DNS servers at users ISP's generally provide a lookup service that is more local to the user, and hence generally faster to respond. The use of caching enables other users of the ISP that lookup the same record to retrieve the information directly from a very close source generally at a much greater speed. If there was no cache, every single time a web site URL was requested a dns query would need to be made to the servers that run dns for that domain. This can only take 20-50 milli seconds or so, but bear in mind a page may refer to a url lots of times on a page resulting in multiple dns lookups. On many sites as many as 20-30 times a page. Having a local cache prevents repeat lookups for information that is unlikely to have changed. If your TTL is set at 1 hour, the local ISP can cache that record locally and provide the information to other users from it's local cache. Users PC's also cache the information right on their own desktop meaning even faster access after that initial lookup.

The downside of a long ttl
The downside of having a TTL set at 24-48 hours as most larger ISP's and web hosts do is that if you do have to make a change to your domains dns it can take up to the TTL to fully propagate around the world. This means that with your TTL set at 24 hours, some ISP's could still be serving the old information 23 or so hours later. This is worst case, but you can see that it would be important to have both the old and new IP addresses both answering queries for the domain for some time to prevent some users being unable to access them.

The benefit's or a short TTL
If your TTL is short it should be cached for a shorter duration by other internet systems. This means that should an IP address change as a result of a server move or network re-configuration, users pick up on that change and things start working again more quickly.

Finding a balance
The answer is to find a reasonable balance between lower TTL in case you need to make a change to your dns, and less dns traffic/better performance experienced with longer TTL's. At first thought it might seem like a good idea to simply reduce all your TTL's to 10 minutes or so, but not only is this incredibly wasteful of internet resources it can cause performance issues for your web site possibly affecting sales and search engine rankings. Studies have shown that even small delays you would think barely susceptible to humans can make a difference when a user is making an opinion about your web site. In the event of an issue with your dns service, it also means your web site goes off-line faster. Some adsl routers struggle and even become unstable with sub 60 second TTL's, so if your intended web site visitor is a home shopper, bear in mind if their router crashes when surfing your site, they are unlikely to buy!

Some dns records rarely if ever change. Mail servers and name servers are prime examples. It makes good sense to set these records at 24 hours or more. Some registries will even insist on it.

Below are some recommended minimum TTL's for various record types. Set them longer if you can, but no so absurdly long that they take weeks to change if you do change them.

Note, these are recommended minimums. If you can set your TTL longer, then do so. It will improve your sites performance globally for many users and reduce the load on worldwide dns infrastructure. As of 2009, the dns infrastructure of many ISP's is overloaded. This has been mostly caused by the social networking phenomenon that has erupted over the last few years. Some organizations such as the department of defense have even blocked these sites completely to preserve resources. A single myspace page can have 100 or more dns lookups. Some larger ISP's have reported 10% of the dns capacity taken by myspace alone. Many ISP's have struggled to maintain high performance dns lookup service with this rapid increase in dns traffic. Setting your TTL's longer will help avoid performance issues for users accessing your sites. Setting your TTL's lower than 3 minutes for an 'www' record for example is pointless. Internet explorer will internally cache a dns lookup for 30 minutes, and Firefox for 3 minutes. These 2 browsers account for the vast majority of all web browsers. New visitors will of course get the new dns record quicker, but people surfing your site at the moment it changes will probably not.

Make use of the dns traffic graphs on Microtech's web site if you are using Microtech's dns services to see the affects of changing your TTL's. If the traffic shows no real difference, then live with the benefits of a reduced TTL perhaps. If your dns traffic shows a dramatic reduction, seriously consider keeping the longer TTL to improve performance.

Preparing for a move.
What if one of your servers is moving or you have a change in supplier and need to change an IP address? The best way to go about this is to reduce the TTL on the records you want to change before the planned move. If your TTL is normally 24 hours, consider reducing it to 10 minutes a day before the move. This should mean that when you change your record it will be almost immediate. Once changed you can restore the TTL to the original setting. The below graph is a real-world example of a popular domain that changed the www record to 10 minutes rather than the usual 1 hour for an ip change. The change has a dramatic affect on dns traffic as you can see, so don't forget to increase the TTL again later!

Not all ISP's allow you this sort of granular dns access or reporting. Microtech's DNS service gives you full control over individual DNS records TTL's and provides very detailed reporting on dns usage enabling you to performance tune your domains dns.

Name server changes will be requested by us immediately but due to DNS propagate around the internet, will most likely take several hours to take affect.

Start at http://mya.godaddy.com

Click the 'Manage domains' link. This will open the domain control panel.

Click on the domain you want to transfer

Unlock the domain by cliking 'change' and choosing to 'Unlock' the domain.

To retrieve the auth code for the domain, click the 'send by email' link. This will email the auto code to the listed admin contact for the name.

To request the transfer in of the domains at Microtech

Go to www.mtgsy.net, select 'domain names', 'transfer' from the menu and enter the names to transfer.

Don't forget, if you have a number of domains to transfer and would rather we manage the move for you, contact our sales team

keywords: domain, transfer, godaddy, away, transfer guide

Start at http://www.joker.com

Login to Joker using the menu on the left and your Joker username and password.

Select 'service zone' from the menu

Click 'advanced options', then ' proceed'

In the 'AUTH-ID' section click proceed.

Enter the domain name into the 'domain' box and click the 'send auth-id' link.

The auth code will be send to the domain contact. if the contact data / email for the domain is out of date, update it before requesting the auth key by going to the 'service zone', then 'domain modification', then enter the name and update the admin contact.

If it is a non-uk domain, unlock the domain by clicking 'service zone', then 'domain settings', 'proceed', 'domain modification', 'proceed', and 'remoew' or 'switch off' domain protection.

To retrieve the auth code for the domain, click the 'send by email' link. This will email the auto code to the listed admin contact for the name.

To request the transfer in of the domains at Microtech

Go to www.mtgsy.net, select 'domain names', 'transfer' from the menu and enter the names to transfer.

Don't forget, if you have a number of domains to transfer and would rather we manage the move for you, contact our sales team

keywords: domain, transfer, joker, away, transfer guide

For .uk domains

Start at http://www.ukreg.com

To transfer a Fasthosts domain away from UKreg, you'll first need to check if it was initially registered at UKreg or if it was transferred into UKreg from elsewhere.

Click on the "Members Login" link at the top of the page.

Go to UKreg and select "Configure Domains".

Select the domain you'd like to move and choose "Change IPS Tag".

The IPS tag for Microtech is MICROTECH. enter it here.

If the domain was transferred into UKreg you must also send a fax, on headed notepaper, to UKreg providing the following information:

• The new IPS tag name
• The username and password for your UKreg account
• The domain name

The support fax number for UKreg is 0870 888 3555.

For non .uk domains

Start at http://www.ukreg.com

Click on the "Members Login" link at the top of the page.

Select "Configure Domains" in the middle of the page.

Log into your UKreg account.

Select the domain you wish to unlock.

Click "Unlock For Transfer" to see the screen in Fig. A. This does not apply to .eu domains.

Click "Confirm".

Contact UKreg support and ask them to send you your Auth Code.

To request the transfer in of the domains at Microtech

Go to www.mtgsy.net, select 'domain names', 'transfer' from the menu and enter the names to transfer.

Don't forget, if you have a number of domains to transfer and would rather we manage the move for you, contact our sales team

keywords: domain, transfer, Fasthosts, away, transfer guide

The advantage of using 'webzone' credits instead of subscriptions to specific services is that the webzones are refunded when services are cancelled and so can be reused for other services. For instance, you have dns for 10 domains, costing 10 webzones. You remove 2 domains. You now have 2 webzones free to add a further 2 domains for dns.

Webzones work for all our dns services. You can redeem them for normal static dns, dynamic dns, and secondary dns. Because of the flexible nature of webzones you can switch between these different services at any time.

All webzone paid credits last for 1 year. Webzones can be purchased here http://www.mtgsy.net/dns/signup.php and managed or renewed from here http://www.mtgsy.net/dns/renew.php.

To see how many webzones you are using, and where, go to the 'my account', 'my microtech' menu option. This page shows you how many webzones you have and how many you are using. You can click the 'where' link to see exactly which services each webzone is being used for.

Webzones may be provided free of charge on occasion, such as with .uk domains.

If you did not receive the SSL approval email, or need to change it due to selecting a non-working address, this is possible.

Go to the SSL management panel. You will see the certificate 'Processing' or 'Approval Email Sent'. Click the link to 'Cancel Configuration'. This cancels the pending configuration and allows you to re-configure the certificate. When you click this link the management panel will re-load. The same certificate will be shown with the status 'Rejected by customer'. Click the link to configure your certificate, and add the appropriate details again as per the first time configure. The authorisation email will be sent to the new address.

For security reasons and to ensure that SSL certificates are only issued to relevant people, thus preventing fraud, the authorisation emails can only be sent to the addresses suggested by the drop down list. This normally consists of addresses at the domain itself, it's parent domain, or the listed domain contacts in public whois.

Renewing a certificate is the same procedure as purchasing a new one.

As long as you use the same common name and type for the replacement certificate, GeoTrust will automatically add the relevant remaining portion of your subscription to the new certificate.

For security reasons, the domain a certificate is issued to cannot be changed. Unfortunately, if you need to change the common name your certificate works with, you will need to purchase a new certificate for that name. If you only very recently purchased your certificate (7 days, maybe more), then it may be possible to cancel the order and receive a full refund against the purchase of another certificate. Please log a call with support with details including your certificate id if you wish to investigate this option.

You may seen this error if you generated your CSR from a version of Linux (debian derivatives) that use a version of openssl with a vulnerability. This version of open SSL was found to be predictable, and this makes any SSL certificate generated off these versions of Linux a security risk. CSR's submitted to the certification authority are now checked to see if they appear vulnerable before issuing.

If you receive this error it does mean you are most likely using a vulnerable version of openssl. Debian has released updates to resolve this issue. Please update your open ssl, regenerate your CSR, and re-submit your request.

The security notice for debian regarding this can be found at http://www.debian.org/security/2008/dsa-1571

GeoTrust certificates require a challenge passphrase be assign to the certificate. If you generated your certificate via WHM or other Linux based OS's and didn't specify a password, you will need to re-generate your CSR making sure you use a password.

Microtech DNS does fully support the use of DNS wildcards. To add a wildcard entry to your dns to make all otherwise no-resolving hosts resolve to a single IP address, add a single A record with the name set to an asterisk (*), set the type to A, and the data to the IP address you want all otherwise non resolved hosts to resolve to.

Note that you can still specify normal static A records such as WWW. Only hosts that do not already exist will match the wildcard record.

There are 2 ways to create dns subdomains on the Microtech platform. If you simply want a name for a website, then the easiest method is the first one. If you need completely seperate dns administration, for example if this is a branch office with different mail servers etc, then it is probably best for you to setup via method 2.

Method 1
Add a subdomain called subdomain.mtgsy.net to the mtgsy.net dns would be done as follows

Bring up the parent domains dns via the link on your management panel
In the new record section, type the name of your subdomain in the 'name' colum, in this case, 'subdomain'. No dot is required, nor should you put the name in full.
In the type colum, select the record type (normally 'A' if pointing to an IP address), in the data field, enter the IP address or host name this sub domain points to, click the add button.

If you need to add MX records for this sub domain, add a new record with 'subdomain' as the name, MX as the record type, and put the name of the mail server in full (with the dot at the end) in the data column.

Method 2
This is generally preferred for more complex sub domains due to the fact management from the parent is separated.

Go to the 'DNS' menu, choose 'Enable dns for a domain', choose the static dns option.
Enter the name of the domain to setup, ie. subdomain.mtgsy.net
Proceed to the editing page and configure dns as normal.
If the parents dns is already on our servers, there is nothing further to do. If the parents dns points to servers elsewhere you will need to ask the dns administrator of the parent zone to delegate the dns for the sub domain to our servers.

Notes

If you create a sub domain using method 2, make sure there is no A record with this sam name in the parent domains dns as this will override your sub domain
If you already tried to see if your sub domain was working before you added it, it's possible due to DNS caching at the client / ISP end it might not work right away. Please be patient and allow up to the zone TTL (normally 1 hour) for your ISP dns cache to clear.

keywords : sub domain subdomain sub-domain

transferring domains away from 1and1 / 1&1 to Microtech

Start at http://contract.1and1.co.uk (or perhaps .com if you are not in the uk).

Chose the menu option to change your contract

select the contract from the list available

Choose the option to cancel individual items (or the whole contact if you are sure you don't need anything else).

Select the domain option (as soon as possible) for the names you want to transfer.

Next page and do the next 10 if you have more than 10.

OK, to the confirmation page.

If you are transferring domains that require EPP keys, these should be presented on this page. Cut and paste them into something as you'll need them when you enter the transfer request on Microtech's web site. They are case sensitive, so if you write them down, do it carefully.

Open the first link (right click and open in new window else you'll loose the current one!). This will send an email to the contract holder asking for confirmation to cancel

Right click and open each of the other links, 1 by 1 and print them.

Sign and date the forms as needed and 'fax back to the number on the form' (note -despite 1and1 instructions, there appears to be no fax numbers on the forms we've seen, and it's a different number than their main one. A call to their support verifies the fax number at the time of writing this is 0845 0762202)

.

To request the transfer in of the domains at Microtech

Go to www.mtgsy.net, select 'domain names', 'transfer' from the menu and enter the names to transfer.

Don't forget, if you have a number of domains to transfer and would rather we manage the move for you, contact our sales team

NOTE:: Please cancel your 1&1 hosting if you are no longer going to use it, else 1&1 will continue to bill you for hosting services.

keywords: domain, transfer, 1&1, 1and1, away, transfer guide

Warnings such as 'dns1.XXX.net is present in the dns zone file by not in the public delegation' and 'dns1.XXX.net is present in the public delegation but not in the dns zone file'. These errors may or may not be critical. They can also show when the dns servers have recently been changed, but the dns information has not yet propagated around the internet (if this is the case, please check back 24 hours later and see if the error has cleared).

If you get this warning on a domain registered with Microtech and you want the DNS to be pointing to Microtech (so you can manage the dns from Microtech), there is a simple way to resolve this. Go to the domain management panel, click on the domain name in the management panel (it will be a link), choose the option to 'update dns servers'. On this page there is a button near the bottom of the page that says 'click this button to automatically set the name servers to Microtech's'. Click this button. This will update the domain name servers with the registry and also reset the NS records in your dns zone file with us, making sure they both match and that you are using the latest set of Microtech's dns servers. The error on the dns zone file editing page should go away within a few hours, though please allow up to 24 hours.

If your domain name is not registered with Microtech, you will need to either update the name servers with your registrar to match the ones in your dns zone file with Microtech, or update the NS records in the zone file to match the ones you have given to your registrar. Microtech has several name servers (approximately 6), and some registrars only allow 2. Whilst this is not a good option from the registrar (it does not give you full fault tolerance). If you are getting the dns warning that the NS records in your zone file do not match the ones listed in the public delegation, this is most likely as we have by default listed all our name servers in your zone file, but your registrar is only listing 2 or 3. We recommend you change registrar, but if this is not possible or desirable, you will need to remove the extra ns records from your dns zone file.

• administrative contact does not respond to email
• epp / authorisation key was incorrect
• domain was not older than 90 days
• domain was locked at the loosing registrar
• various other reasons

If this happens and you take steps to resolve the issue you can simply resubmit the domain transfer without incurring any further charges by using the 'resubmit failed transfer' link that should be present next to the domain name in the domain management panel (domain names menu, 'management panel').

If you need to update, change, or supply an EPP or authorisation key for the domain, click on the domain name in the management panel and choose the option to update the epp key.

If the administrative contact is not listed as you or someone you can get to authorise the transfer (you can check this in whois), then it can sometimes be easier to get the contact details updated to your own with the current registrar before re-initiating the transfer, or change the admin contact address to support@mtgsy.net and we will take steps to ensure the domain authorisation is responded to appropriately.

Should you require any assistance, please contact support or use the live support on our web site where someone will be happy to offer advice and assistance.

The DNS interface can be used with almost any programming language as is it based on HTTP calls. A COM object and a PHP class are also under development.

The API does need to be activated on your account before you will be able to use it

If you would like to make use of the API, please contact us with your requirements.

keywords : dns api application programming interface com php

If you domain name is 'detagged', it most likely means that at some point the tag holder that was responsible for the name has decided they no longer wanted to be associated with it and requested nominet remove it from their account.

Only the tag holder or nominet has permission to make changes to a domain name. This means that if you have a detagged domain name you want to move to Microtech, you will need to ask Nominet (http://www.nominet.org.uk) to change the tag for you. They may make a small charge to do this. If there are any outstanding fees on the domain name, they may need confirmation from us first that we will accept any due fees. Make sure you have spoken to us first or requested a domain transfer via our web site so that we know to expect the domain.

keywords : detagged, nominet, tag

To setup a http content check, add a test from the netmon menu as normal. Make sure you select the test type 'HTTP' and add the full URL such as HTTP://www.mydomain.com/index.html. Make sure Port 80 (if that's what your HTTP server listens on) is selected. Once you've done that and filled in the rest of the options you can click the 'calculate crc' link which, after a second or 2 will put the calculated CRC in the correct field. If your browser does not support javascript then you will be taken to a web page where you can enter the URL and the CRC will be displayed to you.

That's all you need to do to ensure that you get alerted to content changes for that page.

You can also use the 'Check web page content for text' field to ensure that a piece of text is always on the page.

Bear in mind that if you have changing content such as a clock, times, changing news lines etc, then the CRC may well be different every time the page is visited, so you may not be able to use CRC checks on every page of your site.

If you just do the above, then Netmon will alert you when the SMTP port is no longer alive. However, there are many occasions when the SMTP port is alive, but the service cannot respond correctly. For instance, the service may be alive, but the server run out of disk space or suffering another problem. In that type of situation the SMTP server will respond with an error code other than the '220' everything is OK code. To check your SMTP status more thoroughly you can add '220' to the 'check response for' field. This will ensure that your SMTP server is not only alive, but isn't suffering some other issue that will prevent it accepting email.

If you just do the above, then Netmon will alert you when the POP port is no longer alive. However, there are many occasions when the POP port is alive, but the service cannot respond correctly. For instance, the service may be alive, but the server run out of disk space or suffering another problem. In that type of situation the POP server will respond with an error code other than the +OK' everything is OK code. To check your SMTP status more thoroughly you can add '+OK' to the 'check response for' field. This will ensure that your SMTP server is not only alive, but isn't suffering some other issue that will prevent it accepting email.

You can also supply the username and password of a valid account on the server. If supplied, netmon will try and authenticate to the pop server with those details, and alert you if the account cannot be accessed.

Once you have created the zone file, add your individual IP records. These can be added by adding a record type of 'PTR', setting the name column to the value of the IP address, i.e. 1, 4, 15, or 234, and setting the 'data' column to the name you want your IP to resolve to, i.e. 'host192.mydomain.com.'. Make sure you remember the trailing dot (.) after the name if you list it in full.

The following article may also be of interest to you http://www.mtgsy.net/kb/default.php?category=&ID=3027

keywords : reverse ptr

2 of Microtech's name serves are currently .DK registered and approved for use with .DK names by DK-Hostmaster.

The name servers you should delegate your .DK domain names to are dns0.mtgsy.com and dns3.mtgsy.com.

Please let support know if you require any assistance or have any questions.

Microtech is an approved member of UKERNA for the purpose of submitting domain requests for registration in the .ac.uk and .gov.uk name spaces.

Please contact sales@mtgsy.net for details of charges as they may vary depending on your Janet membership.

Please note these domains are only available to qualifying organisations, and not individuals.

mail.mtgsy.net
mail2.mtgsy.net
mail3.mtgsy.com

Be sure to note that mail3 is .com, not .net as per the first 2 server names.

Please add the servers in the order above, i.e. so that mail goes to mail first, then mail2, then mail3. Typical MX preference values would be as follows

mail.yourodmain.com 10
mail.mtgsy.net 20
mail2.mtgsy.net 30
mail3.mtgsy.com 40

To transfer a .uk name from 123Reg to Microtech, you can follow this guide.

Please note, that the 123Reg's web site may change at any point in the future without our knowledge, this guide may become out of date, though we will do out best to keep it accurate.

The following basic steps are needed

Login to the 123Reg control panel with your username and password as provided by them

Select your domain name from the drop down list and choose 'modify domain'

Choose the option to change the IPS tag. Enter MICROTECH as the new IPS tag.

Once you have confirmation from us that the transfer is complete, you should update the name servers within 24 hours if you need to. 123Reg DNS, if you were using it will stop approximately 48 hours after you transfer away the domain. Failure to update your dns with us or another provider before then will mean your domain might stop working.

To setup dns on our web site for the name after it has transferred, click the name in the management panel. Choose the option to update the dns servers, click the button to set the name servers to Microtech's. Once you have done this, choose 'enable dns for a domain' from the dns menu and follow through the steps to setup dns for your domain. Please log a call via the support centre if you need any assistance.

This provides a diverse infrastructure to serve dns for clients all over the globe.

Firstly, in most cases, the uptime of single servers doesn't necessarily mean much to reliability when you are talking about major networks such as mail or dns with multiple redundant sites.

So, is 99.9% better than 99%. Is someone really saying their server has 99.999% uptime? The actual downtime for each '9' is listed below.

For any individual server, 99.999% is pretty unrealistic if you are maintaining it. Considering the reboot time alone is likely to exceed this, what about security patches etc that must be installed?

When we talk about the uptime of a 'service', this is completely different. Microtech publishes live uptime figures for all critical servers on the status page here. Most the uptime figures are conservative as if the monitoring server get's disconnected, even though the servers are up, the server counts some downtime as it cannot reach them. Still, most of our servers provide recorded uptime in excess of 99%. Does this mean we have 3.7 days downtime? No. Consider the dns network. There are a minimum of 4 sites. If a single site fails, dns resolution continues with almost no perceptible difference. DNS is a robust protocol and simply gets answers from the other servers. You could easily consider our dns uptime to be 100% based on these figures. The same follows for the mail servers. Simply because 1 server is down right now, the rest are still working, and the service, as a whole, is still running.

We can happily take down a dns server for maintenance. Yes, it will affect it's individual uptime, but it will not affect the dns service as a whole. Multiple servers in redundant locations are far more important, and in most cases, considerably cheaper to provide than the much sought after 5 9's uptime.

We hope this gives users something to thing about when considering uptime, especially as people sometimes consider it important in making service provider decisions.

If a user gets a bounce message stating 5.1.1, message rejected for spam reasons, either their own or their ISP's mail server is most likely not configured correctly.

In particular, check the senders email address and make sure that all the mail servers listed as MX records for that user actually accept email for it.

If you use the SmarterMail product, there is a bug which causes all mail address with the word 'postmaster' in them to be rejected. This is covered in a post on their own board here http://forums.smartertools.com/forums/post/26708.aspx. If you remove this 'postmaster' rule from the senders mail server the issue will resolve itself.

This message only gets used if the senders mail server rejects attempts from us to send the user an email. If the mail servers report that they cannot accept email for the senders address, there is no return route in any case, and the address is assumed invalid.

If a user gets a bounce message stating 5.1.1, message rejected for spam reasons, either their own or their ISP's mail server is most likely not configured correctly.

In particular, check the senders email address and make sure that all the mail servers listed as MX records for that user actually accept email for it.

If you use the SmarterMail product, there is a bug which causes all mail address with the word 'postmaster' in them to be rejected. This is covered in a post on their own board here http://forums.smartertools.com/forums/post/26708.aspx. If you remove this 'postmaster' rule from the senders mail server the issue will resolve itself.

This message only gets used if the senders mail server rejects attempts from us to send the user an email. If the mail servers report that they cannot accept email for the senders address, there is no return route in any case, and the address is assumed invalid.

What happens when a mail server wants to deliver mail to your domain? This is a several step process. Firstly the remote mail server will ask for the dns servers for your name. If they cannot be found for whatever reason, the mail will in most cases be permanently bounced immediately. This is why it is so important to have a reliable set of DNS servers on a different network to your own. If you DNS is up, but your mail server is down, mail will most likely still come through later even if the sender gets a few delay messages in the meantime. Without dns, all your mail bounces.

The next step is to ask for a list of the mail servers who handle mail for your domain. These are the MX records. These each contain the following information

Domain name we accept mail for | host name of the mail server | preference value

If we have no MX records, some mail servers will then try the host domain, but we consider it essential that you add MX records if you want to ensure reliable mail delivery for your domain.

If the dns server has returned a list of mx records such as the following

mtgsy.net | mail.mtgsy.net | 10

mtgsy.net | mail2.mtgsy.net | 20

Then mail.mtgsy.net is contacted first and the message is sent there. If no contact can be made with the mail.mtgsy.net, then mail2.mtgsy.net is tried, and so on. You can add as many MX records as you like in this manner. Note it is the lowest preference value that is used first.

What if you have a large amount of mail and want to load balance it between 2 or more servers? There are several ways to do this, but one is with MX records. On Microtech DNS servers, if you specify the same preference value for 2 or more MX servers then the connections should be more or less evenly distributed between the hosts.

Tips
In most cases, set the TTL record on your MX records higher than the default. If you normally set your dns record TTL's to 3600 (1hour), set the MX's to 1 day unless you are expecting to change them. MX records point to host names, not IP addresses so they are unlikely to change.

Never point an MX record to an IP address. You must always create and A record for the host name and IP address and then point the MX record to the host name.

Never point an MX record to a CNAME. Whilst this might work for some mail servers it will just confuse them and it's not valid anyway. Don't do it!

A great use of this is where a single web site hosts multiple web sites. Each site is probably www.somthing.com. There are probably may sites pointing to the same server IP. Should this IP ever change it would be necessary to change all the 'www' records for all the domains. If you however CNAME the www records to one master domain, then you only have to change that master domain www record for all the others to change automatically. This is a fantastic time saver, especially if you don't control the dns for some of those domains.

Advantages
Much easier to manage than specifying each A record in each domain individually.

Disadvantages
Causes 1 extra DNS lookup. One lookup needs to be made for the CNAME, then one for the A record it is CNAMEd to. In reality this is probably only 150ms or so, but it could be an extra performance hit on very busy sites. Microtech DNS servers automatically get around this by looking up the A record internally as long as both domains are hosted on our servers and only serving the A record, thus saving the extra record and improving performance.

Tips
It can be worth setting the TTL on CNAME records slightly higher than other records as they are less likely to change. Even if the A record changes, the CNAME will still be pointing to the same place.

Cannot be used with MX records. Do not point an MX record to a CNAME.

Do not CNAME the host domain, i.e. CNAME is OK for host records such as 'www', but do not cname the actual domain itself.

Many domains are often pointed to the same servers and share common dns information. This is often the case if domains are for the same client, or are all being hosted on the same server.

Microtech already has time saving features that enable you to set default zone files and create new zones based on zones that already exist, but templates go much further than that.

Imagine the following scenario. You have 250 domains hosted on your current web server. You decide to host elsewhere and the IP of the WWW record changes. What do you do? With template based DNS you simply update the master template and all the zones based on that template also update in real time. Adding, deleting, and changing records in the master zone affects all the domains based on the template.

You can build as many templates as you wish. This enables you to create templates for groups of domains, say those belonging to a particular client that have common settings. Next time the client asks for the 'www' record to be updated on all their records, or an MX record added to those 200 domains, it'll be a 30 second job to update them.

To setup templates visit the management panel and click the 'DNS Templates' tab on the domain listing. Any existing templates will be listed, and from there you can enter the domain name you want to base the new template on (they must be based on an existing zone) and a description for that template. When you enable the dns facilities on a domain or create a new zone file you'll be given the opportunity to create those zones based on any existing templates. The newly created zones will stay associated with that template and any changes made to the master zone will be replicated to all zones based on the master unless you 'dissociate' the zone from the template via the link on the dns editing for that domain.

Note that if you make changes to a zone file based on a template, and not to the master template, the changes will not be replicated elsewhere. This is intentional and allows you to still have domains based on template but retain the ability to add single extra unique records where required.

If you do not have templates in place but are looking to bulk insert, delete, or update dns records in multiple zones, please look at the 'Bulk update' feature on the 'DNS' menu.

If the problem persists you may delete read emails from your inbox using webmail at http://www.mtgsy.net/webmail. Our webmail product does not suffer from the same fault and will enable you to read / delete the email that outlook cannot handle.

DNS records can be changed for entire groups of domains by selecting 'Bulk Update' from the DNS menu.

This facility also allows for the delayed update (i.e. scheduling) of the updates.

It is important to note that this may not be possible due to restrictions on the existing system, but our systems will take a 'best guess' in any case using publicly available information. This facility works in the following manner

1. We attempt to get a zone transfer from each of the current authorative dns servers. This is the most effective and accurate way to transfer your zone. It enables us to see every record that has been configured and ensures the zone will be completely transferred. This option is sometimes not available due to zone transfer restrictions on other dns servers.
2. If option 1 fails, we poll all the common records that should be available for any publicly available domain name such as 'www', 'smtp', 'pop', etc, including the current MX records, and add them to your zone file. This option will not find any records that are not using common names, but it should save time and bring across any records that are ordinarily used for your website and email.
3. If neither of the above can be completed we will setup the zone with your default zone file
4. If you do not have a default zone file, a simple, minimal zone file will be created for this domain.

The dynamic DNS update protocol is very simple and can easily be integrated with scripts, clients, routers etc. The protocol is described in detail here

You cannot make on demand requests for the release of emails to Microtech. This must be done via the spammanager pages or your own support staff. If you do not have a spammanager account you can get one here

Microtech will be happy to provide assistance in using the spammanager pages if you require help.

To exempt your mail account or domain from spam checking, contact your support department and ask them to log a call with us.

After deletion, the mail cannot be recovered.

If you find spammanager is detecting mails as spam and if should not be, there could be a variety of reasons for this. If it happens too often you can use the 'request whitelist' button on the queue status page to request we white list the selected items. This will prevent the sender from being blocked in the future.

White list requests are dealt with on a very regular basis, but please allow up to 10 hours for your request to be effective on all servers.

If you find yourself receiving a large amount of spam from certain sources, please forward the email complete with full headers to your support department who can log a call with us to investigate whether the source can be blocked.

Spammers try to create new ways around the spam filters daily. From time to time they will manage to get emails through the filters. We are always working to modify the filter to catch such emails and any new methods the spammers use.

This effectively means that you do not have to continuously visit your spam queue to check for items that may have been delayed as this is part of the standard service for most of the mail services.

Making sure the "Leave message on server" option is NOT checked may also help.

Making sure the "Leave message on server" option is NOT checked may also help.

For an example of how to do this with outlook express, please see here

The fail over feature provides a way for you to direct traffic to another host if the service on the primary host fails. You can fail over hosts in a DNS zone by setting up appropriate fail over tests on the Netmon service.

Once you have configured a test using the netmon service :

In the 'Domain name' box, put the name of the dns domain that the fail over relates to, i.e. mydomain.com. This must be the name of the domain that the records you want to fail over are in. This zone must be present on the microtech dns servers. The records you want to fail over must also exist in this zone.

In the 'DNS records to fail over' box put the records you want to fail over in the following way

recordname;Normal_ip_address;Failover_ip_address

For example

www;192.168.1.11;10.101.5.1

The above means that the 'www' record in the 'mydomain.com' zone will be set to '192.168.1.11' under normal circumstances. Should a fail condition be detected, the 'www' record will be pointed to '10.101.5.1'. If the original server is detected back on line again, the 'www' record will revert to '192.168.1.11'. Make sure there is a carriage return after each line.

If you want to fail over more than one record, add them on subsequent lines, i.e.

www;192.168.1.11;10.101.5.1
smtp;192.168.1.11;10.101.5.1
pop;192.168.1.11;10.101.5.1

Notes

The URL or hostname you use to test with should not be once of the records that fails over. The reason for this is that once the test has failed, the hostname's IP will change, and the test will be testing another host instead of the original. This will have the affect that the test will not fail back to the primary host. You should use an IP address or static hostname for the test host.

HTTP tests should not be to pages that redirect. The test is looking for a 'good' response, and a redirect etc will not be seen as such.

Fail over on HTTPS services can only be made using a URL that matches the SSL certificate as a valid test url.

key words:

failover, fail over, dns, failback, fail back

Mail.mtgsy.net
Mail2.mtgsy.net
Mail3.mtgsy.com

You will most likely have to set a preference value, or 'aux' value, we suggest mail be 10, mail2 20, mail3 30.

Please ensure you set them accurately as listed above.

If your dns is hosted here the system will automatically make the above changes for you where possible.

If you dns is hosted elsewhere, please contact however manages your dns to have these changes made. If you need assistance, please log a call via the support centre.

If you have miss spelt the name and require it correcting we can log a request and they will investigate, but you must follow the above procedure if it is a name change or transfer to a different legal entity such as a company.

Please note that the transfer forms printed on the back of the old Nominet domain certificates are no longer accepted by Nominet.

This article applies to Nominet .UK names only.

For more information, read RFC 2782.

example: `0 9 server.example.com.' (FQDN)
example: `0 9 server' (hostname only)

Yes, Microtech DNS supports internationalised DNS via their punycode ASCII equivalents.

The current worldwide DNS system supports ASCII characters only, this means that domains such as

職業.jp or 雇用.jp (if you hold your mouse over these links you may see the real url)

cannot be entered into or supported by the current dns system.  To get around the ASCII limitation, these symbols are run through the ‘nameprep’ algorithm which translates the symbols to an ASCII equivalent.  This ASCII equivalent, prefixed by the four character string ‘xn—‘ is used to create your zone file and is the name actually used for dns lookups.  Entering the full ASCII string into browsers supporting IDN’s will result in the ASCII string being converted into the proper language symbols, and vice versa.  IE7 has built in support for IDN’s, as does Firefox.

Internationalisation of the TLD, for example,  .中国 (.china in Chinese), is not supported by ICANN and thus is only available via domestic Chinese registrars.

Keywords: internationalized international IDN

To transfer a gTLD domain from UKREG to Microtech, you need to do the following*

Login to UKREG's website via the 'members pages' logo.

Select 'Configure Domains, hosting, and web mail'

Click on the domain you want to transfer

Choose the option to 'Unlock' the domain for transfer

If the domain is a .info, .org, or other domain that requires an EPP transfer key, choose the option to 'Video/Modify domain authorisation code', and make a careful note of the authorisation code shown as you will need this when you request the transfer on our site.

If you require any assistance at any point, please do not hesitate to log a call via the support centre.

*Correct as of 13.01.2006

Microtech fully supports and recommends the use of SPF records where possible. All Microtechs DNS services support the TXT records required to implement SPF.

SPF records are simply TXT records added to your DNS zone file that list the mail servers that will be responsible for sending email for your domain. When another email server receives a mail claiming to be from someone@yourdomain.com, the remote mail server can check the SPF record, if it exists, and verifies that the mail server it came from is listed as a mail server that provides mail sending services for that domain. There's no specific rules as to what to do if it doesn't. Some servers will reject it, others tag it as possible spam etc.

Why is this useful? A great deal of spammers send out mail using other peoples domain names. This is not only inconvenient due to the flood of emails you will get, but it could quite possibly be damaging your business reputation etc. At the very least, it doesn't look good. SPF helps prevent this happening.

If an email passes the SPF check, you will at least know that it originated from one of the servers listed in the SPF DNS records for that domain. This can also make it possible for ISP's etc who run spam filters to skip at least some of the expensive spam processing.

Microtech has an SPF wizard to help you in generating SPF records for your domains.

Most domains cannot be transferred until they are more than 60 days old. Domains cannot be transferred if there is an outstanding balance owed on them or if they are locked. You can check the domain lock on your domains by clicking on the name in the management panel.

If you are transferring a .uk domain away from Microtech to another TAG holder, there is no charge providing you use the free and automated routines on our website. If you require us to make the changes manually for you there is a £35 charge to cover the extra time and security checks involved.

The easiest way to reliably update your IP address automatically whenever required is to use one of the downloadable clients. You certainly should not be updating your IP any more than every 10 minutes.

For a pop-up description of the most common record types click the link

- A
- MX
- CNAME
- SOA
- NS.

There are lots of other less frequently used types. If you are interested in finding out more, we recommend you read RFC1035.