What prevents me from setting up an A name entry for “google.ca” to whatever IP address I want?

Question

When I pointed my GoDaddy domain name to the IP address of the GCP VM running my web server, this is all I had to do:

1. Change GoDaddy nameservers to GCP nameservers
2. Create A/CNAME/SOA entry in GCP DNS for my domain to my IP address

What prevents me from doing the same thing for any domain in the world?

As a matter of fact, I did:

I created a CNAME, A, SOA entry for google.ca to my VMs external public IP address and nothing stopped me. Now I don't expect all of Google's traffic to start directing towards anywhere I want (that would be a fun DDOS), but what's going on here? What am I missing?

My intentions aren't unethical. I'm simply trying to learn how it all works.

Answer 1

Nothing is stopping you. However, nobody will take a look either. That’s because the real domain isn’t pointing at your name server (GCP DNS). One could only get these records by directly asking your name server for them.

DNS queries start at the root:

$ dig google.ca +trace

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> google.ca +trace
;; global options: +cmd
.                       68215   IN      NS      h.root-servers.net.
.                       68215   IN      NS      k.root-servers.net.
.                       68215   IN      NS      i.root-servers.net.
.                       68215   IN      NS      g.root-servers.net.
.                       68215   IN      NS      a.root-servers.net.
.                       68215   IN      NS      b.root-servers.net.
.                       68215   IN      NS      d.root-servers.net.
.                       68215   IN      NS      f.root-servers.net.
.                       68215   IN      NS      l.root-servers.net.
.                       68215   IN      NS      e.root-servers.net.
.                       68215   IN      NS      j.root-servers.net.
.                       68215   IN      NS      m.root-servers.net.
.                       68215   IN      NS      c.root-servers.net.
;; Received 553 bytes from 192.168.2.5#53(192.168.2.5) in 31 ms

ca.                     172800  IN      NS      c.ca-servers.ca.
ca.                     172800  IN      NS      x.ca-servers.ca.
ca.                     172800  IN      NS      any.ca-servers.ca.
ca.                     172800  IN      NS      j.ca-servers.ca.
;; Received 626 bytes from 202.12.27.33#53(m.root-servers.net) in 24 ms

google.ca.              86400   IN      NS      ns1.google.com.
google.ca.              86400   IN      NS      ns2.google.com.
google.ca.              86400   IN      NS      ns3.google.com.
google.ca.              86400   IN      NS      ns4.google.com.
;; Received 603 bytes from 199.253.250.68#53(x.ca-servers.ca) in 42 ms

google.ca.              300     IN      A       172.217.16.163
;; Received 54 bytes from 216.239.32.10#53(ns1.google.com) in 22 ms

(I trimmed out the DNSSEC stuff for brevity.)

Usually of course you wouldn’t perform an iterative query yourself. A recursive DNS server will do it for you, a lot quicker, too.

Answer 2

Suppose it's 1980, and telephone books are still a thing. What's to stop you from going to Kmart's entry in your phone book, and replacing their phone number with the phone number for your store? Absolutely nothing. You are free to do this, and if you use that phone book, every time you try to call Kmart, you'll get your own store. You can relabel phone numbers to your heart's content.

Thing is, everyone else has their own phone book, and they aren't looking at yours. Unless you can break into the phone company and change Kmart's phone number there so that the phone books they send out will have your business's number, you aren't going to deny any business to Kmart.

Similarly, if you decide that you're tired of typing incrediblylongdomainnamethattakesaridiculouslylongtimetotime.com and you don't want to rely on autocomplete, you are free to set up a server that has short.com resolve to incrediblylongdomainnamethattakesaridiculouslylongtimetotime.com 's IP address, and have your computer use that server to resolve domain names. But unless you can get other people's computers to use that server too, you're not going to affect what happens when they type short.com into the address bar.

Answer 3

So my question is, what prevents me from doing the same thing for any domain in the world? As a matter of fact, I did.

The tough part is getting that data, including the NS records for your nameservers installed on the .ca name servers. They probably won't let you do that, and third parties will resolve the domain by querying name servers from the root down, so (global) root first, which gives the address to the .ca name servers, which give the address to the .google.ca name servers.

Of course, if you install those records in your organization's name servers, then anybody within your organization will see the data you set up. (Well, assuming they use the org's name servers, instead of something like 8.8.8.8 directly.) But the moment someone tries to open an HTTPS connection there, they'll get an error because no CA outside your organization will sign your keys for that domain. (which of course can then be circumvented by setting up a CA of your own within the organization, but that's a different story.)

Answer 4

A better way to phrase the answer, I think, is to say that while you can do it, it doesn't affect the domain you create them for.

When a device attempts to connect to an IP address it performs a lookup from a number of places in order:

1. It searches for local host file entries that tell it how to resolve the domain.
2. If no entry is found, it then checks the domain service for the name servers set at the registrar.
3. Those name servers then specify an authoritative DNS zone file to reference.
4. The zone file then provides authoritative A records.

Because the zone file you created isn't in the public chain of reference for authority it won't affect public traffic.

However, it can affect local traffic in the right (or wrong) circumstances, supposing you are on a machine that for some reason checks local DNS before checking authoritative DNS (similar to specifying IP addresses for host names in a local host file), such as with mail routing. For example, if a server is set to local mail routing but the authoritative MX records point to a remote machine. Mail sent from the local machine may be routed internally rather than based on the authoritative information.

So, at best it's a waste of your time. At worst it will mess up your own stuff.

Answer 5

Try going through https://howdns.works It covers both iterative and recursive DNS and how it works, in a very fun and understandable manner. The answer pretty much outlined by Daniel has everything needed.

Answer 6

Things like this can be useful! I once set up the firewall to be AOL so a customer's users could get to AOL via a firewall proxy on the same TCP port.

Answer 7

htst would cause you problems. Browsers already know where to point traffic. The inner workings of its system is a bit unclear to me, but as this has to do with DNS record resolvement, we'll just stick to that instead, since your records aren't on an authoritative DNS, and google.ca is routed by whoever handles .ca domains to use their specified nameservers.

This would never work because the top level DNS servers that ARPA runs does not accept changes from your nameserver for a domain that they couldn't verify to be from said DNS pointed out via the .ca domain handlers routing. Therefore this would cause duplicates (not good; it could cause your domain to be revoked if they believe this was done on purpose), if the providers default nameservers handle redirection or pointing to its specified IP address.

It's a whole bunch of levels, and you have to be on the same level within its network (as the DNS record is hosted on) to carry this out and yes as someone mentioned, you would probably have to carry out DDoS attacks to force it to fallover, or some low-key hacking on the victims to use your rouge DNS.

To have its record overwritten, this could probably be done by firewall rules if the system had been compromised, again just guessing, but there could be other ways that doesn't require system access.

It's my understanding of this, there are people here with far more experience than what I have, and this is a very complicated visualisation of what is going on.

There could be several ways to bypass this for not-so-high-end domains not certified/verified for htst, but really this isn't something that should be talked about on the open web since performing this is considered basis for the worst type of cyber crime.

You would be able to use this to intercept, carrying out man in the middle sort of attacks on vulnerable domains using the same DNS as your website, just by using the same provider who also must be fairly outdated/insecure which there are plenty of.

The Internet is broken, and it's the whole reason why we have to mitigate all these faults by spending countless hours configuring even the simplest of services.