Tag Info

Hot answers tagged

11

Simplified version: A records point to IP addresses. CNAME's point to other A records. You could use an A record, but for this you should have a highly available IP address for your EC2 instance. Amazon calls this product "Elastic IP Addresses". If you set up a CNAME to an A record that Amazon manages, then Amazon has control over a layer of indirection. ...


11

The CNAME should cache for an hour (the alias value), but when the corresponding A is looked up, it will only cache for a total of 1 minute. You're talking about two independent records that are handled separately.


11

An A record is a DNS record. Specifically it's the DNS record that maps from a hostname to an IP address. Every URL that contains a domain name must go via an A record to find the IP address of the server that's hosting it. See RFC 1034 and RFC 1035.


10

There is an article here on setting up NXDOMAIN redirects: BIND 9.9 redirect zones (for NXDOMAIN redirection). Here is the example as given by ISC, but full explanation is available on their page. In named.conf, you add a new "zone": zone "." { type redirect; file "db.redirect" ; }; And then in that zone file db.redirect, you populate it with ...


9

ok, the answer is hidden in your question: ...small DNS server...at most 5 domain names... ...queries will be speed up by using A Name records... Usually DNS lookups are done rarely, and are cached in the app anyway or on the requesting system. So, this 'speed up' argument is just hypothetical. I run reasonably large DNS infrastructure that ...


9

The more specific DNS record overrides the wildcard. So your CNAME should override your wildcard A. What this might be is that you still have the domain name cached to the a record. Use the dig command: dig @yourdnsserver mydomain.freshdesk.com Normally it should return the CNAME.


8

The simple answer is that you need to manage their DNS. Get a hosting account from a DNS provider or gulp make your own DNS service. The simpler answer is to tell your clients to own up to the responsibilities of having an IT infrastructure and just change their darned DNS records. The harder / crazier answer is to have your clients CNAME their A record to ...


8

No, this doesn't work. You can't legally have a CNAME at the root of your zone, because the SOA record belongs there too and it's not possible to have both a CNAME and other RRs attached to the same domain name. Your zone file would need to look like this: $ORIGIN example.com. @ IN SOA ...... IN A <server_ip> * IN A ...


8

You can't use a CNAME record at the zone apex. This is because a CNAME record defines one name to be an alias of another regardless the requested record type. This, in turn, also means that a CNAME record cannot coexist with other records as that would be a conflict/inconsistency. The zone apex always has at least SOA and NS records, which means there can ...


7

There are two distinct options: They can continue hosting DNS for the domain and point the A record to you. This is simplest and they may wish to retain this control. But it introduces some administrative overhead because you will need to contact them if you ever need to change your IP address. They can delegate the entire domain to you. They will need to ...


7

Why do you think you can only have one A record per IP? You can have as many as you like. The first example is correct and fine. What you can't have is mutliple IP's for the reverse lookup. I think you may of confused the two.


6

so you are not looking at redirection as such (as that happens at the app level ie on apache/nginx/wherever) but rather on the DNS resolution - host on which DomainA is hosted will or should never be hit - based on your description as you want the DNS requests to be resolved to the IPs of the DomainB. Unless I'm missing something in your request ? As Shane ...


6

I'm afraid you cannot do what you are asking directly unless you want HTTPS traffic to go to e.g. secure.example.com instead of www.example.com. The only solution would be to put a proxy/firewall/load balancer device in front of your webservers that forwarded on traffic to the different IP addresses based on the protocol used.


6

If you have an A record for example.foo.com then no DNS record for any other domain will affect that. So the answer is no. Other facts to bear in mind: You can't have a CNAME and an A record for the same fully qualified domain A CNAME is not he same as a 301 redirect. A CNAME will return the same ip address as the new domain. Your browser will go to that ...


6

Just a couple of notes: Anycast doesn't really provide A record failover. You mention "external DNS failover" and roundrobin - these are not the same things at all. Roundrobin is having multiple A records for the same hostname. DNS failover is changing a single A record to a different IP address when a link goes down and, ideally, changing it back when the ...


6

If your mail server is staying where it is then I would do the following: Create a new A record for mail.domainname.com (or whatever you like really), pointing at the existing IP and change the MX record to use this at the same time. Wait a good day or so to make sure any cached copies of the old MX record disappear. (Technically, you only need to wait for ...


5

You can't put the port number in there. The IP address is 31.220.48.155.


5

Generally the best practice, for ease of maintenance, would be something like this: [A] mydomain.com 123.45.67.89 [CNAME] www.mydomain.com mydomain.com [CNAME] blog.mydomain.com mydomain.com [CNAME] www.blog.mydomain.com mydomain.com [A] mail.mydomain.com 123.45.67.89 [MX] mydomain.com mail.mydomain.com ...


5

The A record should only be delivered to if no mx records exist. If they exist but the server doesn't answer or 4xx the mail, the sending server should queue the message and try again. If the MX fails to answer and the sending server then tries the A record it sounds to me like that server is broken. Edit-.. Troubleshooting steps-- As it only happens on ...


5

Try: @ A 178.79.185.207 Your * covers every subdomain of the root, but not the root itself. What's your DNS server, by the way? If it was bind, you'd need an IN in there..


5

When changing DNS it takes some time for the changes to propagate throughout the Internet. Depending on your ISP/location it can take as little as a few seconds to 48 hours. You could use the old IP to set up a temporary webserver to notify your users of the pending DNS update and forward them to a newly create subdomain that also points to the new IP. ...


5

Try this: In named.conf: options { recursion yes; } zone "." IN { type master; file "named.root"; }; In "named.root": $ORIGIN . $TTL 1D @ IN SOA @ none. ( 0 1D 1H 1W 3H ); IN NS @ * IN A a.b.c.d


5

Have an A record for the server's primary (or "infrastructure") hostname. The websites hosted on it should then use CNAME records pointing at that hostname. The exception is if you want "bare" domain names (i.e. without a www. or similar prefix) to work. DNS rules mean you can't usually use a CNAME for those, which unfortunately means that those records ...


5

There's no way to perform this with DNS, as you have to have one IP address for a given NAME, irrespective of the protocol the options available to you are: Use a firewall/router to route the traffic accordingly to different servers. Add a new record for, for example, secure.example.com as 2.2.2.2, configure the server hosting 1.1.1.1 to redirect any HTTPS ...


5

Yes, there is a propagation delay for DNS changes because of the way they are cached. The length of the delay is controlled by the TTL ("Time To Live") value for the record. If you have not explicitly set it to something else then it will be something between 3 and 24 hours depending on your registrar. Some registrars allow you to change the TTLs (and if you ...


5

I would consider this text by Heroku you linked as only relevant for services hosted by Heroku and similar types of providers and don't think it's relevant eg. for a domain you host on a physical server (or a VM on your own KVM/Xen/ESXi) host. In the Heroku context you don't control where your service runs and Heroku wants the flexibility to move stuff ...


5

You can have multiple RRs pointing to the same IP address. Using CNAME records can be useful in many circumstances but NS and MX records are not one of them. Make sure that you NS and MX RRs point to an A record. RFC2181 section 10.3 says 10.3. MX and NS records The domain name used as the value of a NS resource record, or part of the value ...


5

I think you're badly misunderstanding how DNS work. NS records are used to find the authoritative server for a domain. The A resource record is what the client is requesting (normally) and is what will be looked up for the response to the client. Quickly-ish: Lets say you own example.com. Someone enters http://www.example.com into their webbrowser. Their ...


5

so if one mail server goes down we can automatically start sending emails from the fallover You can't (easily) have machines in different locations with the same IP address. You don't need an 'A' record to send email from a server. You cannot implement failover by changing DNS records. The important stuff is to have any server which sends emails listed ...


4

I would think the best solution would be for you to use some sort of load balancer, and have your clients point to that balancer's IP. Then you could scale as large as you want behind the load balancer and the client is none the wiser. As far as changing datacenters, unless you lease your own netblock from ARIN you will always be at the mercy of whatever ...



Only top voted, non community-wiki answers of a minimum length are eligible