Qu'est-ce qui m'empêche de créer une entrée de nom A pour "google.ca" vers l'adresse IP de mon choix ?

Rien ne vous arrête. Cependant, personne ne jettera un coup d'oeil non plus. C'est parce que le vrai domaine ne pointe pas vers votre serveur de noms (GCP DNS). On ne peut obtenir ces enregistrements qu'en les demandant directement à votre serveur de noms.

Les requêtes DNS commencent à la racine :

$ 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

(J'ai supprimé les trucs de DNSSEC par souci de concision).

En général, vous n'effectuez pas vous-même une requête itérative. Un serveur DNS récursif le fera pour vous, et beaucoup plus rapidement.

Supposons que nous sommes en 1980, et que les annuaires téléphoniques existent toujours. Qu'est-ce qui vous empêche de consulter l'entrée de Kmart dans votre annuaire et de remplacer son numéro de téléphone par celui de votre magasin ? Absolument rien. Vous êtes libre de le faire, et si vous utilisez cet annuaire, chaque fois que vous essayerez d'appeler Kmart, vous obtiendrez votre propre magasin. Vous pouvez changer les numéros de téléphone à votre guise.

Le problème, c'est que tout le monde a son propre annuaire, et ils ne regardent pas le vôtre. A moins que tu puisses t'introduire dans la compagnie de téléphone et changer le numéro de téléphone de Kmart. là pour que les annuaires téléphoniques qu'ils envoient portent le numéro de votre entreprise, vous ne refuserez aucun marché à Kmart.

De même, si vous décidez que vous en avez assez de taper incrediblylongdomainnamethattakesaridiculouslylongtimetotime.com et que vous ne voulez pas compter sur la complétion automatique, vous êtes libre de configurer un serveur dont le nom short.com est résolu par l'adresse IP d'incrediblylongdomainnamethattakesaridiculouslylongtimetotime.com, et de faire en sorte que votre ordinateur utilise ce serveur pour résoudre les noms de domaine. Mais à moins que vous n'arriviez à faire en sorte que les ordinateurs d'autres personnes utilisent également ce serveur, vous n'aurez aucune influence sur ce qui se passe lorsqu'ils tapent short.com dans la barre d'adresse.

Ma question est donc la suivante : qu'est-ce qui m'empêche de faire la même chose pour n'importe quel domaine dans le monde ? En fait, je l'ai fait.

La partie la plus difficile est d'obtenir ces données, y compris la NS pour vos serveurs de noms installés sur le serveur .ca les serveurs de noms. Ils ne vous laisseront probablement pas faire, et les tiers résoudront le domaine en interrogeant les serveurs de noms de la racine vers le bas, c'est-à-dire la racine (globale) en premier, ce qui donne l'adresse au serveur de noms. .ca les serveurs de noms, qui donnent l'adresse à l .google.ca les serveurs de noms.

Bien entendu, si vous installez ces enregistrements dans les serveurs de noms de votre organisation, n'importe qui au sein de votre organisation pourra voir les données que vous avez configurées. (Enfin, en supposant qu'ils utilisent les serveurs de noms de l'organisation, au lieu de quelque chose comme 8.8.8.8 directement). Mais dès que quelqu'un essaiera d'ouvrir une connexion HTTPS à cet endroit, il obtiendra une erreur car aucune autorité de certification extérieure à votre organisation ne signera vos clés pour ce domaine. (ce qui peut bien sûr être contourné en mettant en place une AC propre au sein de l'organisation, mais c'est une autre histoire).

Une meilleure façon de formuler la réponse, je pense, est de dire que si vous pouvez le faire, cela n'affecte pas le domaine pour lequel vous les créez.

Lorsqu'un appareil tente de se connecter à une adresse IP, il effectue une recherche dans un certain nombre d'endroits, dans l'ordre :

1. Il recherche les entrées du fichier d'hôte local qui lui indiquent comment résoudre le domaine.
2. Si aucune entrée n'est trouvée, il vérifie alors le service de domaine pour les serveurs de noms définis par le registraire.
3. Ces serveurs de noms spécifient ensuite un fichier de zone DNS faisant autorité à référencer.
4. Le fichier de zone fournit ensuite des enregistrements A qui font autorité.

Comme le fichier de zone que vous avez créé n'est pas dans la chaîne de référence publique pour l'autorité, il n'affectera pas le trafic public.

Cependant, il peut affecter le trafic local dans les bonnes (ou mauvaises) circonstances, à supposer que vous soyez sur une machine qui, pour une raison quelconque, vérifie le DNS local avant de vérifier le DNS faisant autorité (similaire à la spécification des adresses IP pour les noms d'hôtes dans un fichier d'hôtes local), comme pour le routage du courrier. Par exemple, si un serveur est configuré pour le routage du courrier local mais que les enregistrements MX faisant autorité pointent vers une machine distante. Le courrier envoyé depuis la machine locale peut être acheminé en interne plutôt que de se baser sur les informations faisant autorité.

Donc, au mieux, c'est une perte de temps. Au pire, vous risquez d'abîmer votre propre matériel.

Essayez de passer par https://howdns.works Il couvre le DNS itératif et récursif et son fonctionnement, d'une manière très amusante et compréhensible. La réponse décrite par Daniel contient tout ce qui est nécessaire.