We have several servers on AWS VPC, but all have a 'public' face via DNS, handled with Route53. The problem is that when one server looks up the address of another server via DNS, if the entry is an 'A' record, it gets the public IP, not the AWS 'private' IP, and transfers go via the external network address.
If on the other hand I configure the domain as a CNAME pointing the the AWS public DNS name, like this:
CNAME super.domain.com ec2-1-2-3-4.compute-1.amazonaws.com
then lookups from 'outside' the VPC get the real external IP address, and lookups from 'inside' get the local 10.x.x.x address. This is exactly as I want it. Now the problem comes that these servers need to send mail, and pretty much everyone (mailgun, mandrill, etc.) requires SPF and DKIM records. But you can't mix those TXT records with a CNAME.
I know I could use /etc/hosts files on the servers to pre-empt the DNS lookup and use A records, but there are 14 servers and growing, and every time one of them is restarted, I'd have to update all the hosts files - seems like a recipe for messing things up.
My question is this: Is there a way to set up AWS Route53 so I can take advantage of the automatic internal/external resolution of the Amazon public DNS name, and still provide effective SPF and DKIM records? I did ask this on the AWS forum, but didn't get any help there...
Mailgun is probably closest, in that you can use a subdomain for the SPK/DKIM records (e.g. mg.super.domain.com), which then doesn't clash with the CNAME records. But then you hit this problem, the solution to which appears to be an A record, and I'm back to having to maintain many records when the instance IP addresses change!
Related
I'm in the process of migrating a bunch of stuff over to AWS and I've hit a bit of a snag in relation to Route53, specifically with vanity nameservers.
Current setup (not on Route53);
ns1.example.com - Glue records pointing to IP address of current DNS provider
ns2.example.com - Glue records pointing to IP address of current DNS provider
Various domains, all set to ns1.example.com for their authorities nameservers at the registrar;
website-one.com
website-two.com
etc.
So I've been doing some testing with getting this migrated to Route53, and I'm not sure this is straight forward to do when you want to use a single vanity nameserver across multiple domains. When I create 2x hosted zones in Route53, they get different nameservers that Route53 automatically generates, i.e.;
example.com Hosted Zone - ns-123.awsdns-456.com
website-one.com Hosted Zone - ns-789.awsdns-321.com
website-two.com Hosted Zone - ns-987.awsdns-654.com
etc.
As such, with there only being one option at the registrar for example.com to configure the Glue Records;
ns1.example.com - pointing to IP Address of the Route53 nameserver, i.e. ns-123.awsdns-456.com (1.2.3.4)
ns2.example.com - pointing to IP Address of the Route53 nameserver, i.e. ns-123.awsdns-456.net (1.2.3.4)
Then I'm a bit lost as to how you're supposed to get this kind of setup working in Route53.
The reason for wanting this is to avoid having to go messing around with the nameservers at all of the different domains, some of which I can easily access, others are a bit of a pain to get access to so they can be updated.
Thoughts on how to best approach this?
I've setup my personal website with github, figured out the DNS configs based on the following page. I used A records because those are used in Route53 configs and when I test my DNS routing for mydomainname.com with Route53 tool, I get the proper response.
i.e. the DNS returns me the required GitHub IPs as I configured. However, when I try to run dig mydomainname.com I get an empty response.
I'm confident that I've waited long enough for changes to propagate (probably more than two full days now) so what could be the issue here? Any advice on how to further troubleshoot the routing issues?
UPDATE:
Looked up my url's who is data.
DNS Hosting works with 2 steps: configuring the dns servers to answer queries, and delegating the domain to them.
The first part you seem to have working: you've set up a Route 53 Zone, configured the records, and have successfully resolved them from one of the nameservers in the NS record Route 53 configurd for you when you created the zone.
The second step is essentially to tell your registrar that when the public attempt to look up the domain, they should be referred to the route 53 servers you configured. By adding these same dns servers from the NS record in the working, public route 53 zone, you will delegate dns on that domain to those servers.
You registered your domain on amazon so it created a route53 zone for you, with matching DNS servers in it. Either you removed this zone or created another one. That's fine to do, but each zone costs 50 cents a month, so get in the habit of removing ones that aren't working. You can create any number of route 53 zones to serve the same domain, but the ones you put in the registrar are the ones the public will use to resolve the domain.
Once whois mydomain.tld ( or a web equivalent, if whois isn't available in your environment, like from your screenshot) shows the same nameservers that you can successfully query against with dig, you're golden. It might take some time for the registrar's setting to propagate; in practice this is typically on the order of minutes.
I wanted to create an Alias record that simply points my naked domain name (zone apex) to a simple elastic IP address associated with a single EC2 instance. But that type of target isn't valid. It looks like the Alias Record targets are only limited to
Elastic Load Balancers (ELB's)
S3-Endpoints
Cloudfront Distributions
Other DNS Record Sets.
Can anybody shed some theoretical light as to why I am unable to use the A-record to point the domain to a simple EC2 with an ip address? Thanks.
Basic DNS 101
Yes. Create an A record containing the IP address of your instance. It isn't an alias, and it shouldn't be an alias.
Your issue is that your web server itself or Wordpress is misconfigured and is actively issuing redirects to what it wrongly believes to be the correct/desired name, which has nothing to do with how this A record is provisioned. Review your response headers and you will find a 30x HTTP response coming from your web server.
I have a domain (for example test.example.com) that I wish to forward to my own network for Active directory purposes. The network already has a static IP address, and a DNS server set up that is successfully handling requests for the Domain controller internally.
What I can't figure out is how to set it up so that I can connect to the Domain Controller from outside my Local network.
We use Names.co.uk for hosting, I've been messing around with the DNS settings for about a week, but the names will not resolve. can anybody explain what I need to dO?
FYI I've tried adding the SRV records to the names.co.uk DNS server, but they do not resolve back to the DC, I've also tried adding a NS record for the names.co.uk DNS server to get my DNS to resolve it, but that doesnt seem to work either!
DNS is resolves names using a hierarchy, with each level requiring NS record listing the low-levels. E.g. test.example.com: the 'com' zone has NS records for the 'example.com' nameservers and the 'example.com' zone has NS records for the 'test.example.com' nameservers.
So, not knowing your domain name, I can't check how it resolves. But I can say that to make it visible to the rest of the world, you need to have NS records created in the parent domain which point to your own nameservers (which should also contain NS records for your domain to pointing to themselves).
I have someone telling me that DNS servers only start responding after the whois record is updated to point at their DNS servers. Is this normal behaviour? Or should a DNS server respond before the whois record is updated?
Also, once the domain is active, (so either after the domain is added or after the whois record is update, depending on the answer to the above question) how long till the name servers should start responding?
I'm not referring to the time that it takes to propagate acorss the internet, but just the time on the name server for the domain. I am also not concerned with when the rest of the internet sees the change, only wondering when that DNS server should respond when using a command such as:
nslookup www.example.com ns1.dnsserver.com
For the DNS servers to be found what you call the whois record must know where to find them.
Stricly speaking, the whois record contains much more than just the DNS servers for a domain, but let's not nitpick.
Say your DesktopA needs to connect to example.com, the following servers will be contacted, assuming the answer wasn't already cached by your ISP's DNS or the local machine.
DesktopA has DNS settings pointing to the ISP, so DektopA will ask the ISP's DNS servers if they know where example.com. is located (its IP).
ISP DNS server doesn't know, so it will contact the root domain database for com. (all Fully Qualified Domain Names end in a ., even though we generally don't use it explicitly, but you can try insert it in web requests, it should work fine).
This bootstrap list of global root servers is usually updated by the OS regularly.
The root servers will know which Top Level Domain TLD server to contact for each global domain such as .com, .org, .uk, etc.
In our example, the ISP will ask the root which server to query for com domains.
The root server answers with the IP address of one of the the .COM TLD servers.
The ISP DNS server will now contact the .COM TLD server and ask it where to find EXAMPLE.
The .COM database record for example.com will contain the 2 (or more) DNS servers registered along with the domain name example.com. These are part of your whois record.
The ISP now has the IP addresses of the DNS servers for example.com as setup in the whois. It will query the first one (or the second one if the first isn't available) and ask it: what's the IP of 'example.com'?
The DNS server for example.com will look in its records and return the A record defined for the example.com domain as IP 1.2.3.4 for instance.
Your ISP's DNS server will cache this information for a predetermined amount of time (TTL) and return the IP 1.2.3.4 to DesktopA.
Desktop A can now contact the server for example.com directly by its IP.
DesktopA may cache this information for a little while for fast lookup.
Tis would be the same for subdomains such as www.example.com or john.people.example.com. Everything before the domain example.com must be declared in your DNS server so when someone query for their address, your DNS server for example.com can look up the definitions and answer them (it could very well pass them on to another server as well if necessary).
In conclusion
So, to go back to your question, your whois record must be set with the proper DNS records for your domain before anyone can access them using that domain name.
DNS Servers operate completely separate from the Whois server. The relation of how fast DNS is updated after Whois depends completely on the registrar. A registrar or web host may update DNS within a second or 2 of a customer making a change in the control panel, or it may take minutes or hours if they make updates in batch mode.
Ideally all DNS changes that a customer request should happen very quickly on the DNS server (within a few seconds), but as you note, there may be a delay until changes propagate across the internet.