Re: sendmail without DNS
On Sun, 21 Jul 2024, Adam Weremczuk wrote: This is in a way a continuation of my recently "purely local DNS" thread. To recap: my objective is to send emails to a single domain with both DNS and any other email traffic being disabled. A simple working solution that I've found for Postfix is: /etc/hosts 1.2.3.4example.com /etc/postfix/main.cf smtp_dns_support_level = disabled smtp_host_lookup = native Now I'm trying to achieve the same thing for Sendmail to no avail. So far I've tried: - the above /etc/hosts entry - DEAMON_OPTIONS(`Port-smtp,Addr=127.0.0.1, Name=MTA')dnl in sendmail.mc followed by m4 sendmail.mc > sendmail.cf You can just type make in /etc/mail and dbs will be rebuilt and it will tell you if you need to reload. - /etc/mail/mailertable example.com esmtp:[1.2.3.4] I use this. Are you missing FEATURE(mailertable) sendmail.mc:FEATURE(`mailertable',`hash -o /etc/mail/mailertable.db')dnl
Re: sendmail without DNS
Thanks for pointing that out. I've noticed that installing sendmail package was removing postfix and vice versa. That made me think these two were mutually exclusive. After reinstalling postfix, logwatch suddenly started sending emails so everything is now working as expected. --- Adam On 21/07/2024 14:23, Greg Wooledge wrote: Blimey. You are COMPLETELY confused, aren't you. If postfix (the package named "postfix") is installed, and if sendmail (the package named "sendmail") is NOT installed, then you are using Postfix to send mail. Part of the postfix package is a /usr/sbin/sendmail program which implements the command line interface for local programs to send mail. EVERY MTA has to implement the /usr/sbin/sendmail program. Including Postfix. If you're running Postfix (*not* Sendmail) as your MTA, and if you've got it configured how you want it, then you are DONE. You don't need to ask us how to configure Sendmail to do the same thing, because you're not USING Sendmail.
Re: sendmail without DNS
On Sun, 21 Jul 2024 18:36:30 +1000 George at Clug wrote: > Adam, > > I dislike people to reply to my questions but do not answer the > question, instead suggest I do something totally different. Yes, but sometimes: a) that's the right answer anyway b) it may not answer the OP's question. but may answer someone else's question much later c) it may inform the OP that there may be a better way of doing it that the OP was not aware of d) it may be that the OP is asking the wrong question, but will get information from your answer as to what the right question should be > > Please forgive me, as that is what I am about to do. > > I have had, what seems to me to be similar issue, my solution was to > set up an authoritative BIND9 server on the email/web server in > question, and have the server first use its own BIND9 server's DNS > service first. > > Admittedly I did not care if my authoritative BIND9 server went out > the the Internet for any queries for which it was not authoritative. > > It did allow me to run the server isolated either from the Internet > and/or connected to the Internet. > Indeed. If you do run a DNS server for general network use, you will always want to put in local information. If there is also an Internet DNS server authoritative for the same domain, you need to put in copies of relevant information that server contains, which will otherwise not be found. BIND9 is a bit of a nuisance, especially when you miss a bit of punctuation in a zone file and it won't start, but as far as I can tell, it's the only DNS solution that will access root hints. I would prefer something a bit lighter. I would rather not trust Net DNS servers since I turned up this company https://uk.linkedin.com/company/barefruit (one of many such) in logs. Advertising is easy to ignore, but the idea of tampering with DNS does not impress me. -- Joe
Re: sendmail without DNS
On Sun, Jul 21, 2024 at 08:24:06 +0100, Adam Weremczuk wrote: > Let me rephrase my question, which should be easier to answer. > > What exactly shall I substitute: > > mailer = "/usr/sbin/sendmail -t" > > with in /usr/share/logwatch/default.conf/logwatch.conf > > to make logwatch use postfix (already working without DNS) instead of > sendmail? Blimey. You are COMPLETELY confused, aren't you. If postfix (the package named "postfix") is installed, and if sendmail (the package named "sendmail") is NOT installed, then you are using Postfix to send mail. Part of the postfix package is a /usr/sbin/sendmail program which implements the command line interface for local programs to send mail. EVERY MTA has to implement the /usr/sbin/sendmail program. Including Postfix. If you're running Postfix (*not* Sendmail) as your MTA, and if you've got it configured how you want it, then you are DONE. You don't need to ask us how to configure Sendmail to do the same thing, because you're not USING Sendmail.
Re: sendmail without DNS
Adam Weremczuk writes: > Let me rephrase my question, which should be easier to answer. > > What exactly shall I substitute: > > mailer = "/usr/sbin/sendmail -t" > > with in /usr/share/logwatch/default.conf/logwatch.conf > > to make logwatch use postfix (already working without DNS) instead of > sendmail? With a quick look, the postfix package includes /usr/sbin/sendmail. So if your /usr/sbin/sendmail isn't the one provided by postfix then likely you have more than one and that situation is probably managed by update-alternatives? So, run update-alternatives --list sendmail and maybe also ls -l /usr/sbin/sendmail to see what the what is.
Re: sendmail without DNS
Adam, I dislike people to reply to my questions but do not answer the question, instead suggest I do something totally different. Please forgive me, as that is what I am about to do. I have had, what seems to me to be similar issue, my solution was to set up an authoritative BIND9 server on the email/web server in question, and have the server first use its own BIND9 server's DNS service first. Admittedly I did not care if my authoritative BIND9 server went out the the Internet for any queries for which it was not authoritative. It did allow me to run the server isolated either from the Internet and/or connected to the Internet. George. On Sunday, 21-07-2024 at 16:58 Adam Weremczuk wrote: > This is in a way a continuation of my recently "purely local DNS" thread. > > To recap: my objective is to send emails to a single domain with both > DNS and any other email traffic being disabled. > > A simple working solution that I've found for Postfix is: > > /etc/hosts > 1.2.3.4example.com > > /etc/postfix/main.cf > smtp_dns_support_level = disabled > smtp_host_lookup = native > > Now I'm trying to achieve the same thing for Sendmail to no avail. > > So far I've tried: > > - the above /etc/hosts entry > > - DEAMON_OPTIONS(`Port-smtp,Addr=127.0.0.1, Name=MTA')dnl in sendmail.mc > followed by m4 sendmail.mc > sendmail.cf > > - /etc/mail/mailertable > example.com esmtp:[1.2.3.4] > > 1. Has anybody tried and got it working? > > 2. What's the best way to engage with Sendmail forums / mailing list? > > Both comp.mail.sendmail and newscomp.mail.sendmail usenet groups appear > to be dead. > > --- > Adam > >
Re: sendmail without DNS
Adam Weremczuk writes: > Let me rephrase my question, which should be easier to answer. > > What exactly shall I substitute: > > mailer = "/usr/sbin/sendmail -t" > Eee. Nothing? --8<---cut here---start->8--- dpkg -L postfix|grep send /usr/sbin/sendmail /usr/share/man/man1/sendmail.1.gz /usr/lib/sendmail --8<---cut here---end--->8--- Man sendmail says that: --8<---cut here---start->8--- -t Extract recipients from message headers. These are added to any recipients specified on the command line. --8<---cut here---end--->8--- (I do not that 'original' sendmail has the same meaning, but I supposed so.) KJ -- http://wolnelektury.pl/wesprzyj/teraz/ Make me look like LINDA RONSTADT again!!
Re: sendmail without DNS
Let me rephrase my question, which should be easier to answer. What exactly shall I substitute: mailer = "/usr/sbin/sendmail -t" with in /usr/share/logwatch/default.conf/logwatch.conf to make logwatch use postfix (already working without DNS) instead of sendmail? On 21/07/2024 08:08, Jeff Pang wrote: Sendmail is too old to be supported. You may use postfix and exim instead. They are main stream MTA software today.
Re: sendmail without DNS
Sendmail is too old to be supported. You may use postfix and exim instead. They are main stream MTA software today. On 2024-07-21 14:58, Adam Weremczuk wrote: This is in a way a continuation of my recently "purely local DNS" thread. To recap: my objective is to send emails to a single domain with both DNS and any other email traffic being disabled. A simple working solution that I've found for Postfix is: /etc/hosts 1.2.3.4example.com /etc/postfix/main.cf smtp_dns_support_level = disabled smtp_host_lookup = native Now I'm trying to achieve the same thing for Sendmail to no avail. So far I've tried: - the above /etc/hosts entry - DEAMON_OPTIONS(`Port-smtp,Addr=127.0.0.1, Name=MTA')dnl in sendmail.mc followed by m4 sendmail.mc > sendmail.cf - /etc/mail/mailertable example.com esmtp:[1.2.3.4] 1. Has anybody tried and got it working? 2. What's the best way to engage with Sendmail forums / mailing list? Both comp.mail.sendmail and newscomp.mail.sendmail usenet groups appear to be dead. --- Adam -- Jeff Pang jeffp...@aol.com
sendmail without DNS
This is in a way a continuation of my recently "purely local DNS" thread. To recap: my objective is to send emails to a single domain with both DNS and any other email traffic being disabled. A simple working solution that I've found for Postfix is: /etc/hosts 1.2.3.4example.com /etc/postfix/main.cf smtp_dns_support_level = disabled smtp_host_lookup = native Now I'm trying to achieve the same thing for Sendmail to no avail. So far I've tried: - the above /etc/hosts entry - DEAMON_OPTIONS(`Port-smtp,Addr=127.0.0.1, Name=MTA')dnl in sendmail.mc followed by m4 sendmail.mc > sendmail.cf - /etc/mail/mailertable example.com esmtp:[1.2.3.4] 1. Has anybody tried and got it working? 2. What's the best way to engage with Sendmail forums / mailing list? Both comp.mail.sendmail and newscomp.mail.sendmail usenet groups appear to be dead. --- Adam
Re: purely local DNS
Thanks for the hint Todd. I've replaced it with: smtp_dns_support_level = disabled and it's still working as expected. --- Adam On 15/07/2024 18:49, Todd Zullinger wrote: It's probably worth noting that `disable_dns_lookups` has been deprecated for a long time. The postconf(5) man page says: As of Postfix 2.11, this parameter is deprecated; use smtp_dns_support_level instead. (Debian 12 has postfix-3.7.11; well past postfix-2.11.) I don't know if `smtp_dns_support_level` is needed at all with `smtp_host_lookup = native`. I've never run an MTA where I wanted DNS lookups disabled, so I don't have any direct experience. If it is needed, you'd surely be better off avoiding the long-deprecated `disable_dns_lookups` parameter which will just set you up for failure with some future update.
Re: purely local DNS
My intention was to send emails to a single domain with any other email traffic being disabled. In order to achieve this I considered smart host, dnsmasq and even bind9. The 3-liner solution that I've found seems the simplest, least intrusive and appears to be working fine. On 16/07/2024 01:33, Max Nikulin wrote: I assume that you are not trying to achieve "smart host" configuration for sending mail. Perhaps you can run a dedicated dnsmasq instance with no upstream DNS servers. Option that might help: --dns-rr, --mx-host, --mx-target.
Re: purely local DNS
On 15/07/2024 20:00, Adam Weremczuk wrote: - ability to fetch a single MX record for a single domain I assume that you are not trying to achieve "smart host" configuration for sending mail. Perhaps you can run a dedicated dnsmasq instance with no upstream DNS servers. Option that might help: --dns-rr, --mx-host, --mx-target.
Re: purely local DNS
Hi, On Mon, Jul 15, 2024 at 09:55:06PM +0800, Jeff Pang wrote: > > > > > I get: > > > > 0A032940922 657 Mon Jul 15 14:40:01 user1@mymachine > > (Host or domain name not found. Name service error for name=example.com > > type=MX: Host not found, try again) > > Any SMTP client which does not fall back to the A record when no MX records > exists is fundamentally broken. I think a confusion here is that the /etc/hosts file is not DNS. Not all applications on a system will ask the NSS for host lookups; some do go straight to DNS (as directed by /etc/resolv.conf). So the assumption that putting an entry in /etc/hosts is just the same as an A record in DNS is not always true. It looks like OP has worked out how to tell Postfix not to use DNS, so it would obey a hosts entry. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: purely local DNS
Adam Weremczuk wrote: > I'm using Postfix and this all that was needed: > > /etc/hosts > 1.2.3.4 example.com > > /etc/postfix/main.cf > disable_dns_lookups = yes > smtp_host_lookup = native It's probably worth noting that `disable_dns_lookups` has been deprecated for a long time. The postconf(5) man page says: As of Postfix 2.11, this parameter is deprecated; use smtp_dns_support_level instead. (Debian 12 has postfix-3.7.11; well past postfix-2.11.) I don't know if `smtp_dns_support_level` is needed at all with `smtp_host_lookup = native`. I've never run an MTA where I wanted DNS lookups disabled, so I don't have any direct experience. If it is needed, you'd surely be better off avoiding the long-deprecated `disable_dns_lookups` parameter which will just set you up for failure with some future update. -- Todd signature.asc Description: PGP signature
Re: purely local DNS
I'm using Postfix and this all that was needed: /etc/hosts 1.2.3.4 example.com /etc/postfix/main.cf disable_dns_lookups = yes smtp_host_lookup = native
Re: purely local DNS
On Mon, Jul 15, 2024 at 14:49:21 +0100, Adam Weremczuk wrote: > I want to achieve the first objective and the values are static. > I just hoped there is a one liner hack (like A records in /etc/hosts) to > achieve this vs reconfiguring my MTA. Routing Internet email in the absence of functioning DNS is going to require configuration of your MTA. So, the next question is *which* MTA you're using. I'm most familiar with qmail. I'm guessing you're not using qmail (just based on the odds), but in qmail, this would be done by creating an smtproutes file in the control directory. If you want qmail to route outgoing remote messages for @example.com to the host zeus.home.arpa, you would put this line in smtproutes: example.com:zeus.home.arpa This suppresses the normal MX lookup. The hostname zeus.home.arpa will need to be resolvable, of course. If you want to use a raw IP address there instead of a hostname, I believe that's also possible. This happens to be a "one-line solution" in qmail. I don't know how to do it in other MTAs off the top of my head, but I'm guessing each one will be different. Probably radically different. It wouldn't surprise me if it requires more than one line of configuration in most cases.
Re: purely local DNS
I get: 0A032940922 657 Mon Jul 15 14:40:01 user1@mymachine (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again) Any SMTP client which does not fall back to the A record when no MX records exists is fundamentally broken. -- Jeff Pang jeffp...@aol.com
Re: purely local DNS
I didn’t test it but no MX was found then local MTA should try A record for delivery. As a proof that safe-mail.net has no mx but A record only. Regards On 2024-07-15 21:45, Adam Weremczuk wrote: It doesn't work. mail.example.com record doesn't exist to start with. Even if I add: 1.2.3.4 example.com 5.6.7.8 mail.example.com to /etc/hosts I get: 0A032940922 657 Mon Jul 15 14:40:01 user1@mymachine (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again) us...@example.com On 15/07/2024 14:17, Jeff Pang wrote: Given you want to send mail to foo.com whose mx record is mail.foo.com whose IP is 1.2.3.4 Then write this entry in hosts file: 1.2.3.4 foo.com Which should work for sending mail. Regards On 2024-07-15 21:00, Adam Weremczuk wrote: What I need to configure for my Debian 12 VM: - no public or LAN DNS whatsoever - ability to fetch a single MX record for a single domain I don't think I can add MX to /etc/hosts which only works for A records. I'm after a similarly simple, "one liner" solution. --- Adam -- Jeff Pang jeffp...@aol.com
Re: purely local DNS
I want to achieve the first objective and the values are static. I just hoped there is a one liner hack (like A records in /etc/hosts) to achieve this vs reconfiguring my MTA. On 15/07/2024 14:33, Greg Wooledge wrote: On Mon, Jul 15, 2024 at 14:00:03 +0100, Adam Weremczuk wrote: What I need to configure for my Debian 12 VM: - no public or LAN DNS whatsoever - ability to fetch a single MX record for a single domain I don't think I can add MX to /etc/hosts which only works for A records. I'm after a similarly simple, "one liner" solution. I'm *so* confused by this question. You want to be able to *fetch* an MX record? You don't want to configure your MTA in a static way so that it delivers mail properly for this domain right now? You need to be able to *fetch* the MX record in real time in case it changes? And you want to do that *without* being able to contact the real DNS? How does one reconcile these goal statements? It's beyond me.
Re: purely local DNS
It doesn't work. mail.example.com record doesn't exist to start with. Even if I add: 1.2.3.4 example.com 5.6.7.8 mail.example.com to /etc/hosts I get: 0A032940922 657 Mon Jul 15 14:40:01 user1@mymachine (Host or domain name not found. Name service error for name=example.com type=MX: Host not found, try again) us...@example.com On 15/07/2024 14:17, Jeff Pang wrote: Given you want to send mail to foo.com whose mx record is mail.foo.com whose IP is 1.2.3.4 Then write this entry in hosts file: 1.2.3.4 foo.com Which should work for sending mail. Regards On 2024-07-15 21:00, Adam Weremczuk wrote: What I need to configure for my Debian 12 VM: - no public or LAN DNS whatsoever - ability to fetch a single MX record for a single domain I don't think I can add MX to /etc/hosts which only works for A records. I'm after a similarly simple, "one liner" solution. --- Adam
Re: purely local DNS
On Mon, Jul 15, 2024 at 14:00:03 +0100, Adam Weremczuk wrote: > What I need to configure for my Debian 12 VM: > - no public or LAN DNS whatsoever > - ability to fetch a single MX record for a single domain > > I don't think I can add MX to /etc/hosts which only works for A records. > > I'm after a similarly simple, "one liner" solution. I'm *so* confused by this question. You want to be able to *fetch* an MX record? You don't want to configure your MTA in a static way so that it delivers mail properly for this domain right now? You need to be able to *fetch* the MX record in real time in case it changes? And you want to do that *without* being able to contact the real DNS? How does one reconcile these goal statements? It's beyond me.
Re: purely local DNS
Given you want to send mail to foo.com whose mx record is mail.foo.com whose IP is 1.2.3.4 Then write this entry in hosts file: 1.2.3.4 foo.com Which should work for sending mail. Regards On 2024-07-15 21:00, Adam Weremczuk wrote: What I need to configure for my Debian 12 VM: - no public or LAN DNS whatsoever - ability to fetch a single MX record for a single domain I don't think I can add MX to /etc/hosts which only works for A records. I'm after a similarly simple, "one liner" solution. --- Adam -- Jeff Pang jeffp...@aol.com
purely local DNS
What I need to configure for my Debian 12 VM: - no public or LAN DNS whatsoever - ability to fetch a single MX record for a single domain I don't think I can add MX to /etc/hosts which only works for A records. I'm after a similarly simple, "one liner" solution. --- Adam
Re: DNS query question
On Wed, Jun 12, 2024 at 06:42:04AM +0200, Marco Moock wrote: > Am 12.06.2024 um 10:51:45 Uhr schrieb Jeff Peng: > > Hello list, > > > > I have made a successful query in one of my VPS as the following. > > > > ~$ dig 235.84.36.104.zen.spamhaus.org > > ;; QUESTION SECTION: > > ;235.84.36.104.zen.spamhaus.org.IN A > > > > ;; ANSWER SECTION: > > 235.84.36.104.zen.spamhaus.org. 852 IN A 127.0.0.10 > > > > ;; Query time: 0 msec > > ;; SERVER: 127.0.0.53#53(127.0.0.53) > > > > > > But, the same query wouldn't success in another VPS as follows. > > > > $ dig 235.84.36.104.zen.spamhaus.org > > ;; QUESTION SECTION: > > ;235.84.36.104.zen.spamhaus.org.IN A > > > > ;; Query time: 1 msec > > ;; SERVER: 127.0.0.53#53(127.0.0.53) > > > > > > The returned result is "NXDOMAIN". > > > > Both nodes use systemd-resolve as DNS subresolver. > > > > Do you know what's the reason behind this? > > Spamhaus restricts queries from public resolvers. > https://www.spamhaus.org/resource-hub/email-security/if-you-query-the-legacy-dnsbls-via-digitalocean-move-to-spamhaus-technologys-free-data-query-service/#the-headlines-for-those-in-a-hurry > > > > Thanks. Thanks for keeping context Thanks for noting that response text is below previous text. Yes, keep the discussion order. Regards Geert Stappers Aware of people in different time zones Creating awareness for that not all messages are read Asking for standalone messages -- Silence is hard to parse
Re: DNS query question
Am 12.06.2024 um 10:51:45 Uhr schrieb Jeff Peng: > Do you know what's the reason behind this? Spamhaus restricts queries from public resolvers. https://www.spamhaus.org/resource-hub/email-security/if-you-query-the-legacy-dnsbls-via-digitalocean-move-to-spamhaus-technologys-free-data-query-service/#the-headlines-for-those-in-a-hurry -- Gruß Marco Send unsolicited bulk mail to 1718182305mu...@cartoonies.org
DNS query question
Hello list, I have made a successful query in one of my VPS as the following. ~$ dig 235.84.36.104.zen.spamhaus.org ; <<>> DiG 9.16.48-Ubuntu <<>> 235.84.36.104.zen.spamhaus.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2160 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;235.84.36.104.zen.spamhaus.org.IN A ;; ANSWER SECTION: 235.84.36.104.zen.spamhaus.org. 852 IN A 127.0.0.10 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Wed Jun 12 02:45:16 UTC 2024 ;; MSG SIZE rcvd: 75 But, the same query wouldn't success in another VPS as follows. $ dig 235.84.36.104.zen.spamhaus.org ; <<>> DiG 9.16.1-Ubuntu <<>> 235.84.36.104.zen.spamhaus.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15831 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;235.84.36.104.zen.spamhaus.org.IN A ;; Query time: 1 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Wed Jun 12 10:45:41 HKT 2024 ;; MSG SIZE rcvd: 59 The returned result is "NXDOMAIN". Both nodes use systemd-resolve as DNS subresolver. Do you know what's the reason behind this? Thanks.
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 19848ième jour après Epoch, BERTRAND Joël écrivait: > François TOURDE a écrit : [...] >> >> Il y a des chances que ton registrar te propose son propre DNS. Pourquoi >> ne pas l'utiliser ? > > Parce que pour certaines configurations spéciales, ça ne le fait pas ou > alors très difficilement. Typiquement pour un certificat * chez > Lestencrypt, il vaut mieux avoir son propre DNS. Il y a quand même beaucoup de plugins certbot pour différents fournisseurs de DNS: https://eff-certbot.readthedocs.io/en/latest/using.html#dns-plugins Mais effectivement, je me sens plus confortable avec mon propre DNS ;)
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 19848ième jour après Epoch, NoSpam écrivait: > Le 04/05/2024 à 23:14, François TOURDE a écrit : >> Le 19846ième jour après Epoch, >> NoSpam écrivait: >> >>> Ouvert aux 4 vents, surement pas. Plein de problèmes si le logiciel >>> est mal configuré. Pour réaliser ce que tu veux faire j'utilise BIND >>> avec sa vue local >>> >>> Perso, je connecterai tous les postes en VPN et ne ferait écouter le >>> serveur DNS que sur l'IP privée du VPN. Pas ou prou problème de >>> sécurité >> Sauf que là, l'OP parle de "téléphones IP", donc difficile de faire le >> tri. En plus, opérer un VPN "ouvert aux 4 vents", ou un DNS "ouvert >> pareil", je choisirais la version DNS plutôt que VPN :) > > Un poste IP n'a besoin de connaitre que son registrar: si donc un VPN > est monté, on se passe de DNS et on utilise l'adresse IP. Si l'on veut > tout de même un DNS, dans ce même cas de figure dnsmasq sur le pabx > est suffisant pour renvoyer l'IP du pabx et plus si nécessaire. Pas > ouvert aux 4 vents. Désolé, j'avais interprété "Téléphone IP" comme "Smartphone low cost avec accès IP" au lieu de penser VOIP, SIP, etc...
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 04/05/2024 à 23:14, François TOURDE a écrit : Le 19846ième jour après Epoch, NoSpam écrivait: Ouvert aux 4 vents, surement pas. Plein de problèmes si le logiciel est mal configuré. Pour réaliser ce que tu veux faire j'utilise BIND avec sa vue local Perso, je connecterai tous les postes en VPN et ne ferait écouter le serveur DNS que sur l'IP privée du VPN. Pas ou prou problème de sécurité Sauf que là, l'OP parle de "téléphones IP", donc difficile de faire le tri. En plus, opérer un VPN "ouvert aux 4 vents", ou un DNS "ouvert pareil", je choisirais la version DNS plutôt que VPN :) Un poste IP n'a besoin de connaitre que son registrar: si donc un VPN est monté, on se passe de DNS et on utilise l'adresse IP. Si l'on veut tout de même un DNS, dans ce même cas de figure dnsmasq sur le pabx est suffisant pour renvoyer l'IP du pabx et plus si nécessaire. Pas ouvert aux 4 vents.
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
François TOURDE a écrit : > Le 19846ième jour après Epoch, > Olivier écrivait: > >> Bonjour, >> >> J'envisage de mettre en place un serveur DNS dont le rôle serait de >> résoudre des requêtes sur un de mes domaines. > > Il y a des chances que ton registrar te propose son propre DNS. Pourquoi > ne pas l'utiliser ? Parce que pour certaines configurations spéciales, ça ne le fait pas ou alors très difficilement. Typiquement pour un certificat * chez Lestencrypt, il vaut mieux avoir son propre DNS. signature.asc Description: OpenPGP digital signature
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 4 mai 2024 François TOURDE a écrit : >> Au minimum fermer le serveur par un firewall et autres. Et configurer le >> serveur dns en prenant les options les plus sécurisées, là ça dépend du >> serveur retenu. Mais au minimum bloquer les transferts et la >> récursion. > > Ok pour les transferts et la récursion, mais l'OP parle de "téléphones > IP", je vois mal comment mettre en place un firewall pour gérer ces > types d'accès. Je parlais d'un firewall pour le serveur vps, pour sécuriser globalement le serveur et pas seulement le DNS. Et même sur des IP inconnues un firewall permet de limiter des choses comme : rafales venant d'une IP, packets invalides, etc.
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 19846ième jour après Epoch, NoSpam écrivait: > Ouvert aux 4 vents, surement pas. Plein de problèmes si le logiciel > est mal configuré. Pour réaliser ce que tu veux faire j'utilise BIND > avec sa vue local > > Perso, je connecterai tous les postes en VPN et ne ferait écouter le > serveur DNS que sur l'IP privée du VPN. Pas ou prou problème de > sécurité Sauf que là, l'OP parle de "téléphones IP", donc difficile de faire le tri. En plus, opérer un VPN "ouvert aux 4 vents", ou un DNS "ouvert pareil", je choisirais la version DNS plutôt que VPN :)
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 19847ième jour après Epoch, Michel Verdier écrivait: > Le 3 mai 2024 Olivier a écrit : > >> 1. Une VM (sous Debian) louée chez un prestataire vous parait-elle >> suffisante ? > > Oui sauf si tu attends des milliers de requêtes Milliers par secondes ? Franchement, un prestataire qui loue des machine et qui ne peut pas supporter des floppées de requêtes DNS, j'en vois pas. >> 3. Quel retour d'expérience sur l'exploitation d'un serveur DNS >> "ouvert aux 4 vents" ? Quels problèmes de sécurité rencontre-t-on ? > > Ouvert pour fournir le dns à des personnes que tu ne connais pas ? > Au minimum fermer le serveur par un firewall et autres. Et configurer le > serveur dns en prenant les options les plus sécurisées, là ça dépend du > serveur retenu. Mais au minimum bloquer les transferts et la > récursion. Ok pour les transferts et la récursion, mais l'OP parle de "téléphones IP", je vois mal comment mettre en place un firewall pour gérer ces types d'accès.
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 19846ième jour après Epoch, Olivier écrivait: > Bonjour, > > J'envisage de mettre en place un serveur DNS dont le rôle serait de > résoudre des requêtes sur un de mes domaines. Il y a des chances que ton registrar te propose son propre DNS. Pourquoi ne pas l'utiliser ? > Imaginons que je possède le domaine masociete.com > Le serveur recevra des requètes d'Internet sur des sous-domaines comme > client12345.masociete.com en provenance d'appareils (téléphones IP) > qui peuvent assez rustiques au niveau réseau. > > Mes exigences sont : > > 1- je puisse "facilement" ajouter-retirer-modifier des sous-domaines Tout dépends de ce que tu appelles "facilement", mais par exemple le registrar GANDI propose des API pour gérer tes enregistrements. > > 2- personne ne puisse énumérer mes sous-domaines ie savoir que les > sous-domaines client1.masociete.com et client2.masociete.com > existent et le les sous-domaine client3.masociete.com n'existe pas > (encore), C'est dépendant de ce que tu vas choisir comme outil, mais en général ils possèdent un paramètre qui va restreindre qui a le droit de faire un transfert de données. > 3- le serveur soit protégée-protégeable contre les attaques par Déni > de Service Tu peux difficilement te battre contre une armée de 2^32 (ou plus) de machines zombies, mais des services comme CloudFlare vont pouvoir répondre à ce besoin. Moyennant finances bien sûr. Mais le déni de service n'a pas forcément de rapport avec le type de serveur DNS que tu vas choisir. > Mes questions : > > 1. Une VM (sous Debian) louée chez un prestataire vous parait-elle > suffisante ? Carrément. C'est même presque overkill. > 2. Quel logiciel recommandez-vous ? Bind9 ? Un gros standard bien stable. > 3. Quel retour d'expérience sur l'exploitation d'un serveur DNS > "ouvert aux 4 vents" ? Quels problèmes de sécurité rencontre-t-on ? J'opère mon DNS depuis bientôt 25 ans (Ouch !) et je n'ai jamais eu de soucis majeurs avec. La migration bind8 vers bind9 a été un peu rugueuse, mais j'ai survécu ;) Je pense que la question majeure est: "Ai-je vraiment besoin d'opérer moi-même mon DNS?" Mes 2¢
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Le 3 mai 2024 Olivier a écrit : > 1. Une VM (sous Debian) louée chez un prestataire vous parait-elle suffisante > ? Oui sauf si tu attends des milliers de requêtes > 2. Quel logiciel recommandez-vous ? yadifa ou unbound qui sont assez légers, bind9 qui a plus de fonctionnalités > 3. Quel retour d'expérience sur l'exploitation d'un serveur DNS > "ouvert aux 4 vents" ? Quels problèmes de sécurité rencontre-t-on ? Ouvert pour fournir le dns à des personnes que tu ne connais pas ? Au minimum fermer le serveur par un firewall et autres. Et configurer le serveur dns en prenant les options les plus sécurisées, là ça dépend du serveur retenu. Mais au minimum bloquer les transferts et la récursion.
Re: [semi-HS] Conseil sur l'exploitation d'un serveur DNS
Bonjour Le 03/05/2024 à 17:37, Olivier a écrit : Bonjour, J'envisage de mettre en place un serveur DNS dont le rôle serait de résoudre des requêtes sur un de mes domaines. Imaginons que je possède le domaine masociete.com Le serveur recevra des requètes d'Internet sur des sous-domaines comme client12345.masociete.com en provenance d'appareils (téléphones IP) qui peuvent assez rustiques au niveau réseau. Mes exigences sont : 1- je puisse "facilement" ajouter-retirer-modifier des sous-domaines 2- personne ne puisse énumérer mes sous-domaines ie savoir que les sous-domaines client1.masociete.com et client2.masociete.com existent et le les sous-domaine client3.masociete.com n'existe pas (encore), 3- le serveur soit protégée-protégeable contre les attaques par Déni de Service Mes questions : 1. Une VM (sous Debian) louée chez un prestataire vous parait-elle suffisante ? 2. Quel logiciel recommandez-vous ? 3. Quel retour d'expérience sur l'exploitation d'un serveur DNS "ouvert aux 4 vents" ? Quels problèmes de sécurité rencontre-t-on ? Ouvert aux 4 vents, surement pas. Plein de problèmes si le logiciel est mal configuré. Pour réaliser ce que tu veux faire j'utilise BIND avec sa vue local Perso, je connecterai tous les postes en VPN et ne ferait écouter le serveur DNS que sur l'IP privée du VPN. Pas ou prou problème de sécurité
[semi-HS] Conseil sur l'exploitation d'un serveur DNS
Bonjour, J'envisage de mettre en place un serveur DNS dont le rôle serait de résoudre des requêtes sur un de mes domaines. Imaginons que je possède le domaine masociete.com Le serveur recevra des requètes d'Internet sur des sous-domaines comme client12345.masociete.com en provenance d'appareils (téléphones IP) qui peuvent assez rustiques au niveau réseau. Mes exigences sont : 1- je puisse "facilement" ajouter-retirer-modifier des sous-domaines 2- personne ne puisse énumérer mes sous-domaines ie savoir que les sous-domaines client1.masociete.com et client2.masociete.com existent et le les sous-domaine client3.masociete.com n'existe pas (encore), 3- le serveur soit protégée-protégeable contre les attaques par Déni de Service Mes questions : 1. Une VM (sous Debian) louée chez un prestataire vous parait-elle suffisante ? 2. Quel logiciel recommandez-vous ? 3. Quel retour d'expérience sur l'exploitation d'un serveur DNS "ouvert aux 4 vents" ? Quels problèmes de sécurité rencontre-t-on ? Slts
Re: Bind9 local DNS not forwarding query to public DNS
Muhammad Yousuf Khan wrote:
> Need your experience advice, We have a BIND9 DNS server that operates both
> privately and publicly for the domain example xyz.com. I use the private
> DNS for certain secure nodes on our local network. I want all VPN users to
> be able to resolve these secure nodes using our local DNS, which is
> functioning correctly.
>
> So I force assign all VPN user local DNS so that they can access the secure
> records and local DNS can forward their query to public DNS in case the
> record is not found in the zone file.
>
> locally everything is working just fine, the issue arises when a VPN user
> queries an A record that is on public. For example, if "secure.xyz.com" has
> a local entry in the zone file, it works as expected. However, when the
> entry is not present, I expect BIND to conditionally forward the query to a
> remote DNS server and resolve it for the VPN client. Unfortunately, this is
> not happening. BIND only searches for entries that are available in the
> local zone file and then times out. Here are my configuration files.
>
> here is my bind config
>
>
> options {
> directory "/var/cache/bind";
> recursion yes; // Enable DNS recursion
> allow-recursion { localhost; };
^ only localhost is allowed to do recursive queries. But you
want all your internal users to be allowed to do that.
> allow-query { any; }; // Allow queries from any
> IP address
> forwarders {
> 8.8.8.8;
> };
> dnssec-validation auto;
> listen-on-v6 { any; };
> };
>
> zone "xyz.com" {
> type master;
> file "/etc/bind/db.xyz.com";
> forwarders {
> 8.8.8.8;
> 8.8.4.4;// Additional forwarder (optional)
^ you do not want forwarders here.
-dsr-
Re: Bind9 local DNS not forwarding query to public DNS
On 12/03/2024 12:48, Muhammad Yousuf Khan wrote:
Dear All,
Need your experience advice, We have a BIND9 DNS server that operates
both privately and publicly for the domain example xyz.com
<http://xyz.com/>. I use the private DNS for certain secure nodes on our
local network. I want all VPN users to be able to resolve these secure
nodes using our local DNS, which is functioning correctly.
So I force assign all VPN user local DNS so that they can access the
secure records and local DNS can forward their query to public DNS in
case the record is not found in the zone file.
locally everything is working just fine, the issue arises when a VPN
user queries an A record that is on public. For example, if
"secure.xyz.com <http://secure.xyz.com/>" has a local entry in the zone
file, it works as expected. However, when the entry is not present, I
expect BIND to conditionally forward the query to a remote DNS server
and resolve it for the VPN client. Unfortunately, this is not happening.
BIND only searches for entries that are available in the local zone file
and then times out. Here are my configuration files.
here is my bind config
options {
directory "/var/cache/bind";
recursion yes; // Enable DNS recursion
allow-recursion { localhost; };
You're only allowing recursion from localhost. I guess you need to allow
the internal VPN addresses here. Maybe that's the (commented) acl below,
so try something like
allow-recursion { "trusted"; };
(Maybe the acl needs to be defined before it's used, I'm not sure.)
//acl trusted {192.168.1.0/24; };
But remember to add localhost to the acl, so that local processes can
also use the recursive server.
querylog yes;
allow-transfer { none; }; // Disable zone transfers by
default
allow-query { any; }; // Allow queries from any IP
address
forwarders {
8.8.8.8;
};
dnssec-validation auto;
listen-on-v6 { any; };
};
zone "xyz.com" {
type master;
file "/etc/bind/db.xyz.com";
forwarders {
8.8.8.8;
8.8.4.4; // Additional forwarder (optional)
};
};
Thanks,
Yousuf
--
pension:
A federally insured chain letter.
Eduardo M KALINOWSKI
edua...@kalinowski.com.br
Bind9 local DNS not forwarding query to public DNS
Dear All,
Need your experience advice, We have a BIND9 DNS server that operates both
privately and publicly for the domain example xyz.com. I use the private
DNS for certain secure nodes on our local network. I want all VPN users to
be able to resolve these secure nodes using our local DNS, which is
functioning correctly.
So I force assign all VPN user local DNS so that they can access the secure
records and local DNS can forward their query to public DNS in case the
record is not found in the zone file.
locally everything is working just fine, the issue arises when a VPN user
queries an A record that is on public. For example, if "secure.xyz.com" has
a local entry in the zone file, it works as expected. However, when the
entry is not present, I expect BIND to conditionally forward the query to a
remote DNS server and resolve it for the VPN client. Unfortunately, this is
not happening. BIND only searches for entries that are available in the
local zone file and then times out. Here are my configuration files.
here is my bind config
options {
directory "/var/cache/bind";
recursion yes; // Enable DNS recursion
allow-recursion { localhost; };
//acl trusted { 192.168.1.0/24; };
querylog yes;
allow-transfer { none; }; // Disable zone transfers
by default
allow-query { any; }; // Allow queries from any
IP address
forwarders {
8.8.8.8;
};
dnssec-validation auto;
listen-on-v6 { any; };
};
zone "xyz.com" {
type master;
file "/etc/bind/db.xyz.com";
forwarders {
8.8.8.8;
8.8.4.4;// Additional forwarder (optional)
};
};
Thanks,
Yousuf
Re: Default DNS lookup command?
On 31/10/23 16:27, Max Nikulin wrote: On 30/10/2023 14:03, Richard Hector wrote: On 24/10/23 06:01, Max Nikulin wrote: getent -s dns hosts zircon Ah, thanks. But I don't feel too bad about not finding that ... 'service' is not defined in that file, 'dns' doesn't occur, and searching for 'hosts' doesn't give anything useful either. I guess reading nsswitch.conf(5) is required. Do you mean that "hosts" entry in your /etc/nsswitch.conf lacks "dns"? Even systemd nss plugins recommend to keep it as a fallback. If you get no results then your resolver or DNS server may not be configured to resolve single-label names. Try some full name getent -s dns ahosts debian.org Sorry for the confusion (and delay) - I think I was referring to the getent man page, rather than the config file. Richard
Re: Populating IPv6 DNS addresses in resolv.conf
On 01/11/2023 17:41, Timothy M Butterworth wrote: All, Thanks for all your help. I was able to get it mostly working: # Generated by NetworkManager search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 192.168.104.233 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2001:4860:4860:: nameserver 2001:4860:4860::8844 nameserver 2600:380:bc53:b864::b3 I did not want the DNS name servers to be populated but I can live with it. Do you mean that you prefer to avoid 192.168.104.233 2600:380:bc53:b864::b3 received from DHCP? Perhaps the 3 servers limitation may be relieved by allowing NetworkManager to run dnsmasq.
Re: Populating IPv6 DNS addresses in resolv.conf
All, Thanks for all your help. I was able to get it mostly working: # Generated by NetworkManager search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 nameserver 192.168.104.233 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 2001:4860:4860:: nameserver 2001:4860:4860::8844 nameserver 2600:380:bc53:b864::b3 I did not want the DNS name servers to be populated but I can live with it. thank again for your help Tim -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Populating IPv6 DNS addresses in resolv.conf
On 30/10/2023 20:04, Timothy M Butterworth wrote: sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection [...] [ipv6] addr-gen-mode=stable-privacy dns=2001:4860:4860::,2001:4860:4860::8844; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto I have tried to add a DNS server through GUI. The result is [ipv6] addr-gen-mode=stable-privacy dns=2001:4860:4860::; method=auto Disconnect and connect again. cat /etc/resolv.conf # Generated by NetworkManager nameserver 10.0.2.3 nameserver 2001:4860:4860:: It is a qemu VM, it gets DHCPv4 lease, but not DHCPv6 one. I have not tried to customize /etc/dhclient. Another data point with manually added IPv6 DNS server is Pocket's message https://lists.debian.org/msgid-search/94ff954f-7d28-4a86-bdea-bd2c82196...@columbus.rr.com
Re: Default DNS lookup command?
On 30/10/2023 14:03, Richard Hector wrote: On 24/10/23 06:01, Max Nikulin wrote: getent -s dns hosts zircon Ah, thanks. But I don't feel too bad about not finding that ... 'service' is not defined in that file, 'dns' doesn't occur, and searching for 'hosts' doesn't give anything useful either. I guess reading nsswitch.conf(5) is required. Do you mean that "hosts" entry in your /etc/nsswitch.conf lacks "dns"? Even systemd nss plugins recommend to keep it as a fallback. If you get no results then your resolver or DNS server may not be configured to resolve single-label names. Try some full name getent -s dns ahosts debian.org
Re: Populating IPv6 DNS addresses in resolv.conf
On 31/10/2023 04:02, Pocket wrote: On 10/30/23 15:50, Timothy M Butterworth wrote: I know it is using dhclient because I typod the domain name supersede domain-name "home.apra"; and it populated .apra in resolv.conf. Sorry, it is not clear for me what did you do and what result you got. There is a script that may run ifupdown hooks: /etc/NetworkManager/dispatcher.d/01-ifupdown I hope, dhclient settings do not conflict with NetworkManager connection properties. /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) [main] # rc-manager= # auth-polkit=true # dhcp=internal ^^ This states that you are running two DHCP clients as I suspected. I would not be so sure. Notice "[ifupdown] managed=false". It is better to have a look into "ps axuwwf" for DHCP-related stuff (dhclient, udhcpcd). I hope, systemd-networkd does not try to manage interfaces networkctl should report "unmanaged". I assume that NetworkManager uses its internal DHCP client and it is OK. Timothy, are you sure that "Pixel5" sends a DHCP lease? I have almost no experience with IPv6. I would try other methods for IPv6. I hope, nmcli connection show Pixel5 may shed more light on IPv6 configuration state. Finally, do not neglect "journalctl -b" messages (even though I find NetworkManager log messages rather noisy).
Re: Populating IPv6 DNS addresses in resolv.conf
On 10/30/23 15:50, Timothy M Butterworth wrote: On Mon, Oct 30, 2023 at 1:18 PM Pocket wrote: On 10/30/23 09:04, Timothy M Butterworth wrote: Hello All, I have been following the recent emails regarding resolv.conf. I almost have my system running perfectly. The only thing I am missing is the population of IPv6 DNS addresses. sudo less /etc/dhcp/dhclient.conf supersede domain-name "home.arpa"; supersede dhcp6.domain-search "home.arpa"; supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844; supersede domain-name-servers 8.8.8.8, 8.8.4.4; sudo less /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false [global-dns] searches=home.arpa sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection [ipv4] dns=8.8.4.4,8.8.8.8; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto [ipv6] addr-gen-mode=stable-privacy dns=2001:4860:4860::,2001:4860:4860::8844; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto sudo less /etc/resolv.conf domain home.arpa search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 For some reason I am not getting any IPv6 Name Servers populated. Any thoughts are appreciated. Tim Why not use NetworkManagers internal DHCP client. That is what I have done and then I don't need dhclient or dhcpcd. I am not sure that you are really using dhclient as NetworkManager has not been set to use dhclient from the configuration that you have posted. I know it is using dhclient because I typod the domain name supersede domain-name "home.apra"; and it populated .apra in resolv.conf. What is the output from: NetworkManager --print-config Notice in the following dhcp=internal in my configuration NetworkManager --print-config sudo NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) [main] # rc-manager= # auth-polkit=true # dhcp=internal ^^ This states that you are running two DHCP clients as I suspected. That is probably why you have the results you have. From the docs page: https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html || This key sets up what DHCP client NetworkManager will use. Allowed values are |dhclient|, |dhcpcd|, and |internal|. The |dhclient| and |dhcpcd| options require the indicated clients to be installed. The |internal| option uses a built-in DHCP client which is not currently as featureful as the external clients. If this key is missing, it defaults to |internal|. If the chosen plugin is not available, clients are looked for in this order: |dhclient|, |dhcpcd|, |internal|. The commented entries are the defaults if not explicitly set -- It's not easy to be me
Re: Populating IPv6 DNS addresses in resolv.conf
On Mon, Oct 30, 2023 at 1:18 PM Pocket wrote: > > On 10/30/23 09:04, Timothy M Butterworth wrote: > > Hello All, > > I have been following the recent emails regarding resolv.conf. I almost > have my system running perfectly. The only thing I am missing is the > population of IPv6 DNS addresses. > > sudo less /etc/dhcp/dhclient.conf > supersede domain-name "home.arpa"; > supersede dhcp6.domain-search "home.arpa"; > supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844; > supersede domain-name-servers 8.8.8.8, 8.8.4.4; > > sudo less /etc/NetworkManager/NetworkManager.conf > [main] > plugins=ifupdown,keyfile > > [ifupdown] > managed=false > > [global-dns] > searches=home.arpa > > sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection > > [ipv4] > dns=8.8.4.4,8.8.8.8; > dns-search=home.arpa; > ignore-auto-dns=true #I tried with this on, commented out and set to false > may-fail=false > method=auto > > [ipv6] > addr-gen-mode=stable-privacy > dns=2001:4860:4860::,2001:4860:4860::8844; > dns-search=home.arpa; > ignore-auto-dns=true #I tried with this on, commented out and set to false > may-fail=false > method=auto > > sudo less /etc/resolv.conf > domain home.arpa > search home.arpa > nameserver 8.8.8.8 > nameserver 8.8.4.4 > > For some reason I am not getting any IPv6 Name Servers populated. > > Any thoughts are appreciated. > > Tim > > > Why not use NetworkManagers internal DHCP client. > > That is what I have done and then I don't need dhclient or dhcpcd. > > I am not sure that you are really using dhclient as NetworkManager has not > been set to use dhclient from the configuration that you have posted. > I know it is using dhclient because I typod the domain name supersede domain-name "home.apra"; and it populated .apra in resolv.conf. > What is the output from: > > NetworkManager --print-config > > Notice in the following dhcp=internal in my configuration > > NetworkManager --print-config > sudo NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) [main] # rc-manager= # auth-polkit=true # dhcp=internal # iwd-config-path= plugins=ifupdown,keyfile configure-and-quit=no [global-dns] searches=home.arpa [ifupdown] managed=false [logging] # backend=journal # audit=true [device] # wifi.backend=wpa_supplicant [device-31-mac-addr-change] match-device=driver:eagle_sdio,driver:wl wifi.scan-rand-mac-address=no > # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf > (lib: no-mac-addr-change.conf) > > [main] > # rc-manager= > # auth-polkit=true > # dhcp=internal > # iwd-config-path= > plugins=ifupdown,keyfile > configure-and-quit=no > > [global-dns] > options=ends0 trust-ad > > [ifupdown] > managed=false > > [logging] > # backend=journal > # audit=true > > [device] > # wifi.backend=wpa_supplicant > wifi.scan-rand-mac-address=no > > [device-31-mac-addr-change] > match-device=driver:eagle_sdio,driver:wl > wifi.scan-rand-mac-address=no > > # no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"-- > > -- > > It's not easy to be me > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Populating IPv6 DNS addresses in resolv.conf
On Mon, Oct 30, 2023 at 11:09 AM Max Nikulin wrote: > On 30/10/2023 20:04, Timothy M Butterworth wrote: > > sudo less /etc/resolv.conf > > domain home.arpa > > search home.arpa > > nameserver 8.8.8.8 > > nameserver 8.8.4.4 > > I do not see "# Generated by NetworkManager" here. > > nmcli connection > NAMEUUID TYPE DEVICE Pixel5 e70d426b-3a26-4b29-bf59-edb3dcdfdbc3 wifi wlo1 > nmcli device > DEVICE TYPE STATE CONNECTION wlo1wifi connected Pixel5 > NetworkManager --print-config > sudo NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) [main] # rc-manager= # auth-polkit=true # dhcp=internal # Am I correct in thinking that this setting enables the internal DHCP client. # iwd-config-path= plugins=ifupdown,keyfile configure-and-quit=no [global-dns] searches=home.arpa [ifupdown] managed=false [logging] # backend=journal # audit=true [device] # wifi.backend=wpa_supplicant [device-31-mac-addr-change] match-device=driver:eagle_sdio,driver:wl wifi.scan-rand-mac-address=no # no-auto-default file "/var/lib/NetworkManager/no-auto-default.state" > ls -l /etc/resolv.conf > lsattr /etc/resolv.conf > I just changed this back to using chattr +i with the IPv6 addresses added. > As to /etc/dhcp/dhclient.conf and /etc/network/interfaces, I may be > wrong, but perhaps independent instances for IPv4 and IPv6 may be > running (if actual connection is managed through ifupdown) > > -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Populating IPv6 DNS addresses in resolv.conf
On 10/30/23 09:04, Timothy M Butterworth wrote: Hello All, I have been following the recent emails regarding resolv.conf. I almost have my system running perfectly. The only thing I am missing is the population of IPv6 DNS addresses. sudo less /etc/dhcp/dhclient.conf supersede domain-name "home.arpa"; supersede dhcp6.domain-search "home.arpa"; supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844; supersede domain-name-servers 8.8.8.8, 8.8.4.4; sudo less /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false [global-dns] searches=home.arpa sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection [ipv4] dns=8.8.4.4,8.8.8.8; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto [ipv6] addr-gen-mode=stable-privacy dns=2001:4860:4860::,2001:4860:4860::8844; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto sudo less /etc/resolv.conf domain home.arpa search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 For some reason I am not getting any IPv6 Name Servers populated. Any thoughts are appreciated. Tim Why not use NetworkManagers internal DHCP client. That is what I have done and then I don't need dhclient or dhcpcd. I am not sure that you are really using dhclient as NetworkManager has not been set to use dhclient from the configuration that you have posted. What is the output from: NetworkManager --print-config Notice in the following dhcp=internal in my configuration NetworkManager --print-config # NetworkManager configuration: /etc/NetworkManager/NetworkManager.conf (lib: no-mac-addr-change.conf) [main] # rc-manager= # auth-polkit=true # dhcp=internal # iwd-config-path= plugins=ifupdown,keyfile configure-and-quit=no [global-dns] options=ends0 trust-ad [ifupdown] managed=false [logging] # backend=journal # audit=true [device] # wifi.backend=wpa_supplicant wifi.scan-rand-mac-address=no [device-31-mac-addr-change] match-device=driver:eagle_sdio,driver:wl wifi.scan-rand-mac-address=no # no-auto-default file "/var/lib/NetworkManager/no-auto-default.state"-- -- It's not easy to be me
Re: Populating IPv6 DNS addresses in resolv.conf
Am 30.10.2023 um 22:08:46 Uhr schrieb Max Nikulin: > On 30/10/2023 20:04, Timothy M Butterworth wrote: > > sudo less /etc/resolv.conf > > domain home.arpa > > search home.arpa > > nameserver 8.8.8.8 > > nameserver 8.8.4.4 > > I do not see "# Generated by NetworkManager" here. That is because NM manages the file. Some users use other managers (resolvconf, systemd-resolve) or create the file manually. The content of the file is relevant, which software created it is secondary.
Re: Populating IPv6 DNS addresses in resolv.conf
On 30/10/2023 20:04, Timothy M Butterworth wrote: sudo less /etc/resolv.conf domain home.arpa search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 I do not see "# Generated by NetworkManager" here. nmcli connection nmcli device NetworkManager --print-config ls -l /etc/resolv.conf lsattr /etc/resolv.conf As to /etc/dhcp/dhclient.conf and /etc/network/interfaces, I may be wrong, but perhaps independent instances for IPv4 and IPv6 may be running (if actual connection is managed through ifupdown)
Populating IPv6 DNS addresses in resolv.conf
Hello All, I have been following the recent emails regarding resolv.conf. I almost have my system running perfectly. The only thing I am missing is the population of IPv6 DNS addresses. sudo less /etc/dhcp/dhclient.conf supersede domain-name "home.arpa"; supersede dhcp6.domain-search "home.arpa"; supersede dhcp6.name-servers 2001:4860:4860::, 2001:4860:4860::8844; supersede domain-name-servers 8.8.8.8, 8.8.4.4; sudo less /etc/NetworkManager/NetworkManager.conf [main] plugins=ifupdown,keyfile [ifupdown] managed=false [global-dns] searches=home.arpa sudo less /etc/NetworkManager/system-connections/Pixel5.nmconnection [ipv4] dns=8.8.4.4,8.8.8.8; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto [ipv6] addr-gen-mode=stable-privacy dns=2001:4860:4860::,2001:4860:4860::8844; dns-search=home.arpa; ignore-auto-dns=true #I tried with this on, commented out and set to false may-fail=false method=auto sudo less /etc/resolv.conf domain home.arpa search home.arpa nameserver 8.8.8.8 nameserver 8.8.4.4 For some reason I am not getting any IPv6 Name Servers populated. Any thoughts are appreciated. Tim -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: Default DNS lookup command?
On 24/10/23 06:01, Max Nikulin wrote: On 22/10/2023 18:39, Richard Hector wrote: But not strictly a DNS lookup tool: richard@zircon:~$ getent hosts zircon 127.0.1.1 zircon.lan.walnut.gen.nz zircon That's from my /etc/hosts file, and overrides DNS. I didn't see an option in the manpage to ignore /etc/hosts. getent -s dns hosts zircon However /etc/resolv.conf may point to local systemd-resolved server or to dnsmasq started by NetworkManager and they read /etc/hosts by default. Ah, thanks. But I don't feel too bad about not finding that ... 'service' is not defined in that file, 'dns' doesn't occur, and searching for 'hosts' doesn't give anything useful either. I guess reading nsswitch.conf(5) is required. Thanks, Richard
Re: Default DNS lookup command?
On 22/10/2023 18:39, Richard Hector wrote: But not strictly a DNS lookup tool: richard@zircon:~$ getent hosts zircon 127.0.1.1 zircon.lan.walnut.gen.nz zircon That's from my /etc/hosts file, and overrides DNS. I didn't see an option in the manpage to ignore /etc/hosts. getent -s dns hosts zircon However /etc/resolv.conf may point to local systemd-resolved server or to dnsmasq started by NetworkManager and they read /etc/hosts by default. I haven't found a way to get just DNS results, without pulling in extra software. Usual task for application is to resolve hostname and enough methods besides DNS may be used: multicast DNS, LLMNR, etc. If you need a debug tool then you should install it. On the other hand it is desperate when a feature is implemented, but not exposed to users.
Re: Default DNS lookup command?
On 23/10/2023 20:52, David Wright wrote: AFAICT, if you don't have busybox installed, then I think it's likely that you removed it yourself. Or it is a LXC container installed using the "download" template. It uses systemd-networkd and systemd-resolved. I have never tried qemu with kernel and initrd loaded from host, so related tools are not necessary inside VM. So for original requirement "on any Debian Bullseye or Bookworm install" I would not neglect resolvectl when systemd-resolved is active.
Re: Default DNS lookup command?
On Sun 22 Oct 2023 at 11:07:05 (+0700), Max Nikulin wrote: > On 21/10/2023 22:58, David Wright wrote: > > On Sat 21 Oct 2023 at 17:35:21 (+0200), Reiner Buehl wrote: > > > is there a DNS lookup command that is installed by default on any > > > Debian Bullseye or Bookworm install? > > > > nslookup is in busybox. > > busybox is an optional package, so it may be absent. "getent hosts" > from Greg's message is better in this sense. If systemd-resolved is > configured on a particular instance then > > resolvectl query debian.org > > may be an option. AFAICT, if you don't have busybox installed, then I think it's likely that you removed it yourself. The d-i initrd has busybox already installed, and most people will see something like this in its log: # head -n2 /var/log/installer/syslog Jul 26 19:17:07 syslogd started: BusyBox v1.35.0 Jul 26 19:17:07 kernel: klogd started: BusyBox v1.35.0 (Debian 1:1.35.0-4+b3) # If the following file is still available (the one with the highest generation number), you can see that busybox is typically the third package to be installed by APT. (If the file has been rotated away, just search for "busybox" in the file above.) # zcat /var/log/apt/history.log.2.gz | head Start-Date: 2023-07-26 19:30:49 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install locales Install: locales:i386 (2.36-9), libc-l10n:i386 (2.36-9, automatic) End-Date: 2023-07-26 19:30:56 Start-Date: 2023-07-26 14:31:14 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -q -y --no-remove install busybox Install: busybox:i386 (1:1.35.0-4+b3) End-Date: 2023-07-26 14:31:16 # I suppose preseed experts might be able to prevent that from happening, though to what purpose, IDK. I can only assume that its Priority is set to Optional so that it's easily removable if not required. I don't see many reasons that systemd-resolved would get installed unless you specifically asked for it, so I'd hardly call it "installed by default". Cheers, David.
Re: Default DNS lookup command?
On 22/10/23 04:56, Greg Wooledge wrote: On Sat, Oct 21, 2023 at 05:35:21PM +0200, Reiner Buehl wrote: is there a DNS lookup command that is installed by default on any Debian getent hosts NAME getent ahostsv4 NAME That said, you get much finer control from dedicated tools. That is a useful tool I should remember. But not strictly a DNS lookup tool: richard@zircon:~$ getent hosts zircon 127.0.1.1 zircon.lan.walnut.gen.nz zircon That's from my /etc/hosts file, and overrides DNS. I didn't see an option in the manpage to ignore /etc/hosts. I haven't found a way to get just DNS results, without pulling in extra software. Richard
Re: Default DNS lookup command?
On 21/10/2023 22:58, David Wright wrote: On Sat 21 Oct 2023 at 17:35:21 (+0200), Reiner Buehl wrote: is there a DNS lookup command that is installed by default on any Debian Bullseye or Bookworm install? nslookup is in busybox. busybox is an optional package, so it may be absent. "getent hosts" from Greg's message is better in this sense. If systemd-resolved is configured on a particular instance then resolvectl query debian.org may be an option.
Re: Default DNS lookup command?
Perfect! Then I just need to add an alias to my profile and can use nslookup :-) On 21.10.23 17:58, David Wright wrote: On Sat 21 Oct 2023 at 17:35:21 (+0200), Reiner Buehl wrote: > is there a DNS lookup command that is installed by default on any > Debian Bullseye or Bookworm install? Something that doesn't require as > much dependencies as bind9-utils (which provides dig and nslookup) or > bind9-host? nslookup is in busybox. Type: $ busybox nslookup $ busybox nslookup debian.org Cheers, David.
Re: Default DNS lookup command?
Hello, it's not really answer to your question, but for simple things like IP-Addresses you can use getent ahosts, getent hosts or ping directly. Best Regards, Juri Grabowski
Re: Default DNS lookup command?
On Sat 21 Oct 2023 at 17:35:21 (+0200), Reiner Buehl wrote: > is there a DNS lookup command that is installed by default on any > Debian Bullseye or Bookworm install? Something that doesn't require as > much dependencies as bind9-utils (which provides dig and nslookup) or > bind9-host? nslookup is in busybox. Type: $ busybox nslookup $ busybox nslookup debian.org Cheers, David.
Re: Default DNS lookup command?
On Sat, Oct 21, 2023 at 05:35:21PM +0200, Reiner Buehl wrote: > is there a DNS lookup command that is installed by default on any Debian getent hosts NAME getent ahostsv4 NAME That said, you get much finer control from dedicated tools.
Default DNS lookup command?
Hi all, is there a DNS lookup command that is installed by default on any Debian Bullseye or Bookworm install? Something that doesn't require as much dependencies as bind9-utils (which provides dig and nslookup) or bind9-host? Best regards, Reiner
Re: Conseils sur la configuration DNS d'un serveur
On Fri, Sep 22, 2023 at 05:19:08PM +0200, Stephane Bortzmeyer wrote a message of 13 lines which said: > Oui. Cloudflare 1.1.1.1 ne fait pas autrement, il n'a pas de > privilège particulier, il parle aux serveurs faisant autorité, comme > le fait le résolveur public de FDN, ou comme le fait le petit > résolveur Knot qui est chez moi. La preuve avec dig. Voici la requête qu'un résolveur enverrait à un des serveurs faisant autorité pour .fr, le d.nic.fr. La réponse arrive bien, alors qu'elle est partie d'une petite machine Debian ordinaire, bêtement connectée à un FAI grand public (Free) : % dig +dnssec +norecurse @d.nic.fr www.paypal.fr ; <<>> DiG 9.18.16-1-Debian <<>> +dnssec +norecurse @d.nic.fr www.paypal.fr ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44594 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: 55a74fbb3177a8130100650db3019fb5c6c75bc88734 (good) ;; QUESTION SECTION: ;www.paypal.fr. IN ;; AUTHORITY SECTION: paypal.fr. 3600 IN NS ns1.p57.dynect.net. paypal.fr. 3600 IN NS pdns100.ultradns.net. paypal.fr. 3600 IN NS pdns100.ultradns.com. paypal.fr. 3600 IN NS ns2.p57.dynect.net. paypal.fr. 3600 IN DS 49549 8 2 ( D99B0F323A7E1161CD598AA9ACDAC29235F6707D0E4A C6EBC59FCB703E96AB63 ) paypal.fr. 3600 IN RRSIG DS 13 2 3600 ( 20231126092821 20230915144228 60747 fr. UouuMe6fve2zA8wRqaJCWXoPqjFDh0XafGdfwQ5sM65a eRJotF77ify6lIXaYkt9iT0XueXYMDCRjeXafdBIzg== ) ;; Query time: 0 msec ;; SERVER: 2001:678:c::1#53(d.nic.fr) (UDP) ;; WHEN: Fri Sep 22 15:30:09 UTC 2023 ;; MSG SIZE rcvd: 334
Re: Conseils sur la configuration DNS d'un serveur
On Fri, Sep 22, 2023 at 04:49:07PM +0200, Olivier wrote a message of 10 lines which said: > Quand on installe sur sa machine, un logiciel comme Unbound, celui-ci > sait-il directement interroger les serveurs DNS centraux qui gèrent > les .com, .fr et autres (ie sans passer par les serveurs comme > 1.1.1.1 ou autres ) ? Oui. Cloudflare 1.1.1.1 ne fait pas autrement, il n'a pas de privilège particulier, il parle aux serveurs faisant autorité, comme le fait le résolveur public de FDN, ou comme le fait le petit résolveur Knot qui est chez moi.
Re: Conseils sur la configuration DNS d'un serveur
On Fri, Sep 22, 2023 at 04:55:05PM +0200, Olivier wrote a message of 11 lines which said: > > Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en > > direct. > > > Je n'avais pas compris que c'était possible ! Tout le monde peut installer un vrai résolveur (qui parle directement aux serveurs faisant autorité). Enfin, pour l'instant : parions que le gouvernement va proposer une loi pour interdire cela.
Re: Conseils sur la configuration DNS d'un serveur
Le ven. 22 sept. 2023 à 15:20, Michel Verdier a écrit : > > Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en > direct. > Je n'avais pas compris que c'était possible ! Merci à Michel et Stéphane pour leur réponse qui change pas mal de choses.
Re: Conseils sur la configuration DNS d'un serveur
Le ven. 22 sept. 2023 à 15:03, Stephane Bortzmeyer a écrit : > - pourquoi d'ailleurs utiliser un résolveur en aval, plutôt que de > parler directement aux serveurs faisant autorité ? Quand on installe sur sa machine, un logiciel comme Unbound, celui-ci sait-il directement interroger les serveurs DNS centraux qui gèrent les .com, .fr et autres (ie sans passer par les serveurs comme 1.1.1.1 ou autres ) ?
Re: Conseils sur la configuration DNS d'un serveur
On Fri, Sep 22, 2023 at 11:01:52AM +0200, Olivier wrote a message of 48 lines which said: > - pour chaque VLAN, j'aimerai pouvoir désigner un fichier > /etc/hosts.vlanx dans lequel je liste quelques ressources locales > (imprimante, ...) pouvant être résolues. Hmmm, ça va sérieusement compliquer les choses (et le déboguage !). À part avec les vues, je ne vois pas comment faire. > Vis à vis du DNS amont, j'utilise un fichier /etc/resolv.conf dont le > contenu est: > options rotate timeout:1 retries:1 > search monsuperdomain.lan > nameserver 1.1.1.1 > nameserver 9.9.9.9 Alors, quatre remarques : - pourquoi utiliser des résolveurs étatsuniens qui font Dieu sait quoi des données récoltées ? - pourquoi d'ailleurs utiliser un résolveur en aval, plutôt que de parler directement aux serveurs faisant autorité ? - /etc/resolv.conf est pour les clients finaux, pas pour un résolveur, - avoir à la fois un résolveur non menteur et un menteur va être assez cauchemardesque pour le déboguage. > 1. Préférez-vous séparer le paramétrage DNS amont (/etc/resolv.conf) > de celui en aval ? Pas clair. Pas compris. > 2. Activer le DNSSEC engendre-t-il des difficultés pour > l'exploitant ? On est en 2023, tous les résolveurs sérieux valident avec DNSSEC. > Les utilisateurs lambda perçoivent-ils selon vous, des bénéfices ou > des inconvénients ? Bénéfice : sécurité Inconvénient : comme toutes les techniques de sécurité, ça peut bloquer des accès légitimes > 3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok > ou youtube, faut-il attendre des bénéfices avec du cache DNS (par > rapport à une configuration où les utilisateurs interrogent > directement des DNS publics) ? Tester. (En administration système, il faut mesurer, pas supposer.) > 4. Conseillez-vous unbound ? Si non, quelle alternative ? Unbound est très bien, mais Knot Resolver aussi.
Re: Conseils sur la configuration DNS d'un serveur
On Fri, Sep 22, 2023 at 02:02:36PM +0200, Michel Verdier wrote a message of 31 lines which said: > > 4. Conseillez-vous unbound ? Si non, quelle alternative ? > > bind9 est quand même LE serveur DNS. En 2023, c'est une affirmation très bizarre. Cela fait de nombreuses années qu'il existe de meilleurs logiciels. BIND est utile dans deux cas : - si on veut une option très exotique qui n'existe que sur BIND, - si on aime les patches de sécurité à appliquer en urgence tous les mois. > - forwarder en servant de cache Comem tous les résolveurs (encore heureux). > - mettre DNSSEC Comme tous les résolveurs (encore heureux). > Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en > direct. Comme tous les résolveurs (encore heureux).
Re: Conseils sur la configuration DNS d'un serveur
Le 22 septembre 2023 Olivier a écrit : > 3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok ou > youtube, faut-il attendre des bénéfices avec du cache DNS (par rapport > à une configuration où les utilisateurs interrogent directement des > DNS publics) ? un cache accélère nettement $ dig @cache netflix.com premier appel : ;; Query time: 11 msec deuxième appel : ;; Query time: 2 msec > > 4. Conseillez-vous unbound ? Si non, quelle alternative ? bind9 est quand même LE serveur DNS. Il permet de - forwarder en servant de cache - servir des zones internes selon le vlan avec les views ce qui dispense des /etc/hosts - mettre DNSSEC Et pas besoin de passer par quad9 ou cloudflare bind peut forwarder en direct.
Conseils sur la configuration DNS d'un serveur
Bonjour, J'ai besoin d'implémenter un serveur (sous Bullseye pour l'instant) qui va faire office de cache DNS pour les machines de réseaux locaux (une centaine de machines réparties dans plusieurs VLAN). Une précision importante: je ne maîtrise pas ces machines réparties dans plusieurs VLAN: il peut s'agir de smartphones, PC ou console de tout type. Mes besoins: - pour chaque VLAN, j'aimerai pouvoir désigner un fichier /etc/hosts.vlanx dans lequel je liste quelques ressources locales (imprimante, ...) pouvant être résolues. - si l'existence de cache DNS accélère la résolution DNS des machines du réseau local, tant mieux, sinon c'est pas grave. Vis à vis du DNS amont, j'utilise un fichier /etc/resolv.conf dont le contenu est: options rotate timeout:1 retries:1 search monsuperdomain.lan nameserver 1.1.1.1 nameserver 9.9.9.9 Je découvre unbound qui m'a l'air de bien coller à mes besoins. Mes questions: 1. Préférez-vous séparer le paramétrage DNS amont (/etc/resolv.conf) de celui en aval ? 2. Activer le DNSSEC engendre-t-il des difficultés pour l'exploitant ? Les utilisateurs lambda perçoivent-ils selon vous, des bénéfices ou des inconvénients ? 3. Quand on sert des utilisateurs qui consomment du Netflix, TikTok ou youtube, faut-il attendre des bénéfices avec du cache DNS (par rapport à une configuration où les utilisateurs interrogent directement des DNS publics) ? 4. Conseillez-vous unbound ? Si non, quelle alternative ? Slts
Re: problem with local DNS
Sorry for the double post but I did not see the first answer any where. Thank you. It was a lot easier than I thought it would be. Again Thank you. On 6/5/23 3:45 AM, Brad Rogers wrote: On Mon, 05 Jun 2023 08:49:11 +0200 Michel Verdier wrote: Hello Michel, I already answered to your problem : I suspect OP is of the belief that we will respond to them directly and, as a consequence, they are not reading the list.
Re: problem with local DNS
On Mon, 05 Jun 2023 08:49:11 +0200
Michel Verdier wrote:
Hello Michel,
>I already answered to your problem :
I suspect OP is of the belief that we will respond to them directly and,
as a consequence, they are not reading the list.
--
Regards _ "Valid sig separator is {dash}{dash}{space}"
/ ) "The blindingly obvious is never immediately apparent"
/ _)rad "Is it only me that has a working delete key?"
Well I don't want you to think I'm being obscene
Fish - The Damned
pgpwHys5EQi9m.pgp
Description: OpenPGP digital signature
Re: Fwd: problem with local DNS
Le 5 juin 2023 Maureen L. Thomas a écrit : > Forwarded Message > Subject: problem with local DNS > > I am using a Lonova all in one computer with the latest debian on it. > Bullseye is working fine except for the warning I get as follows: your > current proxy settings do not allow local DNS req > (network.proxy.socks_remote)dns). I already answered to your problem : > I suppose this message is from firefox and is about > network.proxy.socks_remote_dns. If so look at > > https://superuser.com/questions/103593/how-to-do-dns-through-a-proxy-in-firefox Did you read and follow this link ?
Fwd: problem with local DNS
Forwarded Message Subject:problem with local DNS Date: Fri, 2 Jun 2023 18:53:47 -0400 From: Maureen L Thomas To: debian-user@lists.debian.org I am using a Lonova all in one computer with the latest debian on it. Bullseye is working fine except for the warning I get as follows: your current proxy settings do not allow local DNS req (network.proxy.socks_remote)dns). I have the nordvpn installed and I wonder if that is part of the problem. Or maybe not. I do not want to get rid of the vpn if at all possible. I appreciate your help. Intel® Core™ i3-9100T CPU @ 3.10GHz × 4, Mesa Intel® UHD Graphics 630 (CFL GT2). Moe
Re: problem with local DNS
Le 3 juin 2023 Maureen L. Thomas a écrit : > I am using a Lonova all in one computer with the latest debian on it. > Bullseye is working fine except for the warning I get as follows: your > current proxy settings do not allow local DNS req > (network.proxy.socks_remote)dns). I suppose this message is from firefox and is about network.proxy.socks_remote_dns. If so look at https://superuser.com/questions/103593/how-to-do-dns-through-a-proxy-in-firefox
problem with local DNS
I am using a Lonova all in one computer with the latest debian on it. Bullseye is working fine except for the warning I get as follows: your current proxy settings do not allow local DNS req (network.proxy.socks_remote)dns). I have the nordvpn installed and I wonder if that is part of the problem. Or maybe not. I do not want to get rid of the vpn if at all possible. I appreciate your help. Intel® Core™ i3-9100T CPU @ 3.10GHz × 4, Mesa Intel® UHD Graphics 630 (CFL GT2). Moe
Re: bind9 and dns forward
Le 1 juin 2023 Bonno Bloksma a écrit : >> If you get an answer it's a dnssec problem with the error message in your >> logs. If there is no answer it's another problem. > Well, it seems I get an answer with the +cd option, and none without. Yes. If I do : # dig tio.nl A +dnssec +multiline ; <<>> DiG 9.18.12-1~bpo11+1-Debian <<>> tio.nl A +dnssec +multiline ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15946 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: b5616e99dab9dfa201006479183bc71c1f369d50dcb2 (good) ;; QUESTION SECTION: ;tio.nl.IN A ;; ANSWER SECTION: tio.nl. 3600 IN A 188.166.202.179 tio.nl. 3600 IN RRSIG A 8 2 3600 ( 2023061500 2023052500 11454 tio.nl. M3ZcaxHNXwnmZ5SQnvMcPsUDPLQLpyl0RO7azsSWoUTx 6CgENJbWQuMqHyiQlzxeSnzVbfFIlKdbsBACFylJUhsT Mby5rp8ouOr8XOK2wC+qJvgYbl5SJwXePu0f1XgCxoAg P5/6ZnnXpo4gidVtxfUB68Ed5T6yxo23o0eI5gE= ) I get external dns answer with a nice dnssec. Can you do : dig @172.16.208.10 tio.nl A +dnssec +multiline to see if your internal dns answer the same rrsig
RE: bind9 and dns forward
Hi, @Tim, If I use the dnssec-validation no; option then indeed it all works. Just tested it again to make sure. And as a final solution to this problem I might accept it, but I would rather not. @Michel, > I reread all our mails and I miss to ask you this one (as answers via > external dns masked the real problem) : > dig tio.nl NS +cd Ok, with /etc/resolv.conf pointing only to localhost and option dnssec-validation auto; - linbobo:/etc/bind# dig tio.nl NS +cd ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS +cd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8565 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: f9edf2abbc6bb1b401006478e3bce0244f2a98d3724c (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; ANSWER SECTION: tio.nl. 3600IN NS amsstuddc-04.student.tio.nl. [... snip ...] tio.nl. 3600IN NS rtmstuddc-05.student.tio.nl. ;; Query time: 28 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 01 20:30:20 CEST 2023 ;; MSG SIZE rcvd: 568 linbobo:/etc/bind# dig tio.nl NS ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57482 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: eeb3f3a1c2495cf501006478e3c58effeec3959e9ccc (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; Query time: 188 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 01 20:30:29 CEST 2023 ;; MSG SIZE rcvd: 63 linbobo:/etc/bind# - > If you get an answer it's a dnssec problem with the error message in your > logs. If there is no answer it's another problem. Well, it seems I get an answer with the +cd option, and none without. [...] > And it's definitely not the good solution but you could transfer the full > zone (or get a copy of the file) and serve it as master. Nah, I do not want to do that. Too many updates on the internal zone, I would need to copy at least every 5 min. Also other reasons. Bonno Bloksma
Re: bind9 and dns forward
Le 1 juin 2023 Bonno Bloksma a écrit : > I can do that, but ... that is only for inbound traffic TO my dns server on > this network. > That part is working without any problem. Changing that will not change > anything for the clients on this network. You are right. I simply used to fix explicitely interfaces for security and it's not the point here. > My bind instance can reach the company dns server buy claims the response is > false/insecure > Does that maybe mean that my bind gets a "normal" response from the company > dns whereas the external dns at toplevel .nl. (being the parent zone) tells > that any response from a tio.nl dns server should be a secure response. And > therefore bind does not accept it? I reread all our mails and I miss to ask you this one (as answers via external dns masked the real problem) : dig tio.nl NS +cd If you get an answer it's a dnssec problem with the error message in your logs. If there is no answer it's another problem. > Where does bind store this info and can I overrule it? I am not sure but I think bind only cache in memory. And it's definitely not the good solution but you could transfert the full zone (or get a copy of the file) and serve it as master.
RE: bind9 and dns forward
On Thu, 1 Jun 2023, Bonno Bloksma wrote: My bind instance can reach the company dns server buy claims the response is false/insecure Does that maybe mean that my bind gets a "normal" response from the company dns whereas the external dns at toplevel .nl. (being the parent zone) tells that any response from a tio.nl dns server should be a secure response. And therefore bind does not accept it? Where does bind store this info and can I overrule it? /etc/bind/named.conf.options: dnssec-validation auto; You'll have to check the docs but I think setting this to no or none (I don't remember which) should mean that it doesn't complain. But this is rather brute force. There may be a cleaner way to do it for a single domain via trust anchors but it's not something I've tried to do. Tim.
RE: bind9 and dns forward
Hi,
>> linbobo:~# ss -nap | grep named
>> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
>> users:(("named",pid=554,fd=78))
>> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
>> users:(("named",pid=554,fd=71))
>> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
>> users:(("named",pid=554,fd=94))
> You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on this
> interface.
I can do that, it is just default to listen on all local ip's.
But that is also just inbound traffic as far as I know, that has nothing to do
with what ip number bind itself uses to get info from other (company) dns
servers.
> But you don't have real ipv6 on tun0. fe80:: is only assigned when there is
> no adress assigned for an interface.
Correct, the VPN tunnel is IPv4 only at this moment as the company network has
only partial IPv6 set up and is not using it over the whole network yet.
I am only sure to reach all servers via IPv4, including the dns servers. Which
is why I forward to the relevant ipv4 addresses.
> Usually fe80:: are local only and not routed.
Correct
> And bind use ipv6 first.
Yes, first, but not only. Also, there is no IPv6 address in the forward
statements.
> So I suspect that your vpn block ipv6 from your tun0 fe80::. Check your vpn
> configuration to setup a real ipv6 adress.
I cannot setup IPv6 on the VPN tunnel as the other side has no IPv6 address
yet. Also there is no route to the dns servers on ipv6 yet.
> Meanwhile change /etc/bind/named.conf.options to select only your good ip
>
> listen-on port 53 {
[]
>};
I can do that, but ... that is only for inbound traffic TO my dns server on
this network.
That part is working without any problem. Changing that will not change
anything for the clients on this network.
We are still left with the problem shown in the syslog:
--
Jun 1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure
response; parent indicates it should be secure
Jun 1 09:25:45 linbobo named[554]: insecurity proof failed resolving
'tio.nl/NS/IN': 172.16.128.40#53
Jun 1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure
response; parent indicates it should be secure
Jun 1 09:25:45 linbobo named[554]: insecurity proof failed resolving
'tio.nl/NS/IN': 172.16.208.10#53
--
My bind instance can reach the company dns server buy claims the response is
false/insecure
Does that maybe mean that my bind gets a "normal" response from the company dns
whereas the external dns at toplevel .nl. (being the parent zone) tells that
any response from a tio.nl dns server should be a secure response. And
therefore bind does not accept it?
Where does bind store this info and can I overrule it?
Bonno Bloksma
Re: bind9 and dns forward
Le 1 juin 2023 Bonno Bloksma a écrit :
> linbobo:~# ss -nap | grep named
> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
> users:(("named",pid=554,fd=78))
> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
> users:(("named",pid=554,fd=71))
> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
> users:(("named",pid=554,fd=94))
You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on
this interface. But you don't have real ipv6 on tun0. fe80:: is only
assigned when there is no adress assigned for an interface. Usually fe80::
are local only and not routed. And bind use ipv6 first. So I suspect that
your vpn block ipv6 from your tun0 fe80::. Check your vpn configuration
to setup a real ipv6 adress.
Meanwhile change /etc/bind/named.conf.options to select only your good ip
listen-on port 53 {
127.0.0.1;
172.16.17.1;
172.16.1.138;
};
listen-on-v6 port 53 {
::1;
2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3;
# add here real ipv6 from vpn when setup
};
RE: bind9 and dns forward
Hi,
> resolv.conf must have only one search entry. And you don't want to resolv
> with google directly. So you should have :
Ok, I have the google dns commented. Alhough Now I remember why I had the
google dns in there. ;-)
For my machine to create the VPN it needs to know the ip number of the gateway.
I fixed that for now with an entry in the /etc/hosts file. :-)
>> When booting if the internal bind is not up and running yet some services
>> might need a resolver so I have 8.8.8.8 in there as well as a second dns
>> entry.
> Ensure this in services ordering (systemd or initd). It's better and safer.
> And I think it's better to get an error than a false result from bind.
Ok, I get it.
--
linbobo:~# rndc flush
linbobo:~# dig tio.nl NS
; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49974
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 52571ae710dcd2cc01006478463be41c8b3a2afd14a5 (good)
;; QUESTION SECTION:
;tio.nl.IN NS
;; Query time: 244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 01 09:18:19 CEST 2023
;; MSG SIZE rcvd: 63
--
Hmm, no answer, that is weird.
--
linbobo:~# ss -nap | grep named
u_dgr UNCONN0 0 * 17532
* 12035 users:(("named",pid=554,fd=3))
u_str ESTAB 0 0 * 17082
* 17525
users:(("named",pid=554,fd=2),("named",pid=554,fd=1))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=83))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=85))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=84))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=82))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=49))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=50))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=51))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=52))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=39))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=38))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=40))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=37))
udp UNCONN0 0 [::1]:53
[::]:* users:(("named",pid=554,fd=60))
udp UNCONN0 0 [::1]:53
[::]:* users:(("named",pid=554,fd=58))
udp UNCONN0 0
Re: bind9 and dns forward
Le 19 mai 2023 Bonno Bloksma a écrit : > Been a few busy week, that is why I only respond now, sory. Same for me :/ > beheerdertio@linbobo:~$ cat /etc/resolv.conf > domain bobo.xs4all.nl > search bobo.xs4all.nl > search tio.nl > search staf.tio.nl > search student.tio.nl > nameserver 127.0.0.1 > nameserver 8.8.8.8 resolv.conf must have only one search entry. And you don't want to resolv with google directly. So you should have : domain bobo.xs4all.nl search bobo.xs4all.nl tio.nl staf.tio.nl student.tio.nl nameserver 127.0.0.1 > When booting if the internal bind is not up and running yet some services > might need a resolver so I have 8.8.8.8 in there as well as a second dns > entry. Ensure this in services ordering (systemd or initd). It's better and safer. And I think it's better to get an error than a false result from bind. > linbobo:~# dig tio.nl NS > > ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 This is the point : your local dns don't find tio.nl NS and then ask somewhere else. 8.8.8.8 is in resolv.conf so you search tio.nl directly on it and it gives you your provider name server. Retry dig tio.nl NS with a clean resolv.conf and also ss -nap | grep named
RE: bind9 and dns forward
Hi, Been a few busy week, that is why I only respond now, sory. Also as there is a lot of sensitive info in this mail, like a complete lost to domain controllers to be hacked, ;-) I am sending it direct. I will send a redacted version to the list >> What does +cd do? I was unable to find it in the man page. > it disable dnssec checks, was just in case of real dnssec problem Aha, ok clear. > can you give full /etc/resolv.conf > from your result you should have 127.0.0.1 in it but just to be sure beheerdertio@linbobo:~$ cat /etc/resolv.conf domain bobo.xs4all.nl search bobo.xs4all.nl search tio.nl search staf.tio.nl search student.tio.nl nameserver 127.0.0.1 nameserver 8.8.8.8 When booting if the internal bind is not up and running yet some services might need a resolver so I have 8.8.8.8 in there as well as a second dns entry. > and also : > dig tio.nl NS > dig @172.16.208.10 tio.nl NS linbobo:~# dig tio.nl NS ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: bfc026467d702f7d01006467377dffdb068b3e9c0a69 (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; Query time: 32 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 19 10:46:53 CEST 2023 ;; MSG SIZE rcvd: 63 linbobo:~# dig @172.16.208.10 tio.nl NS ; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 tio.nl NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13283 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;tio.nl.IN NS ;; ANSWER SECTION: tio.nl. 3600IN NS hgltiodc-04.tio.nl. [] tio.nl. 3600IN NS amsstuddc-04.student.tio.nl. ;; ADDITIONAL SECTION: hgltiodc-04.tio.nl. 3600IN A 172.16.128.40 [...] amsstuddc-04.student.tio.nl. 1200 INA 172.16.196.11 ;; Query time: 20 msec ;; SERVER: 172.16.208.10#53(172.16.208.10) ;; WHEN: Fri May 19 10:48:07 CEST 2023 ;; MSG SIZE rcvd: 816 Bonno Bloksma
Re: bind9 and dns forward
Le 8 mai 2023 Bonno Bloksma a écrit : > I also do not understand this difference when querying the internal dns > server directly. > Why does the +trace +cd not show an answer but when I leave them out I get a > correct answer. Is that because +trace forces it to start at the root which is > irrelevant when trying to get an answer from an internal dns server? yes > What does +cd do? I was unable to find it in the man page. it disable dnssec checks, was just in case of real dnssec problem can you give full /etc/resolv.conf from your result you should have 127.0.0.1 in it but just to be sure and also : dig tio.nl NS dig @172.16.208.10 tio.nl NS
RE: bind9 and dns forward
Hi, >> linbobo:/etc/bind# cat named.conf.local > > You have only zone blocks in this file, right ? Yes, > And you don't use views ? I have no idea what they would do, but no. The word view is not in that file. > Why does it first go to the public dns and then run into the dnssec problem? > There is a direct definition for the tio.nl zone in my config file. The public dns don't answer at all, so dnssec problem is only a consequence. The main problem seems to be the broken forwarding. Do you restart or flush your bind before the queries ? I suppose you do but... :) Just did a flush and then a query. It still seems to query the public dns and not (exclusively) forward the request. linbobo:/etc/bind# dig einsccmdp-01.tio.nl +trace +cd ; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd ;; global options: +cmd . 279702 IN NS c.root-servers.net. . 279702 IN NS m.root-servers.net. . 279702 IN NS k.root-servers.net. . 279702 IN NS a.root-servers.net. . 279702 IN NS b.root-servers.net. . 279702 IN NS i.root-servers.net. . 279702 IN NS e.root-servers.net. . 279702 IN NS g.root-servers.net. . 279702 IN NS d.root-servers.net. . 279702 IN NS h.root-servers.net. . 279702 IN NS j.root-servers.net. . 279702 IN NS f.root-servers.net. . 279702 IN NS l.root-servers.net. . 279702 IN RRSIG NS 8 0 518400 2023051805 2023050504 60955 . Yz1mgXTG4kStmPrjvxu3iQsekhdLfu3KeyZT26ebRPDeUnRUz/ajenhi jNj4FA6krNnCI1hfU0htq/10iADDnc35NTtGA6PodoTa8qf75l9UZ/Cc 59FRaH7sEDgjXcvts0X2R85aHofogRRcp77ufoetwSS0KZRsbJ5vBbq2 J4UIbKNHCZP0anl8+qmDmiMNy3VJYcUwePT6qDUBMe2fhktmU6w1RLSe 3xGV1dIFONSdZJeQxsJkWBXa5HnBN1Vl8iw6eDKauJDw6LL41fd8XzSk CYfl79f92z2tVv5q3l1G8fN3C+KJ33J1Y/hivBSe2FmVuwRkbr1mddH0 4m4LLw== ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms nl. 172800 IN NS ns1.dns.nl. nl. 172800 IN NS ns3.dns.nl. nl. 172800 IN NS ns4.dns.nl. nl. 86400 IN DS 34112 8 2 3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22 nl. 86400 IN RRSIG DS 8 1 86400 2023052105 2023050804 60955 . ORTn1H1ik3trq8VJQAVQ1nx4rrVZNEpoy9JZ/23pOjysRe9BWlXcCIK4 9LO3olfaXGFMDMWT3RtlSO3XFc7gPw38y2yfSRN8LWMkY0LzmOoLNxLO owY9dqQDfrvZK++EsWWmen0db3u/G07/cVWgb3IO0W9OVioQqko6ryes S9rlwbZY7lrPcohjWbUQ/uKBnhyN9yQs0sU8b+v3EbIudSzAa2zz5Bep ZA/XcnP+I9KNHqOREEfAuUG8moCP3VYFwarIkAgQeg/pE/typQZuxHUS QYY6LEfUpZVVO6i0NAHmqRlOZe2LmIHPWO7FBjK6YZtxyLbNkjyWjjvr kf4bVg== ;; Received 573 bytes from 192.58.128.30#53(j.root-servers.net) in 92 ms tio.nl. 3600IN NS ns3.argewebhosting.nl. tio.nl. 3600IN NS ns1.argewebhosting.eu. tio.nl. 3600IN NS ns2.argewebhosting.com. tio.nl. 3600IN DS 33829 8 2 81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3 tio.nl. 3600IN RRSIG DS 8 2 3600 20230522040659 20230508070836 50076 nl. kTSEJYjimMe4Kvdl6kc4gPF2OLn04nhuGDp4ppYbfxwPKZEzXb3GSY68 3SPqHYTuOvwTeDnGQ1brG7l9N6EJRdgy9rG69/Irj1/aUZT27M5BBN3h r9y7dZQAfdZVDSy7zXUgAYy9AdOf+JeLhIeVhrbxD+NYBXaJOe9r3gtj F6s= ;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms tio.nl. 3600IN SOA ns1.argewebhosting.eu. hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600 tio.nl. 3600IN RRSIG SOA 8 2 3600 2023051800 2023042700 11454 tio.nl. JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0= kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs +XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg= oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi Mpqu1Dw/NSu
Re: bind9 and dns forward
Le 5 mai 2023 Bonno Bloksma a écrit : > linbobo:/etc/bind# cat named.conf.local You have only zone blocks in this file, right ? And you don't use views ? > Why does it first go to the public dns and then run into the dnssec problem? > There is a direct definition for the tio.nl zone in my config file. The public dns don't answer at all, so dnssec problem is only a consequence. The main problem seems to be the broken forwarding. Do you restart or flush your bind before the queries ? I suppose you do but... :) Your tio.nl zone seems correct. Could you provide full /etc/bind/named.conf.options and /etc/bind/named.conf ?
RE: bind9 and dns forward
And just to make sure it realy was my own bind responding - linbobo:/etc/bind# dig einsccmdp-01.tio.nl @127.0.0.1 +trace +cd ; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl @127.0.0.1 +trace +cd ;; global options: +cmd . 518297 IN NS b.root-servers.net. . 518297 IN NS l.root-servers.net. . 518297 IN NS e.root-servers.net. . 518297 IN NS d.root-servers.net. . 518297 IN NS i.root-servers.net. . 518297 IN NS a.root-servers.net. . 518297 IN NS g.root-servers.net. . 518297 IN NS f.root-servers.net. . 518297 IN NS c.root-servers.net. . 518297 IN NS h.root-servers.net. . 518297 IN NS j.root-servers.net. . 518297 IN NS k.root-servers.net. . 518297 IN NS m.root-servers.net. . 518297 IN RRSIG NS 8 0 518400 2023051805 2023050504 60955 . Yz1mgXTG4kStmPrjvxu3iQsekhdLfu3KeyZT26ebRPDeUnRUz/ajenhi jNj4FA6krNnCI1hfU0htq/10iADDnc35NTtGA6PodoTa8qf75l9UZ/Cc 59FRaH7sEDgjXcvts0X2R85aHofogRRcp77ufoetwSS0KZRsbJ5vBbq2 J4UIbKNHCZP0anl8+qmDmiMNy3VJYcUwePT6qDUBMe2fhktmU6w1RLSe 3xGV1dIFONSdZJeQxsJkWBXa5HnBN1Vl8iw6eDKauJDw6LL41fd8XzSk CYfl79f92z2tVv5q3l1G8fN3C+KJ33J1Y/hivBSe2FmVuwRkbr1mddH0 4m4LLw== ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms nl. 172800 IN NS ns1.dns.nl. nl. 172800 IN NS ns3.dns.nl. nl. 172800 IN NS ns4.dns.nl. nl. 86400 IN DS 34112 8 2 3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22 nl. 86400 IN RRSIG DS 8 1 86400 2023051805 2023050504 60955 . n2RgQwHUOPq0Kfit0Fs3PJx+xiSsSeZqOtzw0oq5BU0CBhM6WN75Gw/T u+PIFd4NEFoS2T3Y+mGuQb7PfvGNOFHbRzp1rwHrgj5GzgS3nCih9jOF wPNytFVYhJ/RqfD80dMwShZAs2OxlVIfD7UYEjUs/ZC38PreGAoHedQI wp8lECv80cr+zFHtPHh5RiW1Clg4TDWmlzOsa8y9FOH3acTM+kFjnnaQ se2p0ZciZk8B7aNoxG468JQnQHHKRbxQgn8wxM0ttHKkpmwZHvL7bfhE CH+akGcz/g4TFQA88B9eHTe0AqcUcHsPhBmB/uySv3FAiO0myKsQwuC+ 8vORCg== ;; Received 605 bytes from 2001:7fe::53#53(i.root-servers.net) in 8 ms tio.nl. 3600IN NS ns3.argewebhosting.nl. tio.nl. 3600IN NS ns2.argewebhosting.com. tio.nl. 3600IN NS ns1.argewebhosting.eu. tio.nl. 3600IN DS 33829 8 2 81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3 tio.nl. 3600IN RRSIG DS 8 2 3600 20230516084745 20230501190734 50076 nl. HU8NwsPjKyakNkwXofrXCi6myG361X7PYkKbenuMz+idBTsOJxQDGmVp QAGsuI35V0zDKV4qhjCXH9DLfoPhktYMvQF1S87OrAVT8EKVMYOEbzmH e1KyXWXFIYoJnZxjL+peKL4KMKmlBn2ZbAZ2CjrEaCQU+JoQNK/rjL61 y+g= ;; Received 408 bytes from 2001:678:20::24#53(ns3.dns.nl) in 16 ms tio.nl. 3600IN SOA ns1.argewebhosting.eu. hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600 tio.nl. 3600IN RRSIG SOA 8 2 3600 2023051800 2023042700 11454 tio.nl. JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0= kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs +XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg= oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS owv7naAaZy4Tv83zMcNYjivcM2wV4PCKX9nM1TQieRwB9nBx5+QnvUkX KvI= o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN NSEC3 1 0 1 AB OJI66FT00RG1TJD4KC30VNO3GBKRUU91 CNAME RRSIG o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. FGm7FofqjWiWd+9Bj7oNaLqraLyajz7rugO7N7ctd8ZKT14qcEfGkrgV zghw+Zpnda4Hb7aGomdsZ/XdiJorXRZRWQD5Qcirm1YEoZwAAbLyyJK0 qfn3g8SRuVH51nVOOr7WfeZRMVXOlgYSrRnYGlsGQfg/y7or/1qrGnxM 8gM= ;; Received 1029 bytes from 2a05:1500:702:0:1c00:eff:fe00:ce#53(ns1.argewebhosting.eu) in 12 ms --------- And
Re: bind9 and dns forward
Le 2 mai 2023 Bonno Bloksma a écrit :
> linbobo:/etc/bind# cat named.conf.local
> ---
> []
> zone "tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "staf.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "student.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
> The problem is not that the company dns servers are not working, it is that
> it somehow thinks the answers are not valid, not even for the top level
> domain.
In fact you don't resolv at all. Can you provide:
dig einsccmdp-01.tio.nl +trace +cd
dig @172.16.208.10 einsccmdp-01.tio.nl
(this one to eliminate 172.16.208.10 beeing broken)
I don't understand why you define staf.tio.nl and student.tio.nl as
tio.nl is already on the same forwarders. I don't know if it's valid but
it seems useless. And your logs suggest a problem between staf.tio.nl and
tio.nl. Could you comment staf.tio.nl and student.tio.nl, restart bind
(or reload + flush) and try again above dig ?
RE: bind9 and dns forward
Hi, Lots of info and log quotes. I hope you can find the "normal" text. >> We use a different dns server(s) and zonefile for the external dns >> environment from what we use internally. Company dns is Windows server 2016 >> incase that is relevant. > > It's better to use dig (package bind9-dnsutils) to first eliminate problems > on other DNS. Give us: > > dig @13.107.206.240 trafficmanager.net SOA dig @13.107.206.240 > outlook.ha.office365.com IN dig @172.16.128.40 vijl.staf.tio.nl dig > @172.16.128.10 vijl.staf.tio.nl Yes I also have dig. About your 4 dig statements. Like I wrote the problem with office365 is not MY problem, that is a Microsoft problem. And even though I have a working ipv6 environment at home I do not have a working ipv6 VPN tunnel to work, nor do we use ipv6 there internally. So here are the ipv4 results. As you can see there is a working dns server at those 2 ip numbers. -- linbobo:/etc/bind# dig @172.16.128.40 vijl.staf.tio.nl A ; <<>> DiG 9.16.37-Debian <<>> @172.16.128.40 vijl.staf.tio.nl A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61639 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; ANSWER SECTION: vijl.staf.tio.nl. 1200IN A 172.16.72.97 ;; Query time: 8 msec ;; SERVER: 172.16.128.40#53(172.16.128.40) ;; WHEN: Tue May 02 11:20:52 CEST 2023 ;; MSG SIZE rcvd: 61 linbobo:/etc/bind# dig @172.16.208.10 vijl.staf.tio.nl A ; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 vijl.staf.tio.nl A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12968 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; ANSWER SECTION: vijl.staf.tio.nl. 1200IN A 172.16.72.97 ;; Query time: 16 msec ;; SERVER: 172.16.208.10#53(172.16.208.10) ;; WHEN: Tue May 02 11:21:04 CEST 2023 ;; MSG SIZE rcvd: 61 -- But if I query my own bind server... -- linbobo:~# dig vijl.staf.tio.nl ; <<>> DiG 9.16.37-Debian <<>> vijl.staf.tio.nl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 63ecb9edc2f5036e01006450d2a73c1c133db0bfc629 (good) ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; Query time: 12 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 02 11:06:47 CEST 2023 ;; MSG SIZE rcvd: 73 And from /var/log/syslog May 2 11:06:32 linbobo named[574]: DNS format error from 172.16.128.40#53 resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response May 2 11:06:32 linbobo named[574]: FORMERR resolving 'vijl.staf.tio.nl//IN': 172.16.128.40#53 May 2 11:06:32 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:32 linbobo named[574]: no valid RRSIG resolving 'staf.tio.nl/DS/IN': 172.16.128.40#53 May 2 11:06:32 linbobo named[574]: DNS format error from 172.16.208.10#53 resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response May 2 11:06:32 linbobo named[574]: FORMERR resolving 'vijl.staf.tio.nl//IN': 172.16.208.10#53 May 2 11:06:32 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:32 linbobo named[574]: no valid RRSIG resolving 'staf.tio.nl/DS/IN': 172.16.208.10#53 May 2 11:06:32 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl/A/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:35 linbobo named[574]: no valid RRSIG resolving 'student.tio.nl/DS/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:35 linbobo named[574]: no valid RRSIG resolving 'student.tio.nl/DS/IN': 172.16.208.10#53 May 2 11:06:35 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl.student.tio.nl/A/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl.student.tio.nl//IN': 172.16.128.40#53 May 2 11:06:47 linbobo named[574]: validating vi
Re: bind9 and dns forward
Le 28 avril 2023 Bonno Bloksma a écrit : > We use a different dns server(s) and zonefile for the external dns > environment from what we use internally. Company dns is Windows server 2016 > incase that is relevant. It's better to use dig (package bind9-dnsutils) to first eliminate problems on other DNS. Give us: dig @13.107.206.240 trafficmanager.net SOA dig @13.107.206.240 outlook.ha.office365.com IN dig @172.16.128.40 vijl.staf.tio.nl dig @172.16.128.10 vijl.staf.tio.nl > Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53 > resolving staf.tio.nl/ for client 172.16.17.11#65033: Name tio.nl (SOA) > not subdomain of zone staf.tio.nl -- invalid response I suppose you reboot after your upgrade ? Do you have defined somewhere on linbobo a zone staf.tio.nl ? I guess not but do a grep just to be sure.
bind9 and dns forward
Hello, I have a Debian machine at my home network performing several functions. Two of those are dns server for my network at home and a VPN server to the company network. To facilitate my use of the VPN to the company network I am also forwarding all dns requests tot the company domain to the internal dns servers. A few months ago we had a change in our external dns provider and they enabled secure dns. After that I had some (security?) problems getting bind to forward my internal dns servers. My guess was that somehow it would see the security for the domain at the .nl level and it would be different from the internal response at the tio.nl domain. My resolution at that time was simply to rely exclusively on the company dns servers and just use the internal ip number for the few devices I needed to access at home. However, strangely enough when I went back a while later to test what was the real problem I could not reproduce it and I could once again resolve the normal dns requests against the internet dns servers and also forward the requests for the company servers to the company dns servers. Today I did an upgrade from Buster to Bullseye and the problem is back. :-( Can someone help me analyze the errors and point to a way to find out what is really wrong? We use a different dns server(s) and zonefile for the external dns environment from what we use internally. Company dns is Windows server 2016 incase that is relevant. Earlier in the day I had syslog lines like: --- Apr 28 03:18:14 linbobo named[546]: DNS format error from 13.107.206.240#53 resolving outlook.ha.office365.com/TYPE65 for client 172.16.17.83#61019: Name trafficmanager.net (SOA) not subdomain of zone ha.office365.com -- invalid response Apr 28 03:18:15 linbobo named[546]: FORMERR resolving 'outlook.ha.office365.com/TYPE65/IN': 13.107.206.240#53 --- Which seems to be an error at Microsoft. And regarding my connection to the company dns: --- Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53 resolving staf.tio.nl/ for client 172.16.17.11#65033: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:53 linbobo named[546]: FORMERR resolving 'staf.tio.nl//IN': 172.16.128.40#53 Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.208.10#53 resolving staf.tio.nl/ for client 172.16.17.11#65033: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:53 linbobo named[546]: FORMERR resolving 'staf.tio.nl//IN': 172.16.208.10#53 Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53 resolving om1stafdc-04.staf.tio.nl/ for client 172.16.17.11#53605: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:53 linbobo named[546]: FORMERR resolving 'om1stafdc-04.staf.tio.nl//IN': 172.16.128.40#53 Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.208.10#53 resolving om1stafdc-04.staf.tio.nl/ for client 172.16.17.11#53605: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:53 linbobo named[546]: FORMERR resolving 'om1stafdc-04.staf.tio.nl//IN': 172.16.208.10#53 Apr 28 12:07:54 linbobo named[546]: DNS format error from 172.16.128.40#53 resolving hglstafdc-04.staf.tio.nl/ for client 172.16.17.11#53673: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:54 linbobo named[546]: FORMERR resolving 'hglstafdc-04.staf.tio.nl//IN': 172.16.128.40#53 Apr 28 12:07:54 linbobo named[546]: DNS format error from 172.16.208.10#53 resolving hglstafdc-04.staf.tio.nl/ for client 172.16.17.11#53673: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:07:54 linbobo named[546]: FORMERR resolving 'hglstafdc-04.staf.tio.nl//IN': 172.16.208.10#53 Apr 28 12:08:06 linbobo named[546]: DNS format error from 172.16.128.40#53 resolving vijl.staf.tio.nl/ for client 172.16.17.11#52409: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response Apr 28 12:08:06 linbobo named[546]: FORMERR resolving 'vijl.staf.tio.nl//IN': 172.16.128.40#53 Apr 28 12:08:06 linbobo named[546]: DNS format error from 172.16.208.10#53 resolving vijl.staf.tio.nl/ for client 172.16.17.11#52409: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response --- I would like to know which error the Windows dns servers provides and what I need to do to get rid of these errors. However, in the end I DID get my response it seems as my PC was able to connect to the servers via the dns name. After the upgrade I have syslog lines like: --- Apr 28 16:25:09 linbobo named[574]: FORMERR resolving 'AMSSTAFDC-05.staf.tio.nl//IN': 172.16.208.10#53 Apr 28 16:25:09 linbobo named[574]: DNS format error from 172.16.208.10#53
Re: debian for DNS servers
Hi, On Sat, Mar 11, 2023 at 05:56:00PM +0800, cor...@free.fr wrote: > Now I have three debian nodes in different DCs. > Can I deploy a distributed DNS service for fault tolerance? I assume you mean to run an authoritative DNS service, that provides answers to queries against the DNS zones they are responsible for, as opposed to recursive DNS resolver services. While you COULD put recursive resolvers on each of these nodes, they should really be local to their clients. Assuming each of these hosts has at least one globally routable IP address and port 53 UDP and TCP traffic is allowed, then there's likely no reason why you can't install any of several free authoritative DNS server implementations (even a mix) and have it work fine. Do you have more specific questions? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: debian for DNS servers
cor...@free.fr wrote: > Now I have three debian nodes in different DCs. > Can I deploy a distributed DNS service for fault tolerance? You need to say what you want more specifically. Do you want to provide the same services (web servers, usually) on all three nodes with the ability to redirect traffic on failure? If so, automatically or manually? Do you want to do the above but load-balance traffic across all three all the time? Do you want to literally provide DNS resolution and/or authoritative answers from all three nodes? Tell us more. -dsr-
Re: debian for DNS servers
On 11/3/23 17:56, cor...@free.fr wrote: Now I have three debian nodes in different DCs. Can I deploy a distributed DNS service for fault tolerance? Assuming you don't mean a Windows DC, you can use bind (bind9) in an architecture that has a master for a DNS zone and multiple slaves. Changes to the zone you are interested in can be made on the master and automatically propagated to the slaves. In each DC you can configure DHCP or static configuration to make clients use DNS from their local DC as well as DNS from the other DCs as fallback. -- Jeremy (Lists)
