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)
debian for DNS servers
Now I have three debian nodes in different DCs. Can I deploy a distributed DNS service for fault tolerance? the first node (KVM, NL) # lsb_release -cd Description:Debian GNU/Linux 11 (bullseye) Codename: bullseye # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 193.36.132.10.0.0.0 UG0 0 0 eth0 The second (openstack, Dallas): # lsb_release -cd Description:Debian GNU/Linux 11 (bullseye) Codename: bullseye # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG0 0 0 ens3 The third (KVM, NL): # lsb_release -cd Description:Debian GNU/Linux 11 (bullseye) Codename: bullseye # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 5.255.106.1 0.0.0.0 UG0 0 0 eth0 Thanks. Corey H
Re: [HS] Ambiance (Re: Fuite de DNS avec mon client VPN)
--- Original Message --- Le lundi 9 janvier 2023 à 15:44, Sébastien NOBILI a écrit : > > > Bonjour, > > Le 2023-01-08 07:03, Olivier Back my spare a écrit : > > > Privacytools.io a tout ce que vous > > voulez mais il semble que votre kif soit de surfer en se faisant > > passer pour un autre. > > > Merci de cesser les attaques de ce genre. C'est déjà la deuxième depuis > la semaine dernière. On n'est pas abonnés ici pour lire ce genre de > choses. > > Sébastien +1 Hugues publickey - hlarrive@pm.me - 0xE9429B87.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[HS] Ambiance (Re: Fuite de DNS avec mon client VPN)
Bonjour, Le 2023-01-08 07:03, Olivier Back my spare a écrit : Privacytools.io a tout ce que vous voulez mais il semble que votre kif soit de surfer en se faisant passer pour un autre. Merci de cesser les attaques de ce genre. C'est déjà la deuxième depuis la semaine dernière. On n'est pas abonnés ici pour lire ce genre de choses. Sébastien
Re : Re: Fuite de DNS avec mon client VPN
Le dimanche 8 janvier 2023 à 07:03, Olivier Back my spare a écrit : > Je vais encore en fâcher plus d'un mais bon... Fâcher peut-être pas, mais agacer, ça se pourrait ! > Expressvpn dit que le premier élément qui est la cause des fuites DNS, > c'est le webrtc. Pourtant je croyais que vous aviez lu leur doc. > J'ai fait un test de fuites DNS et le webrtc est peut-être un autre problème. > Là, vous affirmez à l'aide d'un wiki douteux que le problème se situe au > niveau de /etc/resolv.conf. > Ca n'a rien de douteux, je m'en suis rendu compte hier, l'installation d'openvpn installe un script /etc/openvpn/update-resolv-conf, qui, s'il n'est pas appelé pour modifier /etc/resolv.conf, ça va laisser /etc/resolv.conf avec l'ip du serveur DNS de la box du FAI. Donc je passais par un VPN en continuant à interroger le serveur DNS de la box du FAI. C'est pas une fuite de DNS, c'est juste une erreur de config de ne pas avoir veillé à appeler /etc/openvpn/update-resolv-conf qui lui-même fait appel à /sbin/resolvconf et met à jour /etc/resolv.conf. > Jamais de la vie je ne toucherais en profondeur quelque chose qui n'est > même pas documenté dans ma distrib qui fait un bon 600 pages et encore > moins sur des wiki comme celui d'ubuntu, Debian ou Fedora. > C'est pas toucher en profondeur que faire en sorte de veiller à ce que le script /etc/openvpn/update-resolv-conf soit bien appelé et qu'il dispose de /sbin/resolvconf, de façon à ce que /etc/resolv.conf soit bien mi à jour au démarrage du démon VPN. Après avoir veillé à cela, il y a un avant et un après. Avant : www.dnsleaktest.com affichait le DNS de mon FAI ce qui est logique puisque c'est le DNS qui était affecté à nameserver /etc/resolv.conf. Après il ne pouvait plus le voir, car nameserver reçoit le DNS du VPN. Si vous avez des conseils à me donner pour faire en sorte que ma résolution de nom de domaine soit bien configurée par openvpn, sans faire cette manip, ils sont les bien venus. Cette manip n'est peut-être pas la façon la plus appropriée d'y parvenir. Mais ma config d'avant, qui consistait à continuer à interroger le DNS du FAI dans /etc/resolv.conf, plutôt que celui du VPN, n'était certainement appropriée. Et j'en ai la preuve par un teste www.dnsleaktest.com, avant et après. > > Vous ne cherchez pas comment fonctionne le VPN pour résoudre le > problème. Vous bidouillez sans savoir ce que vous faites pour un > nonsenese problème pour une nonsense raison. La sécurité comme vous le > prétendez n'est qu'un prétexte. Privacytools.io a tout ce que vous > voulez mais il semble que votre kif soit de surfer en se faisant passer > pour un autre. > Vos conseil pour bien configurer un client openvpn sous GNU/Linux Debian sont les bienvenus! Mais s'il vous plaît, tenons nous en au sujet : la config d'un client openvpn sur une distribution GNU/Linux Debian afin d'éviter une fuite de DNS. Et ne divaguez sur des théories psychologisantes de comptoir. Merci d'avance -- Benoît
Re: Fuite de DNS avec mon client VPN
Bonjour Je vais encore en fâcher plus d'un mais bon... Expressvpn dit que le premier élément qui est la cause des fuites DNS, c'est le webrtc. Pourtant je croyais que vous aviez lu leur doc. Là, vous affirmez à l'aide d'un wiki douteux que le problème se situe au niveau de /etc/resolv.conf. Jamais de la vie je ne toucherais en profondeur quelque chose qui n'est même pas documenté dans ma distrib qui fait un bon 600 pages et encore moins sur des wiki comme celui d'ubuntu, Debian ou Fedora. Vous ne cherchez pas comment fonctionne le VPN pour résoudre le problème. Vous bidouillez sans savoir ce que vous faites pour un nonsenese problème pour une nonsense raison. La sécurité comme vous le prétendez n'est qu'un prétexte. Privacytools.io a tout ce que vous voulez mais il semble que votre kif soit de surfer en se faisant passer pour un autre. Le 07/01/2023 à 17:07, benoit a écrit : Bonjour à toutes et tous, Il y a quelque temps, je vous avais demandé de l'aide entre autre concernant une fuite de DNS J'ai trouvé la solution ici https://steamforge.net/wiki/index.php/How_to_configure_OpenVPN_to_resolve_local_DNS_&_hostnames#Client_Mod <https://steamforge.net/wiki/index.php/How_to_configure_OpenVPN_to_resolve_local_DNS_&_hostnames#Client_Mod> Et ça empêche la fuite de DNS. Ce n'en était même pas une en fait, c'est juste mon /etc/resolv.conf qui n'était pas mi à jour par openvpn. Vu que /etc/resolv.conf continue à renseigner le DNS de ma box : nameserver 192.168.178.1 plutôt que celui du serveur VPN ben forcément. Donc en suivant la doc ci dessus ca résous le problème. Juste un détail , le fichier /etc/resolv.conf contient ceci quand le vpn fonctionne nameserver 10.71.0.1 nameserver 192.168.178.1 et juste nameserver 192.168.178.1 quand le vpn est stoppé serait-il possible de n'avoir que l'un ou l'autre ? Merci Benoit Envoyé avec la messagerie sécurisée Proton Mail <https://proton.me/>. -- Gestionnaire d'infrastructure/ Gestionnaire de parc informatique "It is possible to commit no errors and still lose. That is not a weakness. That is life." – Captain Jean-Luc Picard to Data
Fuite de DNS avec mon client VPN
Bonjour à toutes et tous, Il y a quelque temps, je vous avais demandé de l'aide entre autre concernant une fuite de DNS J'ai trouvé la solution ici https://steamforge.net/wiki/index.php/How_to_configure_OpenVPN_to_resolve_local_DNS_&_hostnames#Client_Mod Et ça empêche la fuite de DNS. Ce n'en était même pas une en fait, c'est juste mon /etc/resolv.conf qui n'était pas mi à jour par openvpn. Vu que /etc/resolv.conf continue à renseigner le DNS de ma box : nameserver 192.168.178.1 plutôt que celui du serveur VPN ben forcément. Donc en suivant la doc ci dessus ca résous le problème. Juste un détail , le fichier /etc/resolv.conf contient ceci quand le vpn fonctionne nameserver 10.71.0.1 nameserver 192.168.178.1 et juste nameserver 192.168.178.1 quand le vpn est stoppé serait-il possible de n'avoir que l'un ou l'autre ? Merci Benoit Envoyé avec la messagerie sécurisée [Proton Mail](https://proton.me/).
Re: Fanget i DNS - Nu undsluppet
Det ser godt ud. Jeg tror jeg dropper linuxbabe.com. Den 05.11.2022 kl. 10.07 skrev Adam Sjøgren: Flemming writes: Puha, sikke en jungle det er blevet at have sin egen mailserver! Det krævede en vis stædighed at hugge sig igennem junglen. Men mange tak for Jeres hjælp!!! Lars Ingebrigtsen - en af GNU Emacs' vedligeholdere - har lavet et script der løser problemet: "So You Want To Run Your Own Mail Server…" ·https://lars.ingebrigtsen.no/2020/03/25/so-you-want-to-run-your-own-mail-server/ quickdns.dk - nameserveren blev ikke accepteret af dk-hostmaster.dk Det lyder besynderligt. Beskeden ved navneserverskift var: NS records mangler på navneserver Jeg havde oprettet domænet på quickdns.dk. Det kan da godt være at det var en eller anden banalitet som var smuttet for mig. Men på det tidspunkt var jeg så træt af alle mulige mærkelige forviklinger på servere der påstod de havde gratis dns. Flem
Re: Fanget i DNS - Nu undsluppet
Flemming writes: > Puha, sikke en jungle det er blevet at have sin egen mailserver! Det > krævede en vis stædighed at hugge sig igennem junglen. Men mange tak > for Jeres hjælp!!! Lars Ingebrigtsen - en af GNU Emacs' vedligeholdere - har lavet et script der løser problemet: "So You Want To Run Your Own Mail Server…" · https://lars.ingebrigtsen.no/2020/03/25/so-you-want-to-run-your-own-mail-server/ > quickdns.dk - nameserveren blev ikke accepteret af dk-hostmaster.dk Det lyder besynderligt. Godt at høre at du fandt en kombination der virker for dig! Mvh. Adam -- "Check my heart and respirationAdam Sjøgren I feel I look a little pale a...@koldfront.dk I just missed another station I'm stepping off the carousel"
Re: Fanget i DNS - Nu undsluppet
Puha, sikke en jungle det er blevet at have sin egen mailserver! Det krævede en vis stædighed at hugge sig igennem junglen. Men mange tak for Jeres hjælp!!! Mine valg endte med at blive: VPS: contabo.com = Fordi der er reverse dns og åben port 25, og for 7,50€ fik jeg: 4 vCPU Cores 8 GB RAM 50 GB NVMeor 200 GB SSD 1 Snapshot 32 TB TrafficUnlimited Incoming Det kan vist ikke gøres bedre. Men man fik ikke umiddelbart ssh, men derimod vnc. Det fik jeg ikke til at virke. Men i adminpanelet var der en valgmulighed der hedder: I can't connect to this server. Her kan man så vælge SSH, og efter genstart virkede det perfekt. Hertil kommer Contabo et tysk firma så det er under EU-lovgivning, incl. GDPR. Gratis dns: dns.services == dns.services fungerede helt enkelt med både login og opsætning af dns samt skift af navneserver hos dk-hostmaster. Inden for minutter kunne jeg sende mails fra min contabo-server. Det er overbevisende. Mere eller mindre mislykkede eksempler på gratis dns: cloudflare.com - et trekantet system som det ikke lykkedes mig at få til at rigtig indrullere mit domæne. quickdns.dk - nameserveren blev ikke accepteret af dk-hostmaster.dk simply.com - kunne ikke finde noget sted at registrere dnsportal.dk og cloud.dk - kræver mitid registrering (rend og hop!) one.com - har vist ikke tænkt sig at fortsætte med gratis dns. Og der er en som beskrevet at han ikke kunne vride hans com-domæne ud af dem. Hvad angår VPS var det værste eksempel scaleway. Efter at have brugt en times tid på at få en billig instans, endte jeg med at få tilbudt en instans til 162 €/md. Jeg skrev så på deres chat at jeg bare ville have en stardust instans. Så svarede de at jeg først skulle identificere mig ... og det viste sig at være med pas og bla bla bla. Så lukkede jeg min konto. Eller rettere, jeg fik lov at anmode om det (request). Det betød dog at jeg ikke kunne komme ind på kontoen mere. Et par timer efter fik jeg en sms fra Nets med koden for den dollar jeg have acceptere at betale. Men det kunne jeg ikke, for de havde jo lukket min adgang! Da jeg ikke ville have inkasso på den dollar, skrev jeg til dem og bad om en faktura. Fjolserne svarede så at jeg bare skulle logge ind og betale ... Større amatører skal man vist lede længe efter. Det her har varet over en uge!!! Selvfølgelig ikke fuldtid, men Flemming Den 03.11.2022 kl. 19.28 skrev Adam Sjøgren: Flemming writes: Jeg har bemærket at der er danske alternativer med gratis dns. Er der nogle I kan anbefale? Der er QuickDNS:https://www.quickdns.dk/ - de har vist ikke support for DNSSEC, hvilket var en af grundene til at jeg har en minimal virtuel server hos hhv. Linode og Digital Ocean som jeg sammen med min hjemmeserver bruger til at køre DNS (og mail) selv. bind er lidt bøvlet at få sat op, men når det først kører, så kører det bare. Mht. reverse DNS og udbydere sætter Kviknet det op hvis man henvender sig til kundeservice. (Før Fullrate blev købt af YouSee kunne man selv konfigurere det i deres brugerinterface, det forsvandt naturligvis efter sammenlægningen.) For VPS'er har både Linode og Digital Ocean rDNS sat til hostnavnet for både IPv4 og IPv6 for mine to. Best regards, Adam
Re: Fanget i DNS
Flemming writes: > Jeg har bemærket at der er danske alternativer med gratis dns. Er der > nogle I kan anbefale? Der er QuickDNS: https://www.quickdns.dk/ - de har vist ikke support for DNSSEC, hvilket var en af grundene til at jeg har en minimal virtuel server hos hhv. Linode og Digital Ocean som jeg sammen med min hjemmeserver bruger til at køre DNS (og mail) selv. bind er lidt bøvlet at få sat op, men når det først kører, så kører det bare. Mht. reverse DNS og udbydere sætter Kviknet det op hvis man henvender sig til kundeservice. (Før Fullrate blev købt af YouSee kunne man selv konfigurere det i deres brugerinterface, det forsvandt naturligvis efter sammenlægningen.) For VPS'er har både Linode og Digital Ocean rDNS sat til hostnavnet for både IPv4 og IPv6 for mine to. Best regards, Adam -- "Many activities in life are either so difficult Adam Sjøgren or so boring and repetitive that we would like a...@koldfront.dk to delegate them to other people or to machines"
Re: Fanget i DNS
Den 03.11.2022 kl. 13.30 skrev Povl Ole Haarlev Olsen: On Thu, 3 Nov 2022, Flemming Bjerke wrote: Den 03.11.2022 kl. 11.29 skrev Povl Ole Haarlev Olsen: On Thu, 3 Nov 2022, Flemming Bjerke wrote: Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. Nåeh ja, selvfølgelig. Tak, for hjælpen!!! No problem... Før havde jeg mine domæner hos gratisdns. Nu er de flyttet til one.com. Men one.com er lidt trættende. Man skal hele sno sig uden om forskellige tilbud, og så er deres dns lidt begrænset. Jeg har det på samme måde. Sådan var det også for mig. Jeg løste problemet ved at få mine egne maskine godkendt hos DK Hostmaster og derefter flytte DNS for mine domains til min egne DNS servere. Måske ikke en løsning, der er god for alle, men den virker fint for mig. Jeg har også gjort dette med nogle domæner, som alternativ kan man oprette dem hos cloudflare.com, de kan køre navneservere på deres gratis web cache selvom det nok ikke er meningen at man kun bruger dem til DNS :) smime.p7s Description: S/MIME-signeret meddelelse
Re: Fanget i DNS
On Thu, 3 Nov 2022, Flemming Bjerke wrote: Den 03.11.2022 kl. 11.29 skrev Povl Ole Haarlev Olsen: On Thu, 3 Nov 2022, Flemming Bjerke wrote: Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. Nåeh ja, selvfølgelig. Tak, for hjælpen!!! No problem... Før havde jeg mine domæner hos gratisdns. Nu er de flyttet til one.com. Men one.com er lidt trættende. Man skal hele sno sig uden om forskellige tilbud, og så er deres dns lidt begrænset. Sådan var det også for mig. Jeg løste problemet ved at få mine egne maskine godkendt hos DK Hostmaster og derefter flytte DNS for mine domains til min egne DNS servere. Måske ikke en løsning, der er god for alle, men den virker fint for mig. -- Povl Ole
Re: Fanget i DNS
Den 03.11.2022 kl. 11.29 skrev Povl Ole Haarlev Olsen: On Thu, 3 Nov 2022, Flemming Bjerke wrote: Hvordan løser I problemer med reverse DNS? Jeg ved, at DanskNet, Telenor og YouSee alle tre understøtter rDNS. Og med et tryk på maven og en henvisning til RFC2317/BCP20 kan man endda få dem til at redelegere rDNS for en enkelt IP-adresse til nogle andre DNS servere end deres egne. Navneserveren er ikke registreret hos DK Hostmaster Du behøver ikke bruge samme DNS servere for forward og reverse DNS. Dit .dk domain skal ganske rigtigt være på nogle servere DK Hostmaster kender, men rDNS (dvs. PTR-recorden for .in-addr.arpa) bør være på mdns3.hostwindsdns.com, hvis det er den, der er auth DNS for rDNS domænet (mailserverens IP adresse skrevet baglæns og med ".in-addr.arpa" bagefter). Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. Nåeh ja, selvfølgelig. Tak, for hjælpen!!! Før havde jeg mine domæner hos gratisdns. Nu er de flyttet til one.com. Men one.com er lidt trættende. Man skal hele sno sig uden om forskellige tilbud, og så er deres dns lidt begrænset. Jeg har bemærket at der er danske alternativer med gratis dns. Er der nogle I kan anbefale? Forøvrigt havde virkelig problemer med at genopsætte min mailserver op på debian 11 i foråret. Det lykkedes først da jeg fulgte linuxbabe.com: https://www.linuxbabe.com/mail-server/build-email-server-from-scratch-debian-postfix-smtp Flemming
Re: Fanget i DNS
On Thu, 3 Nov 2022, Flemming Bjerke wrote: Hvordan løser I problemer med reverse DNS? Jeg ved, at DanskNet, Telenor og YouSee alle tre understøtter rDNS. Og med et tryk på maven og en henvisning til RFC2317/BCP20 kan man endda få dem til at redelegere rDNS for en enkelt IP-adresse til nogle andre DNS servere end deres egne. Navneserveren er ikke registreret hos DK Hostmaster Du behøver ikke bruge samme DNS servere for forward og reverse DNS. Dit .dk domain skal ganske rigtigt være på nogle servere DK Hostmaster kender, men rDNS (dvs. PTR-recorden for .in-addr.arpa) bør være på mdns3.hostwindsdns.com, hvis det er den, der er auth DNS for rDNS domænet (mailserverens IP adresse skrevet baglæns og med ".in-addr.arpa" bagefter). Er der nogen af Jer der har nogle løsninger? Behold dit .dk domain hvor det er og nøjes med at lade hostwinds stå for rDNS for IP adressen. -- Povl Ole
Fanget i DNS
Hej alle Hvordan løser I problemer med reverse DNS? Jeg har min debian mailserver på min fibia-internet-opkobling. De vil så have 49 kr/md for fast ip, hvilket jeg synes er uacceptabelt dyrt. (Og jeg tvivler på at de alligevel gider give mig reverse dns.) Jeg har derfor ikke reverse dns på min server, hvilket har givet problemer når jeg sender til gmail-konti. Jeg har bl.a. af denne grund prøvet at flytte min mailserver til en VPS, men det har vist ikke at være let så endda. Mange VPS-udbydere har enten lukket for port 25 eller for reverse dns, og når man beder om åbning, får man tågede svar om at det vil de måske nok hvis ... bla bla. (F.eks. Hetzner og Kamatera). Og det kan jeg jo ikke rigtig bruge til noget. (Jeg ved selvfølgelig godt at de prøver at beskytte sig mod spammere og andre skumle typer.) Så fandt jeg en liste over servere med åben port 25 (https://j-insights.com/list-of-vps-providers-with-port-25-open/). Og mit valg blev hostwinds.com. Og ganske rigtigt, der er åben port 25, og man kan opsætte PTR. MEN ... da jeg skulle skifte DNS server via dk-hostmaster, fik jeg beskeden: Navneserveren er ikke registreret hos DK Hostmaster Skal jeg nu til at gå alle 25 servere igennem for at finde ud af hvilke Dk-Hostmaster har registreret hvis overhovedet nogen af dem? Er der nogen af Jer der har nogle løsninger? Bedste hilsener Flemming PS: I et anfald af optimisme skrev jeg lige til dk-hostmaster: "Jeg har en VPS hos hostwinds.com. De har primær navnerserver: mdns3.hostwindsdns.com Men når jeg forsøger at skifte navneserver for rødblog.dk til at skifte til hostwinds ser, meddeler I: Navneserveren er ikke registreret hos DK Hostmaster. Kan der ikke blive lavet om på det selvom det er em amerikansk server? Problemet eksisterer ikke når der er tale om det tyske firma hetzner.com."
Re: Bug - remote DNS monitoring
> On Aug 30, 2022, at 1:12 PM, Casey Deccio wrote:
>
> I am having trouble tracking down a bug in my monitoring setup. It all
> happened when I upgraded the monitored host (host B in my example below) to
> bullseye. Note that Host A is also running bullseye, but the problem didn't
> show itself until Host B was upgraded.
With some help over at the bind-users mailing list [1], I discovered that
nrpe-ng closes stdin when launching the command [2], and the new version of
nslookup (invoked by check_dns) has issues when stdin is closed [3].
Redirecting stdin to /dev/null fixes the issue:
$ diff -u /usr/lib/python3/dist-packages/nrpe_ng/commands.py{.old,}
--- /usr/lib/python3/dist-packages/nrpe_ng/commands.py.old 2017-08-08
13:05:02.0 -0600
+++ /usr/lib/python3/dist-packages/nrpe_ng/commands.py 2022-09-13
17:00:36.767239885 -0600
@@ -85,6 +85,7 @@
proc = tornado.process.Subprocess(
run_args,
+stdin=subprocess.DEVNULL,
stdout=tornado.process.Subprocess.STREAM,
close_fds=True,
env=env)
I've filed a bug report [4].
Thanks,
Casey
[1] https://lists.isc.org/pipermail/bind-users/2022-September/10.html
[2] https://github.com/bootc/nrpe-ng/blob/master/nrpe_ng/commands.py#L86
[3] https://github.com/libuv/libuv/blob/v1.x/src/unix/core.c#L602
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019718
Re: Bug - remote DNS monitoring
> On Aug 30, 2022, at 1:40 PM, Nicholas Geovanis wrote: > > When you run check_dns by hand on Host B, you don't say who you are logged-in > as. That can make a difference. Nagios runs its scripts in a known > environment which may be different than you expect. > Thanks for the question. I have run the check_dns script with: - an arbitrary, unprivileged user - the nagios user (also unprivileged) - root (gasp!) They all work just fine. Also, in every case, I run tcpdump, and I can see the DNS queries and responses going back and forth just fine. In the strace messages, I can also see that the DNS messages were written and read properly. I think the issue is in nslookup, some time *after* the send/recv. But I can't narrow it down much more than that. Casey
Re: Bug - remote DNS monitoring
On Tue, Aug 30, 2022, 2:13 PM Casey Deccio wrote: > Hi all, > > I am having trouble tracking down a bug in my monitoring setup. It all > happened when I upgraded the monitored host (host B in my example below) to > bullseye. Note that Host A is also running bullseye, but the problem > didn't show itself until Host B was upgraded. > > Here is the setup: > > Host A (monitoring): > Installed: nagios4, nrpe-ng > IP address: 192.0.2.1 > > Host B (monitored): > Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils > IP address: 192.0.2.2 > > Host C (monitored through host B): > Installed: bind9 > IP address: 192.0.2.3 > Configured to answer authoritatively for example.com on port 53. > > nrpe > over HTTPs DNS > Host A --> Host B -> Host C > When you run check_dns by hand on Host B, you don't say who you are logged-in as. That can make a difference. Nagios runs its scripts in a known environment which may be different than you expect. On Host B, I run the following: > sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config > /etc/nagios/nrpe-ng.cfg > > While that is running, I run the following on Host A: > /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a > example.com 192.0.2.3 0.1 1.0 > > The result of running the command on Host A is: > DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address > > On Host B, I see the following debug output: > 200 POST /v1/check/check_dns (192.0.2.1) 78.05ms > Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 > -A -w 0.1 -c 1.0 > > When I run this exact command on Host B, I get: > $ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 > -c 1.0 > DNS OK: 0.070 seconds response time. example.com returns > 192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00 > > Looks good! When I run nslookup (run by check_dns), it looks good too: > $ /usr/bin/nslookup -sil example.com 192.0.2.3 > Server: 192.0.2.3 > Address: 192.0.2.3#53 > > Name: example.com > Address: 192.0.2.10 > Name: example.com > Address: 2001:db8::10 > > After rerunning nrpe-ng with strace -f, I see something: > > [pid 1183842] write(2, "nslookup: ./src/unix/core.c:570:"..., 83) = 83 > ... > [pid 1183841] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83 > > So it appears that the nslookup process is reporting an error. But I > cannot reproduce it outside of nrpe-ng. > > Any suggestions? > > Casey >
Bug - remote DNS monitoring
Hi all, I am having trouble tracking down a bug in my monitoring setup. It all happened when I upgraded the monitored host (host B in my example below) to bullseye. Note that Host A is also running bullseye, but the problem didn't show itself until Host B was upgraded. Here is the setup: Host A (monitoring): Installed: nagios4, nrpe-ng IP address: 192.0.2.1 Host B (monitored): Installed: nrpe-ng, monitoring-plugins-standard, bind9-dnsutils IP address: 192.0.2.2 Host C (monitored through host B): Installed: bind9 IP address: 192.0.2.3 Configured to answer authoritatively for example.com on port 53. nrpe over HTTPs DNS Host A --> Host B -> Host C On Host B, I run the following: sudo /usr/bin/python3 /usr/sbin/nrpe-ng --debug -f --config /etc/nagios/nrpe-ng.cfg While that is running, I run the following on Host A: /usr/lib/nagios/plugins/check_nrpe_ng -H 192.0.2.2 -c check_dns -a example.com 192.0.2.3 0.1 1.0 The result of running the command on Host A is: DNS CRITICAL - '/usr/bin/nslookup -sil' msg parsing exited with no address On Host B, I see the following debug output: 200 POST /v1/check/check_dns (192.0.2.1) 78.05ms Executing: /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 -c 1.0 When I run this exact command on Host B, I get: $ /usr/lib/nagios/plugins/check_dns -H example.com -s 192.0.2.3 -A -w 0.1 -c 1.0 DNS OK: 0.070 seconds response time. example.com returns 192.0.2.10,2001:db8::10|time=0.069825s;0.10;1.00;0.00 Looks good! When I run nslookup (run by check_dns), it looks good too: $ /usr/bin/nslookup -sil example.com 192.0.2.3 Server: 192.0.2.3 Address:192.0.2.3#53 Name: example.com Address: 192.0.2.10 Name: example.com Address: 2001:db8::10 After rerunning nrpe-ng with strace -f, I see something: [pid 1183842] write(2, "nslookup: ./src/unix/core.c:570:"..., 83) = 83 ... [pid 1183841] read(4, "nslookup: ./src/unix/core.c:570:"..., 4096) = 83 So it appears that the nslookup process is reporting an error. But I cannot reproduce it outside of nrpe-ng. Any suggestions? Casey
Re: verouderde instellingen exim en spamhaus? + DNS ??
Hoi Geert en anderen, Op 28-08-2022 om 12:51 schreef Geert Stappers: On Sun, Aug 28, 2022 at 09:44:09AM +0200, Gijs Hillenius wrote: Ik zit nu naar Unbound te kijken. Dat lijkt minder complex? Is dit *echt* alles ? https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html Mij ontgaat hoe een eigen tussenschakel kan helpen bij het probleem van een twijfelachtige CHECK_RCPT_IP_DNSBLS configuratie. Er is wat veranderd bij Spamhaus, lees dat artikel maar eens. Een oplossing is om een eigen DNS server te gebruiken, daarmee had ik succes. Maar wellicht kun je ook gewoon een andere DNS server gebruiken, b.v. die van Google, of die van je ISP. Maar Cloudflare gebruiken is dus geen goed idee. Groeten, Paul Groeten Geert Stappers P.S. Iets wat ik wel geinig vind: | $ dig +short 42km-mi.unit @dns.toys | "42.00 Kilometer (km) = 26.10 Mile (mi)" -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Re: verouderde instellingen exim en spamhaus? + DNS ??
Ha Geert Ik, tien dagen terug: >> >> Mijn exim4.conf.templat bevat >> >> .ifndef CHECK_RCPT_IP_DNSBLS >> >> CHECK_RCPT_IP_DNSBLS = \ >> >> cbl.abuseat.org : \ >> >> virbl.dnsbl.bit.nl : \ >> >> zen.spamhaus.org >> >> .endif mijn posts op de lijst (hieronder) gaan niet meer over wat hierboven staat. [...] te grote knip > Mij ontgaat hoe een eigen tussenschakel kan helpen > bij het probleem van > een twijfelachtige CHECK_RCPT_IP_DNSBLS configuratie. Klopt. Ik ben nu bezig met die spamassassin dqs. Ik maak ergens morgen (of de dag erna) een nieuwe post.
Re: verouderde instellingen exim en spamhaus? + DNS ??
On Sun, Aug 28, 2022 at 09:44:09AM +0200, Gijs Hillenius wrote: > On 27 August 2022 20:43 Paul van der Vlis, wrote: > > Op 18-08-2022 om 12:20 schreef Gijs Hillenius: > >> Mijn exim4.conf.templat bevat > >> .ifndef CHECK_RCPT_IP_DNSBLS > >> CHECK_RCPT_IP_DNSBLS = \ > >> cbl.abuseat.org : \ > >> virbl.dnsbl.bit.nl : \ > >> zen.spamhaus.org > >> .endif > >> maar .. ik krijg het idee dat deze regels achterhaald zijn. > >> die eerste (cbl) is blijkbaar al een paar jaar terug vervangen door > >> xbl.spamhaus.org, lees ik nu net op https://www.abuseat.org/cutover.html > >> Zou dit verklaren waarom ik de laatste tijd meldingen krijg over > >> bounces van bendel.debian.org en van lists.gnu.org? > >> voorbeeld: > >> 2022-08-18 12:10:01 H=lists.gnu.org [209.51.188.17] > >> X=TLS1.2:ECDHE_SECP256R1__RSA_SHA256__AES_256_GCM:256 CV=no > >> F= rejected RCPT > >> : 209.51.188.17 is listed at cbl.abuseat.org > >> (127.255.255.254: Error: open resolver; > >> https://www.spamhaus.org/returnc/pub/2400:cb00:71:1024::a29e:52ca) > > > > Je gebruikt wellicht de verkeerde DNS, let op dat "open resolver": > > > > https://www.spamhaus.com/resource-center/if-you-query-spamhaus-projects-dnsbls-via-cloudflares-dns-move-to-the-free-data-query-service/ > > > > Jij gebruikt blijkbaar Exim, dat ken ik niet zo goed. > > Toen ik begon met Debian was dat de default. Het is maar een mini > servertje, voor een handvol actieve mail-ontvangers/verzenders. > > > Ik gebruik Postfix, belangrijk daarbij is dat je na wijzigen DNS > > Postfix echt uitzet en weer opnieuw start, anders gebruikt het nog de > > oude DNS. > > > > Ik had hier ook problemen mee bij een klant, toen ben ik eigen DNS > > gaan draaien daar. > > Dank! En daar (ik moet aan de DNS) lijkt het op! > > Enkele jaren terug deed ik al eens een echt poging met Bind; en dat > samen met iemand die er best verstand van heeft. Dat lukte ons toen in > een paar uur worstelen toch niet. > > Ik zit nu naar Unbound te kijken. Dat lijkt minder complex? Is dit > *echt* alles ? > > https://unbound.docs.nlnetlabs.nl/en/latest/getting-started/configuration.html > Mij ontgaat hoe een eigen tussenschakel kan helpen bij het probleem van een twijfelachtige CHECK_RCPT_IP_DNSBLS configuratie. Groeten Geert Stappers P.S. Iets wat ik wel geinig vind: | $ dig +short 42km-mi.unit @dns.toys | "42.00 Kilometer (km) = 26.10 Mile (mi)" | $ -- Silence is hard to parse
Re: Needless DNS queries
Thanks to everybody, who replied. After some more reading and tinkering I've made the following observations: The response code NXDOMAIN means: domain name did not resolve. In this case the search option becomes important. Whenever a domain name does not resolve, the client's resolver (at least in Linux) suffixes the original domain name with each item in the search list until the new domain name resolves. So this is regular behaviour and it explains the needless DNS queries. AdguardHome uses the response code NXDOMAIN to signal the client "this is a forbidden domain". For this signal "this is a forbidden domain" you can configure AdguardHome to use the IPv4 0.0.0.0 and the response code NOERROR. Now the (forbidden) domain is resolved without an error and the IPv4 of 0.0.0.0. So there's no need to use the search list and the needless DNS queries vanish. Thanks for reading and have a nice day. Dieter
Re: Needless DNS queries
On 6/8/22, Greg Wooledge wrote: > On Wed, Jun 08, 2022 at 12:56:52AM +, Lee wrote: >> host and dig are non-standard. or use non-standard name lookups? >> library?? >> In any case, try your example with ping or ssh - the search list will >> be applied after the initial NXDOMAIN > > On Debian, the canonical tool for performing generic hostname lookups > according to the rules established by /etc/nsswitch.conf and other > local system config files would be: > > getent hosts NAME > > unicorn:~$ getent hosts www.google.com. > 2607:f8b0:4009:80b::2004 www.google.com > unicorn:~$ host www.google.com > www.google.com has address 142.250.190.100 > www.google.com has IPv6 address 2607:f8b0:4009:80b::2004 > > (Demonstrating the difference between canonical and useful. My system > has no IPv6 capability.) I'm in the same boat :( Verizon _still_ hasn't rolled out IPv6 in my area. I like having DNSSEC enabled, so I'm running bind locally; here's the bits from the bind log (with an 'rndc flush' between queries to clear out any cached info) $ getent hosts www.google.com query: www.google.com IN + (127.0.0.1) $ ping www.google.com query: www.google.com IN A + (127.0.0.1) query: www.google.com IN + (127.0.0.1) $ host www.google.com query: www.google.com IN A + (127.0.0.1) query: www.google.com IN + (127.0.0.1) query: www.google.com IN MX + (127.0.0.1) Why getent doesn't look for an IPv4 address I don't know. Same for host .. no idea why it goes looking for an MX record. Ping, ssh, telnet all look for an IPv4 and an IPv6 address. hrmm... Firefox only looks for an ipv4 address ... ah! right - because I've got network.dns.disableIPv6 set to true I was under the impression there was a standard method for doing the name -> address lookup but it seems that host, dig and even getent do something non-standard - maybe to give you more control for debugging purposes? Lee
