DNS Configuration

Support
,
#1

I have read various resources about how DNS is handled in yunohost and find them a bit confusing, even inconsistent sometimes. So please forgive me for asking the basic questions but the answers do not seem obvious.

The service

First, the service itself. In my admin interface the only sign of a DNS is Bind9, but it’s inactive and I can’t activate it. Then on the command line, in the processes all I can find about a DNS service is dnsmasq. In the latest release announcement I understand we should be using dnsmasq.
So should we use dnsmasq? Then what about bind9? Should it be removed?

Resolver

I have started looking at dnsmasq, which looks nice. But there is something I’m not sure about it. It seems to be a DNS forwarder. So when I need a resolver, dnsmasq won’t actually do the resolving and instead pass it along to the DNS listed in its resolv.conf. Am I right or am I missing something?
It’s not a very big deal but some routers (Mikrotik if I’m not mistaken) work as forwarders too, so if you give them the address of your yunohost DNS as resolver then a loop is created and unless the router has other DNS listed then resolving is impossible in that scenario.
It’s not super important but I would like to have a resolver on the yunohost.

DNS server

Now I would like to tell my registrar to stop being responsible for my DNS and instead consider my yunohost as the DNS server for my domain.
My understanding is that dnsmasq will configure everything installed on the yunohost box to just work. But what about things that I need to configure manually on my domain, that are external to my yunohost? Can I do it? Should there be a interface in the admin? Should I edit something manually on the command line?
I would like to add stuffs like an external mail server in the MXs or some NS servers.

Is it supposed to handle reverse DNS as well?

Thanks for your help!

2 Likes
#2

Did you ever get an answer to this?

#3

Nope. Welcome to ghost town.

1 Like
#4

I wound up figuring it out.

#5

in french sorry …

L’idée m a traversé également l’esprit.
Cependant si je comprend bien ta demande; la question serait pourquoi pas rendre son serveur Yunohost auto-hébergé, un vps ou dédié comme mon propre résolveur DNS?

petite parenthèse : Je fonctionne sur mes ordis avec unbound qui interroge les dns racines. Si j ai bien compris Unbound peut etre installer comme resolveur dns et dhcp sur un serveur tiers.
https://homeserver-diy.net/wiki/index.php?title=Installer_et_configurer_son_serveur_DNS_connecté_aux_serveurs_root_avec_Unbound

Pour Dnsmasq ( que je connais très peu) il y a le quelque infos que j ai trouvé sur le web
http://www.drazzib.com/docs/admin/dnsmasq.html
http://iomem.com/archives/19-Run-a-local-DNS-resolver-with-OpenWRT.html
https://www.linux.com/news/enhance-your-dns-and-dhcp-service

Pour un webui de dnsmasq je n ai trouvé que cela
https://sourceforge.net/projects/dnsmasq-mikrotik-admin/files/README.txt/download

Donc étant dans les mêmes questionnements et n ayant que peu de compétences dans le domaine, je m abonne a ton post :wink:

merci
Yolateng0

#6

Depuis que j’ai posté cela j’ai fait quelques changements sur ma config. J’utilise unbound également comme resolver sur les clients mais pas sur yunohost. Je n’ai pas vraiment regardé mais je pense qu’il y aurait conflit avec dnsmasq vu qu’ils vont devoir écouter tous les 2 sur le port 53. Ça ne me dérange pas tant que ça, j’utilise des DNS de confiance sur yunohost et ça me suffit.

J’utilise désormais l’instance dnsmasq de mon yunohost comme DNS autoritaire pour mon domaine. Du coup la j’ai pas vraiment trouvé comment le configurer dans le cadre de yunohost et j’édite le fichier de config directement à la main. Ça n’a rien cassé pour le moment et le fichier n’est pas réécrit par un scripte ni rien de bizarre pour le moment. Mais je pense que ça peut changer à tout instant si yunhost se met à changer la manière d’utiliser dnsmasq.

Pour le moment tout fonctionne mais ce n’est pas optimal dans la mesure où ce n’est pas intégré dans le système et c’est du bricolage.

2 Likes
#7

Bonjour à tous !
Je me permets de déterrer ce sujet car nous avons fait face à un problème avec dnsmasq récemment.
A partir du moment où on ajoute un domaine sur sur une instance YunoHost, ce sous-domaine en l’occurence pointe forcément vers la boucle locale à moins qu’on modifie le fichier /etc/hosts.
Nous avons voulu crée une tuile sur l’interface utilisateur de YunoHost donc :

  1. Installation du sous-domaine sur YunoHost
  2. Installation de l’app redirect_ynh avec ce sous-domaine et qui pointe vers une ip externe (vers un serveur BBB en l’occurence)
  3. Problème de communication avec l’API du service externe. Un dig nous a fait constater que le sous-domaine pointait vers la boucle locale
  4. Modification du fichier /etc/hosts pour forcer le sous-domaine à pointer vers la bonne IP externe.

Bref ce n’est pas idéal comme solution.

Avez-vous plus d’explication sur pourquoi dnsmasq ? Quel est son fonctionnement ?

1 Like
#8

yes I missing dns server enhacements too. Sometime its needed to manually add / edit dns server zones. But uhmm impossible right now. :confused:

#9

Vraiment je comprends pas pourquoi les gens pensent que c’est une superbe idée de déterrer des posts vieux de 6 ans, genre y’a milles trucs qui ont changé depuis, personne n’a envie de relire 15 postes pour savoir de quoi ça parle, et en faisant ça vous ne filez même pas les infos standards genre “vous êtes dans quel contexte” ce qui est juste énervant

(Oui je suis un vieux aigri mais j’en ai marre de passer mes journées à dire et redemander les mêmes choses encore et encore)

J’ai la flemme de redire les trucs que j’ai déjà dit mille fois ailleurs … M’enfin en l’occurence ton cas d’usage a l’air d’être déjà un cas d’usage avancée

Dans le cas d’usage normal, il faut bien que le domaine pointe quelque part, et en particulier c’est important pour que Lets Encrypt fonctionne car les scripts vérifient que le fichier mis à disposition pour le challenge ACME sont bien exposés…

Bref, dans ton cas c’est sans doute OK de bricoler /etc/hosts, même si je suis pas sur de l’impact que ça aura sur tes futures générations de certifs Lets Encrypt … Moi je dirais que la vraie question c’est pour quoi il y a un « problème de communication avec l’API du service externe » … Normalement il y a pleins d’apps qui gèrent très bien le fait d’être dans une config de reverse proxy

Yes great thanks for your valuable very detailed feedback …

1 Like
#10

Bonjour,

Je confirme…

Mais, selon moi, une question qui ne trouve pas sa réponse dans la doc et qui est posé dans le forum sur le post dont le sujet qui semble le plus adapté ne mérite pas une réponse aussi brutale.

Qu’aurait-il fallu faire ? Recréer un autre post avec le même sujet ? Ne rien demander ?

Désolé nous avons peut-être mal cherché mais nous avons épluché la doc et nous ne l’avons pas trouvé.

Si cela à été répondu mille fois ailleurs peut-être alors que cela vaudrait le coup de faire une mise à jour de la doc avec ce sujet précis car nous somme à l’évidence plusieurs à tomber sur ce cas, non ?

Nous nous doutons que c’est très lourd et compliqué de maintenir un logiciel libre de l’ampleur de YNH, et cela est probablement épuisant mais cela ne mérite pas une telle réponse, je pense.

Ce qui n’était peut-être pas claire dans le message de @lydra c’est que nous avons dans YNH déclaré une domaine ext.domain.tld pour y mettre l’application redirect_ynh dans le but d’avoir une tuile d’application dans la liste des apps de YNH.

Mais en faisant ça le serveur considère que ext.domain.tld est sur le serveur et ne sort pas.

Pourtant le domaines DNS pointe vers un autre serveur qui est déclaré dans la zone DNS de notre hébergeur.

Donc les app sur le serveurs YNH ne peuvent plus communiquer avec ext.domain.tld car le DNS interne ne fait pas sortir les requêtes.

La bidouille n’a aucune impact sur la génération de certifs Lets Encrypt du domaine ext.domain.tld car les requêtes externes à YNH sur ce domaine arrivent sur un autre serveur. On à bien un certificat LE sur ext.domain.tld qui est géré par le serveur externe, pas de problème.

Nous allons travailler une issue pour pouvoir créer des applications sans domaine dans YNH pour justement pouvoir mettre en place ce genre de choses sans bidouiller comme on le fait.

1 Like
#11

C’est pas spécialement le même sujet si ce n’est que ça parle de config DNS. Le truc est tellement vieux qu’en relisant le post original ça parle de bind9

Le topic a juste 7 ans et tout a changé depuis

Moi je passe quand même régulièrement des heures à réfléchir à comment implémenter plus de bureaucratie nazie qui empêche de poster dans la section support si tu files pas les infos de base

J’veux dire on s’est quand même fait chier à implémenter :

  • une check quand tu t’inscrit qui dit que si tu postes dans la catégorie Support, tu t’engages à utiliser le template et fournir les infos de bases demandées
  • une bannière en haut du forum qui rappelle la même chose
  • quand tu créés un topic, c’est pré-rempli avec le modèle

Suite à ce post j’ai encore passé une demi-heure cette nuit à chercher si il existe des modules Discourse pour implémenter un truc plus contraignant vu que j’ai l’impression que la moitié des users ne savent juste pas utiliser le template. Ça détruit la santé mentale de devoir redire mille fois la même chose alors qu’il suffirait que les gens prennent 2 secondes pour faire le truc qui est demandé et qu’on va de toute façon leur redemander si il le font pas (d’ailleurs c’est pas spécifique au forum, c’est la même merde dans le chat)

Sur le ressucitage random de topic, on a aussi mis en place un truc qui autoclos les topics au bout d’un certain temps justement parce que c’était la pagaille avec les gens qui pensent que c’est pertinent de réouvrir un topic de y’a X année parce que “le problème ressemble” alors qu’il n’a rien à voir. Sauf qu’on a pas trouvé de truc magique pour fermer les topics déjà existants.

Plusieurs fois ça me démange de fermer ou supprimer des topics qui ne respectent pas ça, mais bon, on essaye de rester acceuillant hein

Alors du coup ouai aujourdhui je pète mon cable random et ça tombe sur vous, surtout grâce au type anglais qui surenchéri un truc wtf derrière qui m’a bien trigger, et c’est juste nul parce que vous êtes les gens cool qui bossez sur Lydra -_-

Oui il faudrait sans doute mettre à jour la doc, comme milles autres trucs. M’enfin faire de la doc pour expliquer tous les choix de design du projet, je t’avoue que c’est pas la top priorité, on galère déjà à tenir à jour les trucs utiles, comme par exemple la doc de packaging qui est complètement obsolète et confusante

M’enfin je doute que le problème soit vraiment de comprendre pourquoi DNSmasq que de savoir quelle est la bonne manière de config le reverse proxy.

Wokay mais du coup comment est vraiment configuré l’app redirect ?

Le message initial parle de pointer vers une IP … du coup à quel moment le serveur aurait besoin de résoudre le domaine vers la vraie IP si ce n’est pas le domaine qui est utilisé dans le reverse proxy ?

Si c’est un reverse proxy qui pointe vers un domaine, alors j’aurais tendance à dire que c’est pas la bonne façon de config le truc. Faire un reverse proxy qui pointe vers un domaine c’est tout un zbeul avec la gestion du HTTPS/certificat etc. Pourquoi ne pas faire une simple redirection (302) ?

#12

Tiens bah dans le genre “les gens ne savent pas poser une question correctement”, je viens tout juste de recevoir un message perso sur le forum avec quelqu’un qui me demande si il y a une roadmap pour le support du 2FA, comme si j’étais la hotline de YunoHost

Djeezus fucking christ