56

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:

Screenshot

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.

Improve this question
  • 2
    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? – Logarr Feb 13 '20 at 15:52
  • 18
    @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. – Marcel Krüger Feb 13 '20 at 18:58
  • 2
    Congratulations! You found a way break the internet. 😳 – Pablo Feb 14 '20 at 17:42
  • better to hide your public IP in the image – dev-masih Feb 15 '20 at 10:12
  • 1
    Don’t forget to accept one of the answers! If you need further clarification, please don’t hesitate to ask. – Daniel B Feb 16 '20 at 21:33
83

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.

Improve this answer
  • 7
    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? – nick012000 Feb 13 '20 at 10:54
  • 9
    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. – saucecontrol Feb 13 '20 at 11:14
  • 8
    @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. – Tyzoid Feb 13 '20 at 16:14
  • 7
    @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). – fraxinus Feb 13 '20 at 21:42
  • 3
    @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 ... – Hagen von Eitzen Feb 14 '20 at 23:01
34

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.

Improve this answer
  • 8
    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. – ceejayoz Feb 14 '20 at 21:57
  • 3
    @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. – quetzalcoatl Feb 14 '20 at 23:21
  • 1
    @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. – ceejayoz Feb 15 '20 at 2:01
  • @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" – quetzalcoatl Feb 15 '20 at 2:04
  • 1
    @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. – ceejayoz Feb 15 '20 at 2:29
25

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

Improve this answer
  • 4
    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. – Brian Feb 13 '20 at 14:25
  • 3
    @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. – cpast Feb 14 '20 at 1:05
  • 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 Feb 21 '20 at 21:24
3

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
-1

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.

Improve this answer
  • 3
    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> – phuzi Feb 14 '20 at 11:42
  • What is htst? – Peter Mortensen Feb 15 '20 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.