Filtre actif, cliquez pour en enlever un tag :
Cliquez sur un tag pour affiner votre recherche :
Résultat de la recherche (15 notes) :
Commandes valables sous Fedora mais aussi plus généralement sous Linux.
Affiche la configuration DNS actuelle :
$ resolvectl status
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.1:5300
DNS Servers: 127.0.0.1:5300
DNS Domain: ~test
Link 2 (wlp1s0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.31.1
DNS Servers: 192.168.31.1
Intéroge directement un serveur DNS :
$ dig @127.0.0.1 -p 5300 server2.vagrant.test +short
192.168.56.21
Résolution d'un hostname avec resolvectl
:
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23
-- Information acquired via protocol DNS in 4.2ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
La commande suivante affiche toutes la configuration de resolved.conf :
$ systemd-analyze cat-config systemd/resolved.conf
Journal du mardi 05 novembre 2024 à 11:34
En explorant la console de Scaleway, je viens de tomber sur la fonctionnalité suivante :
Scaleway Domains and DNS provides advanced features for traffic management using your DNS zone. It allows you to redirect users based on their geolocation, the load on your different servers, and more.
Je viens de réaliser que cela répond à une question que je me posais souvent entre 2000 et 2010 : comment les sites à portée mondiale parviennent-ils à répartir le trafic entre différents datacenters avec une URL unique, comme google.com ?
À l’époque, j’imaginais que ces acteurs utilisaient principalement le Round-robin DNS ou des algorithmes de répartition de charge avec HAProxy. mais je n'avais pas pensé à la possibilité que le serveur DNS puisse donner une réponse différente en fonction de l'IP de la personne qui fait la requête.
De plus, cette réponse peut dépendre de la localisation de l'IP (GeoIP).
Par exemple, depuis 2014, le serveur DNS Bind propose nativement la fonctionnalité "GeoIP Features".
J'ai lu aussi que les gros acteurs utilisent la méthode Anycast, mais cette méthode nécessite de gérer son propre Autonomous System.
Journal du dimanche 20 octobre 2024 à 22:50
Nouvelle #iteration du Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS.
Il y a quelques jours, j'ai migré de vagrant-hostmanger vers vagrant-dns. J'ai ensuite souhaité mettre en œuvre Grizzly, mais j'ai rencontré un problème.
J'ai installé une version binaire statiquement liée de Grizzly à l'aide de Mise. Dans cette version, Go ne fait pas appel à la fonction getaddrinfo pour la résolution des noms d'hôte. Au lieu de cela, Go se limite à lire les informations de configuration DNS dans /etc/resolv.conf
(champ nameserver
) et les entrées de /etc/hosts
.
Cela signifie que les serveurs DNS gérés par systemd-resolved ne sont pas pris en compte 😭.
Pour régler ce problème, j'utilise en même temps vagrant-dns et Vagrant Host Manager : voici le commit.
J'active uniquement ici le paramètre config.hostmanager.manage_host = true
et je laisse vagrant-dns résoudre les hostnames à l'intérieur des machines virtuelles et des containers Docker.
Journal du vendredi 18 octobre 2024 à 19:15
Nouvelle #iteration de Projet 14.
Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.
-- from
Résultat : j'ai migré de Vagrant Host Manager vers vagrant-dns avec succès 🙂.
Voici le commit : lien vers le commit.
Voici quelques explications de la configuration Vagrantfile.
Les lignes suivantes permettent d'utiliser la seconde IP des machines virtuelles pour identifier les identifier (renseignés par le serveur DNS).
config.dns.ip = -> (vm, opts) do
ip = nil
vm.communicate.execute("hostname -I | cut -d ' ' -f 2") do |type, data|
ip = data.strip if type == :stdout
end
ip
end
La commande hostname
retourne les deux IP de la machine virtuelle :
vagrant@server1:~$ hostname -I
10.0.2.15 192.168.56.22
La commande hostname -I | cut -d ' ' -f 2
capture la seconde IP, ici 192.168.56.22
.
La configuration DNS qui retourne cette IP est consultable via :
$ vagrant dns -l
/server1.vagrant.test/ => 192.168.56.22
/server2.vagrant.test/ => 192.168.56.23
/grafana.vagrant.test/ => 192.168.56.23
/loki.vagrant.test/ => 192.168.56.23
vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
Cette ligne configure la machine virtuelle pour qu'elle utilise le serveur DNS de vagrant-dns.
Cela permet de résoudre les noms des autres machines virtuelles. Exemple :
vagrant@server1:~$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23 -- link: eth0
-- Information acquired via protocol DNS in 12.3ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
En mettant en place vagrant-dns sur ma workstation qui tourne sous Fedora, j'ai rencontré la difficulté suivante.
J'avais la configuration suivante installée :
$ cat /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd
Elle me permet de résoudre les hostnames des machines qui appartiennent à un réseau privé exposé via OpenVPN (voir cette note).
Voici ma configuration complète de systemd-resolved
:
$ systemd-analyze cat-config systemd/resolved.conf
# /etc/systemd/resolved.conf
...
[Resolve]
...
# /etc/systemd/resolved.conf.d/1-vagrant-dns.conf
# This file is generated by vagrant-dns
[Resolve]
DNS=127.0.0.1:5300
Domains=~test
# /etc/systemd/resolved.conf.d/csd.conf
[Resolve]
DNS=10.57.40.1
Domains=~csd
Quand je lançais resolvectl query server2.vagrant.test
pour la première fois après redémarrage de sudo systemctl restart systemd-resolved
, tout fonctionnait correctement :
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23
-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
Mais, la seconde fois, j'avais l'erreur suivante :
$ resolvectl query server2.vagrant.test
server2.vagrant.test: Name 'server2.vagrant.test' not found
Ce problème disparait si je supprime /etc/systemd/resolved.conf.d/csd.conf
.
Je n'ai pas compris pourquoi. D'après la section "Protocols and routing" de systemd-resolved, le serveur 10.57.40.1
est utilisé seulement pour les hostnames qui se terminent par .csd
.
J'ai activé les logs de systemd-resolved au niveau debug
avec
$ sudo resolvectl log-level debug
$ journalctl -u systemd-resolved -f
Voici le contenu des logs lors de la première exécution de resolvectl query server2.vagrant.test
: https://gist.github.com/stephane-klein/506a9fc7d740dc4892e88bfc590bee98.
Voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test
: https://gist.github.com/stephane-klein/956befc280ef9738bfe48cdf7f5ef930.
J'ai l'impression que la ligne 13 indique que le cache de systemd-resolved a été utilisé et qu'il n'a pas trouvé de réponse pour server2.vagrant.test
. Pourquoi ? Je ne sais pas.
Ligne 13 : NXDOMAIN cache hit for server2.vagrant.test IN A
Ensuite, je supprime /etc/systemd/resolved.conf.d/csd.conf
:
$ sudo rm /etc/systemd/resolved.conf.d/csd.conf
Je relance systemd-resolved et voici le contenu des logs lors de la seconde exécution de resolvectl query server2.vagrant.test
: https://gist.github.com/stephane-klein/9f87050524048ecf9766f9c97b789123#file-systemd-resolved-log-L11
Je constate que cette fois, la ligne 11 contient : Cache miss for server2.vagrant.test IN A
.
Pourquoi avec .csd
le cache retourne NXDOMAIN
et sans .csd
, le cache retourne Cache miss
et systemd-resolved continue son algorithme de résosultion du hostname ?
Je soupçonne systemd-resolved de stocker en cache la résolution de server2.vagrant.test
par le serveur DNS 10.57.40.1
. Si c'est le cas, je me demande pourquoi il fait cela alors qu'il est configuré pour les hostnames qui se terminent par .csd
🤔.
Autre problème rencontré, la latence de réponse :
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23
-- Information acquired via protocol DNS in 7.5073s.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
La réponse est retournée en 7 secondes, ce qui ne me semble pas normal.
J'ai découvert que je n'ai plus aucune latence si je passe le paramètre DNSStubListener
à no
:
$ sudo cat <<EOF > /etc/systemd/resolved.conf.d/0-vagrant-dns.conf
[Resolve]
DNSStubListener=no
EOF
$ sudo systemctl restart systemd-resolved
$ resolvectl query server2.vagrant.test
server2.vagrant.test: 192.168.56.23
-- Information acquired via protocol DNS in 2.9ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
Le temps de réponse passe de 7.5s
à 2.9ms
. Je n'ai pas compris la signification de ma modification.
Je récapitule, pour faire fonctionner correctement vagrant-dns sur ma workstation Fedora j'ai dû :
- supprimer
/etc/systemd/resolved.conf.d/csd.conf
- et paramétrer
DNSStubListener
àno
Migration de vagrant-hostmanager vers vagrant-dns
Dans le cadre du Projet 14 - Script de base d'installation d'un serveur Ubuntu LTS, j'utilise Vagrant avec le plugin Vagrant Host Manager pour gérer les hostnames des machines virtuelles.
Vagrant Host Manager met correctement à jour les fichiers /etc/hosts
sur ma machine hôte, c'est-à-dire, ma workstation, et dans les machines virtuels.
Cependant, ces noms d'hôtes ne sont pas accessibles à l'intérieur des containers Docker.
Par exemple, ici, http://grafana.example.com:3100/
n'est pas accessible à l'intérieur du container Promtail.
Pour traiter ce problème, je souhaite essayer de remplacer Vagrant Host Manager par vagrant-dns.
vagrant-dns semble exposer un serveur DNS qui sera accessible et utilisé par les containers Docker.
D'autre part, vagrant-dns (page contributors) semble un peu plus actif que Vagrant Host Manager (page contributors).
Journal du mardi 20 août 2024 à 09:47
Dans ce thread Fediverse #JaiDécouvert LeBureau.coop.
Une société coopérative de gestion de noms de domaine (registrar).
La vidéo Les noms de domaine pour se réapproprier Internet de Arthur Vuillard à Pas Sage en Seine (à partir de 25min) contient une présentation de ce projet.
J'y ai au passage découvert la coopérative Hasshbang.
Dans ma #todo-list :
- [ ] Transférer un de mes noms de domaine vers LeBureau.coop pour tester ;
- [ ] Acheter des parts pour devenir sociétaire soutien.
Journal du mercredi 14 août 2024 à 12:05
Cela fait 25 ans que je travaille dans le domaine du web, et je viens seulement de prendre conscience de la différence entre un Domain name registrar et un Domain name registry 🙈.
Jusqu'à présent, j'avais tendance à les considérer comme synonymes.
Par exemple, des entreprises comme Gandi ou BookMyName sont exclusivement des Domain name registrar. Elles ne jouent pas le rôle de Domain name registry.
En revanche, certaines entreprises cumulent les deux fonctions, à savoir être à la fois registrar et registry.
C'est le cas de https://www.identity.digital/, qui est à la fois un registrar et registry pour des gTLDs comme le .systems
.
Un autre exemple est Team Internet, qui non seulement opère en tant que registry pour le domaine ".xyz", mais agit également en tant que registrar.
Journal du mercredi 14 août 2024 à 12:01
#JaiDécouvert l'existence du gTLDs .systems
, qui est disponible depuis 2014.
Article wikipedia : https://en.wikipedia.org/wiki/Round-robin_DNS
Article Wikipedia : https://fr.wikipedia.org/wiki/GeoIP
Journal du mardi 12 novembre 2024 à 11:36
#JaiLu le Thread Reddit : What dns do you use on your home router?.
J'y ai découvert Quad9.
DomainMOD is a self-hosted open-source application used to manage your domain name and other Internet assets in a central location.
Journal du jeudi 14 novembre 2024 à 10:26
DomainMOD is a self-hosted open source application used to manage your domains and other Internet assets in a central location.
Dernière page.