If configuring DNS and Nameservers is becoming a problem for you, I can personally help. I am very good at finding and solving DNS problems, and determining which company is at fault in an outage. Do not let your business be completely offline for days on end. Please see my Web Consulting Services page for contact information and rates. While DNS troubleshooting is not technically consulting work, I will help with DNS at the rates stated. If you want to do this yourself, the information on how is below.
I do not get paid for giving free advice online or from making the free instructional videos. If you wish to donate to the free project, so I can keep giving free resources, here is a donate button. I have donated my time, and if you do end up resolving a situation and getting something in return, then anything would be appreciated:
DNS and Nameservers are how domains connect you to the servers where the website is you want to see, or where the email you send needs to go. If you remember from the Domains page, a domain is a type of connection service. There are more than 1 billion computers on the planet. When you visit a website or send an email, your computer needs to know which specific computer on the planet, out of the more than 1 billion out there, that has the information from the site you want to visit or where the email needs to be delivered to. Remember when you watch your next YouTube video, how did your device know where in the world to contact for that video? The answer is not just “Of course, YouTube has the video, duh!” The answer is the YouTube video is stored on specific servers in a specific building in a state and country. Your device has to find those servers and communicate with them in the fraction of a second from the time you click the video until when it loads.
The first step in any complex journey is finding out just how to get to the place you want to go. An Address, maps, GPS, a compass and landmarks all can help with this job in the physical world, but what about the digital world? In that case, Nameservers are the first step.
Nameservers are somewhat like an office receptionist or a traffic cop in many ways. They are not the final destination. They are there simply to help you find and get to where the real destination you are going to is. You can think of nameservers as the ones who give the directions that get you to that server your computer is looking for. Nameservers contain all the ADDRESS information.
Where you register the domain does not directly control which hosting or email service your domain connects to. It is the Nameservers that do that. Yes the place you buy the domain from can change which Nameservers you use, but it is actually the Nameservers that do the real work of connecting the domain, not the registration provider.
One common scam that many less that reputable website developers and hosts use is to make their client think that they have to transfer the domain to the provider or the developer in order for it to function. As nameservers control how a domain works, not the registration provider, neither the website developer nor the host actually needs to have anything to do with the domain in order to do their part. Once unsuspecting domain owners transfer their domain, then they can completely lose all control and ownership of the domain, if the developer is not reputable. They can be given token access to edit small things on the website, thus giving them a false sense of security that they actually own or control anything about their site. With any payment dispute, the developer can (and many do) revoke all access to the domain, the website, and anything that goes with it. If the developer knows what they are doing, not even the hosting company they use has any legal authority to do anything about the problem. It can go to court. The point is, do not transfer the domain out of your control, ever. No reputable developer or business will ever force you to do that. If they do, they either do not know what they are doing, or they do and are trying to scam you. Either way, don’t do it. Changing nameservers at the request of the host or developer is far safer. You could still lose all your content if they try something funny, but you will keep the name.
THE EASIEST WAY of connecting a domain: If you simply just purchase the domain at the company that is also providing you with the website and email services, they typically have automatic tools that connect everything. If you are buying the domain at the same company that manages every other service that you have, typically this is enough and you can stop reading here. No need to go on further to the rest of this page.
The next easiest way: Connecting nameservers to your host. If you get website and email services at the same company, but that company is a different place than where you purchased your domain, then simply ask the company who will host your website and email what their nameservers are. Just take whatever they tell you to your domain provider and then that is that. Usually you are told to transfer your domain. That is wrong. Ignore that and tell them no way. I have seen many people delayed from building a website for between 5 days to 60 days just because they were told to transfer the domain and had to wait for that to be possible. A domain transfer is much better being the last step in the process, not the first. Just remember that you ask the nameservers from your host and give them to the domain provider. As long as your email and website services are with the same company, you are done. No need to read further on this page.
If you need to have services at more than one place, and have no choice, then the easy way is to just ask the service provider (like an email or hosting provider) for the Appropriate DNS records. You just have a copy of whatever they give and hope that your nameserver provider can make sense of what you hopefully have saved neatly so they can see. You should have at minimum Record Type(s), Host name(s), and sometimes a Priority (for MX records). Whatever you are given by your service provider, just have in a neat format and provide to your host. If they are able to, they can often do the hard work of helping you get those in the right place.
If you are on this website, then there is a good chance that not everything is going well. For those with more advanced needs such as having problems with connecting the domain, or those with services hosted at several different companies, more information to help you is further down this page. At its heart, remember you are just copy and pasting information. It does not matter too much how complex that information seems. Just try to find the appropriate place to copy and paste the information and you should be fine. Nameservers and DNS can get quite complex though. So if one of the easy methods does not apply to your situation, then by all means read on.
Types of Nameserver Records
The very first types of nameservers and records are ones that you will not deal with. The process of getting to a nameserver starts at the Root level Nameservers. If you remember that there are different type of domain extensions such as .com, .net, .org, and .guru, you may be able to see that finding each one of these is the first step. All .com domains are managed by Verisign. Each other extension is managed by different places. So you can see that all the .com nameserver records are kept one place, all .org nameserver records are kept another place, and so on. This next level of nameserver managed by the Registry (or business that runs the .com, net, or other domains). When you set the nameservers you are given, this is the place that actually makes sure they are set and working.
When you are given Nameservers by your host or other service provider, these are actually something called Parent Nameservers. The PARENT NAMESERVERS you are given by your host or other service provider must be set by the place you bought the domain name from (The Registrar or the Registration Service Provider). Who you bought the domain name from may or may not be on public tests that you can do. If you need more information about finding the provider you bought the name from, please visit the Domains page of this website for more information. Nameservers records are the most simple of all records to set typically (Unless you are dealing with custom nameservers and complex hosting types). They should look something like ns45.domaincontrol.com, ns46.domaincontrol.com, or ns1.domain.com and ns2.domain.com. They always come in a minimum of two different records, and sometimes more than that.
The process of setting Nameservers is pretty simple usually. Just ask the Host or other provider for their Nameservers (the tech support rep probably will not know what a Parent Nameserver is even though that is the record type they are giving you). Just take the nameservers to where you purchased the domain and you can set them there. Problems often come in with this process because many companies do their level best to prevent you from being able to find and change your nameservers. A nameserver is just as important to a domain as the steering wheel of a car is. Hiding the place where nameservers are set makes about as much sense as hiding the steering wheel to a car in the trunk underneath mats meant to hide it. No it does not make any sense and will just make the process difficult, yet this is how many providers like Godaddy work.
Because it is so common to intentionally hide where the nameservers can be set, one somewhat common mistake is that people often find a DNS record called an NS record instead. The NS record or a LOCAL NAMESERVERS are NOT the record you are looking for. Do NOT put the Nameservers in the NS record field. It must go where the Nameservers are set, not the NS record. I know this may sound confusing. It is supposed to be. Remember that nameservers really are the most simple type of record there is, but places that sell them are under no obligation to try to make it easy to find them. You may need to contact their support for help. Even though support at most places is a nightmare compared to what it had been some years ago, even the most rookie agent should easily be able to show you where the nameservers go.
Testing Nameservers: If you want to see what the Parent Nameservers are, you need to look at a WHOIS directory and not any other type of test. There are many websites that let you look up information on the Whois directory. Some of those sites include https://lookup.icann.org/ https://www.whois.com/ https://who.is/ or https://www.godaddy.com/whois. I DO NOT recommend buying anything at Godaddy or at the other links I provided here. I gave them as examples of places that allow you to test the Whois information which includes the Parent nameservers. Websites linked to above may try to sell you services. Buy at your own risk. If you look at the Domains, Hosting, and Email pages of this site, I will list some reputable places to get services from. Here is an example of what the nameservers on a Whois can look like:
As you can tell, in this example, the registrar of this domain has set the Parent Nameservers properly. The STATUS of a domain can in some cases prevent everything from working (example clientHold or serverHold). Unless those statuses show, what shows in a whois is almost always right.
Please be aware that there is a type of test called a DIG that is very often used to tell if Nameservers have been set properly. If you look up the results in a dig, you will likely get the same results, though there are exceptions to this. Even when working properly, a DIG can show a different nameserver name than you entered. This is not always a problem. It can be normal for certain hosts. To further illustrate how domains work, here is an example of a test that can be found at whatsmydns.net.
As you can see in the above test, something is not right. If you had an issue like this with virtually any provider, you would be put into a he said, she said type of argument. One provider would show a WHOIS and say things are set properly. Another would show this test and show they are not. Both may make you wait 24 to 72 hours and assure that your problem will be fixed with waiting for something called “Propagation“. (Propagation refers to the fact that DNS records are not just stored in one place on the internet. They are saved on your own computer, your own router, and also your own Internet Service Provider. With so many computers, routers, and providers on the planet, you can see it may take a while to have records update.) In this example, the problem is NOT propagation. You could wait until the cows come home, and it will NEVER work. You can see that some already show the correct nameservers, so why in the world will this never work? The answer is that most of the results on this test refer to the Local Nameservers. All the results that show a red X are displaying what the Local Nameserver says. The few results that show the domaincontrol nameservers are showing the Parent Nameservers, which are set correctly. This is not just a random example that never happens. I have seen many many many examples of Godaddy not setting their nameservers properly and causing this exact problem, then blaming others for it. In this example, it is not actually their fault as the domain really is not registered or hosted here. In other cases, it is.
In order to not be led in a nightmare of he said, she said by both providers which could eat up days of valuable time your website and email are down, another test is needed. LEAFDNS.COM uses one of the single most important types of tests out there for configuring nameservers. (If you do not have this site bookmarked, do so now. It is very important if you work with DNS much at all.) Here is what their results say about the problem from these examples:
To read this test, you need to look at the first statement that says “The parent nameserver a.gtld-servers.net. reports your nameservers as:” This one statement shows that the Registrar or Registration provider of the domain has indeed done their job. If it was a problem with the registration, the test would have read that the parent nameserver does not have your nameservers listed. There would be no results past that. In this case, they are reported, so that is all the Registration Provider of the domain does in this process. If you look at the big red X on the test, you can see the text “Nameserver is not authoritative for eynfaw.com.” What this means is that it is the fault of the Nameserver provider, not the domain provider. There never is an exception to this with this specific result. A “not authoritative” error is by definition the nameserver not being configured to work with your domain name. This could mean that your hosting expired, or maybe they just gave you the wrong nameservers. In the case of GoDaddy, I have personally seen them do this many many times by accident when the hosting is good and they are supposed to be the correct nameservers. Whatever the reason, the operator of the nameservers will have to fix the problem, or you will be forced to not use that company to host your DNS. There are certainly more complex errors, but there is no way to cover every possible one here. Odd problems that are not covered here may require another search on a search engine, or possibly talking to a professional that is experienced with DNS such as myself.
Types of DNS Records
If you hear the term ZONE FILE, that is another way of talking about all the DNS records you use of any type. Zone file just is another way of talking about your DNS records. Once you have a working Nameserver, it has a file of all your DNS records called a Zone File. You will only really need to know that if you are either in the industry or if your nameserver provider uses that term on their website. Otherwise just know that when you go to the company that operates the Nameservers you have pointed your domain to, it will have a web page that allows you to enter all of the different DNS records you have to use.
Before starting to work with entering specific DNS records, it is best to take a step back and make sure that you are doing things in the easiest way possible. It is very often the best practice to use the nameservers at the place that has the most difficult DNS records. For example, if your web host has a large number of complicated DNS records needed to get the website, SSL, and services running, but your email provider only has a few simple DNS records, then have the host manage the DNS and use their nameservers. Take the email related DNS records to the web host. If the situation is reversed and the email DNS records are more complex, it may be possible to bring the web hosting DNS to the email provider. The main point here is that any company can run the nameserver. Usually, the only time when you are absolutely required to use a company to run the nameservers is with a service like Cloudflare where they provide specialized services that require it. Shy of that, you can usually choose to use the nameservers of whatever company seems easiest to you, and just bring all the DNS records from whatever services you have with other companies to the provider of your choice.
The types of DNS records that you are likely to encounter on any beginner or intermediate level hosting or email plan are as follows:
A Record: This record is pretty much required on all domains that function. This record consists of a HOST name, an IP address and a TTL. The terminology DOES differ from company to company. When you have an A record, just remember it is simply just copy and paste, and make sure you get the formatting right. The only very crucial parts are usually the Host name and the IP address. Get those right and you are usually good. Read below for host name or server name information.
CNAME Record: While an A record has a host name and an IP, a CNAME always has a host name and what looks like a URL or a web address without the http part. The terminology varies for each company, but the Host name and where it points to are the important parts. There is also a TTL that honestly does not matter as much for most people.
MX Record: This record makes your email work. The email provider gives you this record. Like the CNAME record, it does have a Host name and a value it points to which should be something that looks like a URL or web address without the http part. It also has a TTL which is not that important, and a Priority. The priority is only important if you have multiple MX records given by your email provider. Unlike the CNAME, the host is almost always the same thing and is very often not told to you. It is usually assumed what the host name is, and many providers do not let you enter that. So, for an MX record, you have Host name which is not something you always deal with, value, or where it points to, the Priority, and the TTL.
TXT Record: This is a record type that just contains text. Because of that, it is used in a wide variety of ways. There is a Host name field which is sometimes used, but most of the time you will just be given a value to paste in and not the host name. It is just copy and paste here. No matter how complex it looks, just copy and paste what you were given into the spot where the text part goes, and you normally should be fine. In the case of an SFP record, you may need to adjust that. Please see the Email page of this site for more information about that.
SRV Record: If you were given an SRV record, either Microsoft gave that to you because you got email through them, or your situation is complicated enough where you probably should be having someone experienced help with this. If you can look at sites that give a more thorough explanation of this record type and can get what to do, then that is great. If you were given the record from Microsoft because you signed up for their email, do know that this is NOT an email record and it is not needed for that. There is another purpose they have for this. It used to just be used for customers who need Skype. While this may have changed by the time you read this, just know that for most people this record is not needed. If you have to get this record working and have no choice, just get the information from the service you are using, and give it to your DNS host. Just hope their customer support knows how to enter it and test it. There is too much variation in how this is entered for me to cover, considering most novice and intermediate users will never need this type of record.
Also not covered here, SOA, PTR, AAAA, and CAA. The Local Nameserver is a DNS record, but one you typically should never touch. The nameserver provider should set this and for novice and intermediate users, this should also not ever be touched.
Do note that you may be given DNS record types that are not actually listed above. They are not actually DNS record types either, strictly speaking for most. Example a DKIM record helps email deliverability. It is not actually its own record type. It is entered as either a CNAME or as a TXT record, depending on the email provider. For records such as these, treat them like any other CNAME or TXT record. You enter them and test them the same. The provider that gives those other record types to you has a more challenging job, but for what you do it is just copy/paste in the appropriate fields.
The terminology and format for DNS records WILL VARY quite a lot from place to place. It would be nice if all you have to do is copy and paste, but this is not the case. Because this varies, we need to go further into how each field varies.
HostName Host Name, or Subdomain Name: However this is called, each DNS record type has this though not all really use it much. To explain this, lets take the domain name eynfaw.com as an example. Lets pretend that you purchased that domain name and are trying to set it up. The first task is to get the website working is to make sure that it goes to the website if you enter just eynfaw.com into the browser. That specific address requires a host name of @, eynfaw.com, or it can be blank, depending on who runs your nameserver. Yes it could be entered as either. If you enter the host name @ that one symbol by itself means that it is for eynfaw.com. In other systems, they do not use that symbol and you would instead just enter your domain name (which for this example is eynfaw.com). There always will need to be an A record that has either the @ or the domain listed. The MX record always should use this same host name as well. The TXT record should almost always use the same host name @ or the domain name in question.
Important: If you are given a CNAME, you should NEVER EVER EVER EVER use the host name of @ or just the domain by itself. If you are specifically told to do so, whoever told you that is wrong. There are NO exceptions. If the help article for your host ever mentions to use that host name, they are ALWAYS WRONG, there are NO EXCEPTIONS. NEVER EVER EVER use @ or just the domain by itself as the host name for a CNAME. It is an invalid record type and will lead to massive and very hard to troubleshoot problems. The reason why there is a host or two out there that gives this as a host name when they absolutely should not is because there are one or two providers on the planet that basically autocorrect for this error so it could be technically done on their Nameservers, even though it is an invalid record type. As a rule, do not ever do that, even if asked. It is very very bad practice and you can count on one hand the number of Nameserver providers that have systems that can adequately correct for this.
Most of the time the Host name will be something like www, mail, smtp, or something to that effect. Here is where you have to think for a bit about formatting. If the goal is getting the URL www.eynfaw.com working, then your host name needs to be www (or www.eynfaw.com in some hosts). Some systems list the host name as the full subdomain prefix and domain all together and some just list the front subdomain part. If you want mail.eynfaw.com, then your host name should be just mail in some systems and mail.eynfaw.com in other systems.
Now that we know all these concepts, entering DNS records should be much easier. We first look to know the Record Type (such as A, CNAME, MX, or TXT), the Host Name, the IP/Content/Value, and sometimes the Priority (MX records have that). When entering those records in the website that controls the Nameservers, we look for the DNS or Zone File to find where to put them. The knowledgebase or help articles from your host can help you find specifically where they are at. Next, look at records that are already there to see how they want you to format the DNS records that you have to enter. If you see all the other records just say mail, ftp, www, and so forth under the Host name (or equivalent term they use), then use that shortened version. If you see all the other records use the long version such as www.eynfaw.com or mail.eynfaw.com as the example we went over, then you make sure to use the long version of the host name, even if you were given the shorthand version by the service provider. Also, for the record that refers just to the domain without any subdomain prefix, then look to see if they use @ to refer to that, or if they use the full domain name.
All nameserver providers are likely to have somewhat different formatting rules on their website, but at the end of the day they all have to work the same when they give those records to the internet at large. No matter how they format things internally, you run the tests in the same way, and should expect to see the same results.
Testing DNS Records
When you enter DNS records, you either test them and save a lot of time, or just wait 24 to 48 hours and hope. Honestly, those that get them right will usually start seeing them work a lot sooner. Those that do not may waste a lot more than the 24 to 48 hours, because they will be told to wait that after every single change to the DNS record. I have seen people waiting a week, two, or more for DNS as they were not using appropriate tests.
The first rule of testing is that every website and every email MUST ALWAYS ultimately route to an IP address. Usually it has to route to an IP quickly. A CNAME does not list an IP, but it does list a subdomain/domain that should have an IP. Remember that a computer’s address is an IP address. Just because mail.yourdomain has an MX record does not mean that whatever MX record it lists ultimately routes to an IP address. Here is an example:
I do not like Godaddy, but as they are a major player in the industry and get a lot of money from people wanting to get their sites out there, then they deserve to help others out. In this case, they can help by showing a classic example of how Microsoft 365 email should look and route. This test I am running here is called a DIG. There are many places to run a dig. The Google Admin Toolbox is one such place that is easy to use. Dig Web Interface is a more advanced test capable of more things. Whatsmydns.net is another test that shows what servers across the planet show, rather than just from one location.
In the example above, this is a very simple test to see what the MX record shows. In this case, you can see that it gives an address that lists mail.protection.outlook.com. This happens to be the format that Microsoft uses most of the time for anyone’s Microsoft 365 email service. This is a standard formatting though there are other formats they use. Typically this is all that a help line or chat rep will do. They just look at this one result and then say that it is there, working, and routing to Microsoft. It typically is good enough most of the time. Sometimes it is not though. As most will not get this far into the website unless they have an odd problem, lets go further into the test.
If you have a working MX record that lists the value that Microsoft gave you to put, and it still does not work, then you can do another test. Simply take the address that Microsoft gave to use as an MX record and do a dig on that exact record, but this time look for an A record. In this example, you can see that the value given does absolutely route to an A record. This is how it is supposed to look. Not every DNS test is going to be for Microsoft email though. The test is the same for websites that use CNAME records (CNAMES need to be on www and cannot be used on the @ record) or for any other MX record.
Remember an MX record or a CNAME of any type should list some address that has an A record. You can literally copy the value given for a CNAME or MX record and do a dig on ANY valid record by looking what it says under A record for that value given. For this example, we were given an outlook.com address as an MX record, so then we can take that and run a Dig for the A record that the address we were given routes to. It should ALWAYS have an A record. A Cname should not usually route to another CNAME, and an MX record should not usually route to a CNAME. Yes that does happen a lot. It is sloppy and can make the testing more difficult.
You should get the point though. Any record ultimately has to route to an A record and an IP to be valid. Yes you could have an MX record route to a CNAME that routes to a different CNAME, then finally to an A record, but that is sloppy and can create problems. Follow the trail wherever it leads until you get to the final A record. If you can get one, the record is either valid or valid but sloppy. If it does not route to an A record at any point, the record is not valid. Here is an example of an invalid MX record:
This example comes from a number of times I ran into this issue when helping people get Microsoft email working. This can easily apply to any domain or any email service. It is absolutely not just something for only troubleshooting Microsoft by any means. Say that we were hypothetically given the same basic type of MX record from Microsoft to use on the eynfaw.com domain. I do not actually have the service with this domain, but this is exactly how it looks with customers that do, and have this type of problem (other than the fact I cannot show their domain here for privacy reasons). The MX record follows exactly what format Microsoft typically uses. In the real world example this is based on, Microsoft confirmed several times that the MX record was valid and then blamed the host for the problem. The host blamed Microsoft and everyone just also thought it could be propagation. Remember, when you test any normal record, it MUST eventually resolve to an IP some how. As you can see, when we test the MX record given to see if it does resolve to an IP, we can see clearly that it does not. In the real case this example is based on, the customer was given an MX record that they used. The nameservers listed the MX record given by Microsoft and you absolutely can test that as showing in whatsmydns.net. The email not working was the fault that the MX record given was not configured properly by Microsoft.
Again, this is not just a Microsoft issue. Every provider has problems at some point. In the example above, it is possible that they could have been given the wrong MX record. Microsoft does at times use non standard formatting that is impossible to guess at. Whatever the reason, testing until we resolve to an IP shows that there is a server listed. Once you test until you see that your DNS record does resolve to an IP, then at that point, you can check to see if the IP matches the server it is supposed to (If that is something you would have access to check). One way or another, of there are still problems, they would be the responsibility of either A the service provider for resolving to the wrong place, or B the problem where the computer that is at the IP address is not configured or working properly. Either way, the work of the DNS is being done. Your job with DNS is simply to list the records as given. Once listed, we can make sure they resolve. Once they resolve to an IP, it becomes the problem of the computer that is at the IP address.
So in summary, DNS is very very complicated at time, but it ALWAYS has to route to an IP sooner or later (and it ideally should be sooner).
For other records like the SPF record, the DKIM or DMARC records, you can put them and test that they are being given out by the nameserver, but the value itself has to be accurate and valid from whoever gave that. One example of how to do a Dig test to see if a Dkim record is this: If default._domainkey is the host name given, then you can do a dig for default._domainkey.eynfaw.com (or more accurately for your domain, not the example domain). When doing a dig, if the dkim record was supposed to be entered as a TXT record, then select TXT in the dig test. If it was supposed to be a CNAME, then select CNAME when you do a dig. If the nameserver is working correctly and everything is as it should, you will see the value that you were told to enter on the dig. If the correct value comes up, any problems would generally be the fault of the provider that gave the record. If it does not, then it would be the problem with the nameserver. SRV records are harder to test, but most DNS records can be tested with a simple Dig tool, if you just enter the right address and look for the appropriate DNS record type.
You were given the MX record mail.eynfaw.com for your eynfaw.com domain that you own in this hypothetical situation. You take the MX record to your nameserver provider and enter that and wait for propagation. After some propagation, your email is still not working. Your email provider that gave you the record says it is the fault of the nameserver, and vice versa. How can we see who is really at fault? I will assume that you just said that we should do a dig. Well, lets do that then.
Okay. We were asked to put the MX record and it is clearly there on this dig. We did what the email provider said, so the mail should work. We are still getting errors though. Whose fault is this and how can we tell? What is that you say? See where it all resolves to? Okay, lets do that. Let us do another dig, but this time we will enter the address we were given for the MX record and see what that resolves to.
What is that we see? Oh, it looks like the MX record that we were given is either wrong or incomplete. It does not resolve to an IP address, no matter if we select IP, CNAME, or anything. There is no test we run that comes back with any IP or way to get one. The way to fix this is simple. Since we were given mail.eynfaw.com as the MX record, all we need to do is create an A record on the same domain that we already own in this example and point it to the mail server. We just ask for the IP of the email server and create an A record with the host name of mail (or mail.eynfaw.com depending on the DNS server) and use the mail server IP. That way, the MX record then routes to a valid A record, and that is then set correctly to our email server’s IP address.
There is no possible way to make everything clear here. Do your best with the information given. Try not to let the DNS records intimidate you because they can look very different than anything we normally deal with in life. It is pretty much a copy/paste job we have to do. Remember the basics, and it will solve most DNS problems. If you still need help, you can always contact an expert, such as myself, for help.