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.

Solution 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.

Solution 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.

Solution 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.)

Solution 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.

Solution 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.

View more solutions

Comments

[Logarr]

I don't use GoDaddy, but on my DNS host when it say something like domain.something. that last dot is indicating it's still a subdomain of whatever domain I'm editing records for. Are you sure you're not actually making records for google.ca.mydomain.com?

[Marcel Krüger]

@Logarr Are you sure? Normally it is the other way around: Without the final dot domains are relative, with the final dot absolute domains are given.

[jzlas]

Congratulations! You found a way break the internet. 😳

[dev-masih]

better to hide your public IP in the image

[Volker Siegel]

Oh, I found a big red button that looks scary. Let's try what it does! (No worries, just trying it was the right thing to do here. And quite interesting!)

[Daniel B]

Don’t forget to accept one of the answers! If you need further clarification, please don’t hesitate to ask.

[nick012000]

Wouldn't be be able to do shenanigans if he controlled the name server for a given network (e.g. the name server for a corporate intranet), since it'd be the first server a given user's computer consulted?

[eagle275]

also your own name-server would only be asked for an answer if NO other name-server provided one ... as they are hierarchically organized you can assume that most well known addresses are resolved WAY before your name-server is asked. People with malicious intend fire ddos attacks at the higher name-servers to force the hierarchy to ask to resolve it using their manipulated name-servers - yes @nick012000 .. in his organization he could do shenanigans - but only for people who only use his (corporate) name-server. Most use additional name-servers ;-)

[saucecontrol]

It's worth noting that HSTS is a mitigation against this. Even if one were to set up private DNS with records for well-known sites and then set up phony versions of those sites, a user attempting to visit those sites would be redirected by their browser to the HTTPS version of the site, which would either fail or show an invalid certificate warning.

[ilkkachu]

@saucecontrol, if you control the DNS of some domain, you should be able to get a Let's Encrypt certificate for it.

[Gary - Stand with Ukraine]

In practice, HTTPS can still be intercepted within organizational machines. If your organization is setting up organizational name servers, they are probably also distributing internal certificate authorities (e.g., using Group Policy). This still fails under certificate pinning, on condition that the pinning itself was not intercepted and discarded. Note that public key pinning is deprecated, though I believe Google Chrome hard-codes the root certificates for some of Google's domains.

[Tyzoid]

@ilkkachu The HSTS mitigation was in response to having a private DNS server that resolves to a malicious IP, not access to the authoritative nameserver. Let's Encrypt resolves the site from multiple locations and queries from multiple IPs before issuing a certificate. HKP would be a further mitigation against malicious certs.

[Dave]

@nick012000, then he wouldn't be in charge of that corporate name server for long, would he?

[Dave]

@eagle275, this isn't really true. On networks that have their own internal name servers, which is most, those servers are queried first, and it's trivial to configure them not to recurse for a particular domain name. But then see my reply to nick012000.

[Daniel B]

Chat’s over here, m’kay? 😉

[fraxinus]

@nick012000 besides shenanigans, it makes a perfectly valid method for applying a company policy. For example, you can make facebook or youtube browser requests to go to a company policy memo (or a local jobs site, as we once did for a client).

[cpast]

@Brian Even with pinning, browsers generally accept any non-default certificate authorities regardless of whether or not a different CA is pinned. This is done specifically to support organizational HTTPS interception, which is generally considered a valid use case.

[iBug]

@Tyzoid Pardon, but what is HKP?

[phuzi]

HTST - don't you mean HSTS (HTTP Strict Transport Security)? If so, HSTS will only tell the browser to updgrade the request from HTTP to HTTPS if the browser has already seen the HTTPS site or the domain is pre-loaded. DNS is not involved in this in the slightest. All it will do is force a request to http://<domain> to be automatically upgraded to https://<domain>

[Acccumulation]

@nick012000 That's kinda what a firewall is (grossly simplified). Once you control the name server, you control access to the outside world. This is just part of controlling an intranet. I guess whoever controls the intranet can perform "shenanigans" with that control.

[ceejayoz]

Basically, it's like putting the title "President of the United States" on your business cards. Most people in the world will never see one. Most of the people who do will roll their eyes and ignore it.

[PyRulez]

@saucecontrol what if they set up a malicious certificate authority on the local network as well?

[Hagen von Eitzen]

@PyRulez Either your pc by default ignores the unknown certificate authority, or your pc is property of the company with the "malicious" CA preinstalled. In the latter case it may be the case that the pc does as the owning company wants more than as you want ...

[quetzalcoatl]

@ceejayoz First two sentences are correct. Third is wrong. In such situation your computer will say "Oh hello Mr President!". The problem is, that if your computer even looks at that business card, it has no way to know it's not legit. You want your computer to NOT check business cards at all, you want your computer to check the only good business-card-catalog you really trust. If your computer was somehow made into thinking that it's better to ask (hacked/spoofed) DNS server B instead of normal DNS server A, then your computer won't roll its eyes and will believe that you are the president.

[ceejayoz]

@quetzalcoatl It's an imperfect analogy, but the third sentence is intended to address how difficult it's going to be to get a valid certificate for google.ca on your spoofed server.

[quetzalcoatl]

@ceejayoz what does a certificate have to DNS? Without http+s case would be lost. The sole fact that the computer connects to the fake google.ca proves that DNS spoofing succeeded. that's what I meant by saying that "those computers won't roll their eyes"

[ceejayoz]

@quetzalcoatl You can point the google.ca record wherever, but wherever won't have a valid cert. As browsers will grump about things like password fields submitting to HTTP these days, it's another nail in the coffin for DNS hijacking.

[TOOGAM]

@ nick012000 (presuming meant "Wouldn't be be able") Yes. If he controlled a DHCP server that pointed people to the local DNS server, the local DNS server could provide such bad information. (A client could override this by manually choosing a known public DNS server.)

[TOOGAM]

Great answer. But I would have bee more likely to register incrediblylongdomainnamethattakesaridiculouslylongtimetotype‌​.com (because, who needs to time how long it takes to time something?)

[PyRulez]

@HagenvonEitzen okay, so CAs are generally preinstalled. That makes sense. Thanks!

[Peter Mortensen]

What is htst?

[Asteroids With Wings]

This is a great answer

[Patrick Mevzek]

"(I trimmed out the DNSSEC stuff for brevity.)". Just add +nodnssec to your dig CLI next time and it won't display DNSSEC related information (which is orthogonal on doing or not DNSSEC validation, which is the +cd flag). Note that you can trim flags, so I often use +nodns to just confuse people... ("Wait, what, dig with no DNS?")

[Patrick Mevzek]

"Wouldn't be be able to do shenanigans if he controlled the name server for a given network (e.g. the name server for a corporate intranet), since it'd be the first server a given user's computer consulted? " Yes, but less and less so with the advent of DNS over TLS and even more DNS over HTTPS used by browsers, like Firefox, to disregard completely your local DNS settings and just go out asking CloudFlare to do DNS resolutions for you.

[Patrick Mevzek]

"It's worth noting that HSTS is a mitigation against this" No it is not, except if you pin the keys. If you control resolution, it is trivial to get DV certificates, so HTTPS is fine. DNS TLSA records on the other end are a mitigation to this (this is DANE, because you basically encode parts of the certificates in the DNS), but only with DNSSEC in which case even if you control the resolution, you won't make the responses DNSSEC valid.

[Patrick Mevzek]

DNS TLSA records let owner of the domain choose which certificates/CA should be accepted, per service. Unfortunately this is for more far more spread in usage in SMTP-land than in HTTP-land.

[Patrick Mevzek]

@iBug HKP is in fact HPKP or HTTP Public Key Pinning. This allows a website to say to the browser: please accept HTTPS connections to me only with certificates having public key being X or Y (in summary). This basically insures that you can not connect to something pretentind to be the website but using another certificate. However in practice this is not anymore (never was) a real solution: browsers are slowly deprecating it over things using Certificate Logs, and you have the problem of first access anyway (how to disseminate the proper keys to use?). DNS TLSA records are a better solution

[InterLinked]

... and telephone books are still a thing? I ordered the latest copy of the White Pages and the Yellow Pages four months ago. I need to do it again now that it's the new year. Shame they don't send them automatically anymore - at least the White Pages.