I'm trying to set up my root domain as my link in the link settings form.
when I put it I get this warning.
Domain is incorrectly set up; please use the nameservers below as your
NS record. A CNAME record is not required. If you've already done
this, note that it can take up to several hours to propagate.
ns-907.awsdns-49.net.
ns-1438.awsdns-51.org.
ns-1683.awsdns-18.co.uk.
ns-401.awsdns-50.com.
So I changed my ns in goddady to those
now if I run $ host -t NS getgogro.com I get 2 different outputs randomly
getgogro.com name server ns64.domaincontrol.com.
getgogro.com name server ns63.domaincontrol.com.
I believe this 2 are still godaddy's default dns, but I dont always get that output
and http://getgogro.com/ already takes me to branch.io
but in the Link Settings section I sell get the same warning
Domain is incorrectly set up; please use the nameservers below as your
NS record. A CNAME record is not required. If you've already done
this, note that it can take up to several hours to propagate.
ns-907.awsdns-49.net.
ns-1438.awsdns-51.org.
ns-1683.awsdns-18.co.uk.
ns-401.awsdns-50.com.
Thanks for reaching out to Branch. Let me follow up with you directly via email!
Related
I want to use branch.io fro deep-linking but my custom domain doesn't register with the service.
At link settings, where I define my custom link I have this message:
Domain is incorrectly set up; please use the nameservers below as your NS record. A CNAME record is not required. If you've already done this, note that it can take up to several hours to propagate.
ns-1104.awsdns-10.org.
ns-19.awsdns-02.com.
ns-666.awsdns-19.net.
ns-1742.awsdns-25.co.uk.
And this is how I've set it up in my domain settings (goDaddy):
I've done this about 3-4 days ago. What am I doing wrong?
How do you change name servers for your .is domain at ISNIC ?
In my case, the domain zipcode.is has the preconfigured DNS, pointing
to ISNIC domain-parking service nserver: parking00.isnic.is and it
seems pretty hard/confusing to change it. Apparently, no sign of how
to actually change the DNS in their documentation.
-
Step 1.
Register your Name Servers at ISNIC - Menu > Nameservers > Register
Hostname is your Nameserver e.g. NS1.YATKO.COM (in my case)
Zone Contact (NIC) is your username, find it in My Settings
*you may run into issues like Nameserver NS1.YATKO.COM does not appear to comply with ISNIC's technical requirements and you’ll need to add PTR records to your DNS zone
-
Step 2.
If you managed to get trough Step 1. then Check domain setup with ISNIC’s tool, where simply disregard ISP, enter your Domain name, Master nameserver (e.g. NS1. …) and Nameserver 2, 3, … .
-
Step 2.1
You will likely get an error like this:
Test results for “NS1.YATKO.COM”:
No NS records found for domain ZIPCODE.IS on nameserver …
Test results for “NS2.YATKO.COM”:
No NS records found for domain ZIPCODE.IS on nameserver …
Fix it by adding the DNS Zone to your server. On a cPanel server, this means creating a new account (where you’re using your own name servers as NS1 and NS2, …).
-
Step 3.
Go to Contacts > My Page and under My domains check the domain you wish to modify. The list to the right becomes active. Select Web forwarding and under Domain delegation select Custom. Change your Nameservers and Sumit.
… no comment. If you dare to defend ISNIC’s solution, please do so. I am really curious how they invented the solution, and if anyone else in the world agrees with them :-)
I have inherited a web server that is hosting 5 websites for my client. Call them domian1, domain2, etc I just discovered that all the domain nameservers for all 5 domains are set to ns1.domain1.com and ns2.domain1.com. The single server is running the DNS for all the domains including domain1.com. ns1 and ns2 are both pointing to the same web server.
Aside from the fact that there is no redundancy, and the domain1 name servers are using the DNS to resolve their own IP's, why would anyone do this? Am I missing something?
There are two options when creating NS records for zones:
1) Set the NS record of each zone to point only to itself. Hence, domain1.com would get ns1.domain1.com, etc. The advantage of this is that the remote site doesn't need to do a cross reference to somewhere else and go look it up too. EG, if you have domain1.com's NS records pointing to ns1.domain2.com, then a lookup of the NS records for domain2.com have to be checked too to ensure it has the right location to go lookup where ns1.domain2.com really is. You could imagine the case where domain2.com's NS records point to domain3.com's name servers... This is obviously inefficient and results in a lot of unneeded chasing. So... pointing entirely internal seems like a no-duh, right! Less chasing! But... it also means you need to keep com's notion of your name servers in sync with your notion of your name servers, and when you add or remove them and/or change the IP addresses, you need to notify your com (through your registrar) that things have changed. (tech speak: update com's notion of your glue records).
2) Add an NS record pointing to an external server. This is common for server farms that sell you DNS services as part of their transaction as your registrar (ie, where you went to go buy domain1.com). They set your NS record to something like "ns1.godaddy.com". In your case, the previous zone owner set the NS records to all point to the domain1.com zone. This is actually helpful when you expect to change your address in the future. Rather than have to go change the IP address in all 5 of your zones, you only change it in domain1.com's ns1.domain1.com record and you're good to go. The other zones don't need to be touched. Yay! It's even more yay-full when you are managing 100 zones.
So, there isn't a right or a wrong here... It's a trade-off and different administrators do different things. Feel free to change it to the other model if you don't mind the zone-editing maintenance if you ever change anything. Personally, it's what I do when possible too: I like them internally self-contained. But then, that's also when most people fail to update the parent's glue records to match and there are tons and tons of zones in the world that are out of sync for exactly this reason: "oh, I'll do that tomorrow".
Let's say I have a server (DNS and other), myserver.com. Now I register a domain, mydomain.com, and set it's NS at the registrar to myserver.com - it is therefore the authoritative server, if there is any such thing.
In the authoritative records for mydomain.com, can I set the NS to ns.mydomain.com?
I have two domains set up like that, one works, the other one seems reluctant to propagate. So I'm wondering if there is something wrong with that - I mean how can you resolve the name of the NS when you need to resolve the name of the NS to resolve the name of the NS...
And, If yes, how come parallels plesk sets them automatically in this way?
Ps: there is an A record for ns.mydomain.com on that same server, pointing to the proper IP
There's a solution for this problem - it's called "glue records", i.e. A records hosted in the parent zone that contain the IP addresses of the name servers.
See http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
Why would you want to set the NS record for the "mydomain.com":
to "myserver.com" in the delegation record that goes into the parent zone (com.), but
to "ns.mydomain.com" at the zone apex (inside the mydomain.com. zone)
? This creates an inconsistency (two different DNS servers answer the same question with two different answers) without any apparent benefit. You should try to help the DNS system as a whole issue consistent answers.
Unless you have a good reason to make the DNS inconsistent, you should decide what the correct, canonical name for your nameserver is, and publish that name in the NS record both in the delegation and at the zone apex for "mydomain.com".
That being said, it will still work:
If a recursive resolver which does not yet know anything about "mydomain.com" asks about it, it will be told by the gTLD servers to go look at "myserver.com". The gTLD will also issue A and AAAA glue records to help find "myserver.com", but even if they don't, you have A and AAAA records for "myserver.com" in the "myserver.com" zone file (right?).
If a recursive resolver which wants to refresh its cache for the "mydomain.com" NS record, it may query the authoritative server it already knows about. This server will answer that the nameserver is "ns.mydomain.com", with a glue record. This is different from what it had in its cache before, but ultimately it will map to a server with the same IP address.
As for "parallels plesk", I know nothing about that.
I setup a couple of nameservers and updated my domain to use them, and as far as I can tell everything went fine and the nameservers have been updated, or so says every whois and dnstools type site ive used, (intodns, who.is etc are all saying the same thing: the new nameserrvers are in effect, and the site points to the new ip just fine). Problem is that The site is not showing up, and dig tells me that the old ip/nameservers are still effective.
In my DNS Records I have:
domain. A IN NS ns1.newnameserver
domain. A IN NS ns2.newnameserver
ns1 IN A newipaddress
ns2 IN A newipaddress
domain. IN A newipaddress
I'm very short on time and haven't found anything on the interweb, so any help would be much appreciated
The old IP address is probably being cached by the server you queried. First of all, check that BOTH your new authoritative nameservers are publishing the correct address by querying them directly with dig:
dig #ns1.newnameserver domain. a
dig #ns2.newnameserver domain. a
Assuming those queries give correct answers, dig some other servers that aren't:
dig domain. a # Use the system's default resolvers
dig #8.8.8.8 domain. a # Use Google's public resolver
dig #some.other.ip.address domain. a
If it gives the old answer, look at the TTL. That's the numeric field listed in the answer just after the name and before "IN". That's how many seconds you have to wait until the server you queried discards its cached data and will query the authoritative servers again.
Ask those same nameservers where they think "domain." is delegated:
dig domain. ns # Use the system's default resolvers
dig #8.8.8.8 domain. ns # Use Google's public resolver
dig #some.other.ip.address domain. ns
You want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver", but the resolvers likewise cache that information so they might still have the old nameservers. If so, look at the TTL on those NS records too. If the TTL on those records is longer than the TTL on the A records, those resolvers may still go to the old nameservers to get "domain."'s A records even when their currently cached copy expires... so you may need to wait for that TTL to expire first, and then for the TTL on the actual A record to expire again!
Another thing you can do is query some of the authoritative nameservers for the PARENT domain of your domain to see if they are indeed delegating it to "ns1.newnameserver" and "ns2.newnameserver". This will verify that the delegation in DNS matches what's in WHOIS.
dig com. ns # If your domain's parent domain is "com."
dig #<one-of-the-servers-that-resulted-from-that-query> domain. ns
Again, you want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver".
If the old nameservers are still running, either:
make sure they aren't, or
make sure they've also got the new zone data
Some people will still be talking to the old nameservers, and until they either stop answering or give the right answer, they won't learn the new nameservers from the parent zone.