Re: A good name for development branch releases package
Hi Petr, Le 11/30/21 16:09, Petr Menšík a écrit : Is there any distribution offering already two releases at the same time? Would you have some idea, how should it be called? Do you like "bind9-dev" base name? For example, FreeBSD provides 3 bind releases : - dns/bind-devel - dns/bind911 - dns/bind916 HTH Xavier -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: CNAME for google sites
Hello Elias, This is not a CNAME, but rather a redirection at the web server (Apache or Nginx) level Cheers, Xavier Le 10/25/21 15:40, Elias Pereira a écrit : Hi, Google sites use a domain in the following way for their free sites. https://sites.google.com/company.com/mysite/ How can I create a CNAME for a site in this format? Is there another way? -- Elias Pereira -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Any interest in a write-up showing how to configure BIND 9.17x with DoH and LetsEncrypt?
On 30/05/2021 17:24, Richard T.A. Neal wrote: DNS over HTTPS support appears to be steadily increasing and it looks like the next version of Windows 10, Windows 10 21H2, will including support for DoH at the operating system level. � I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 21.04 and configuring the system as a recursive resolver offering DNS over HTTPS using a LetsEncrypt certificate. � Is there any interest in me writing this up as a web article, or has everyone who’s interested in DoH already got it running comfortably in their test environment? � Best. � Richard. Oh yes, please do ! Xavier -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[UNSOLVED] Re: Strange DNS behaviour
On 09/05/2021 13:44, Xavier Humbert via bind-users wrote: On 09/05/2021 12:32, Xavier Humbert via bind-users wrote: Hi, My DNS system if perfectly working : [xavier@numenor ~]$ dig dns.google.com ; <<>> DiG 9.16.15 <<>> dns.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 7b606d7c32a9990601006097b6d7f61894ea0a92dac2 (good) ;; QUESTION SECTION: ;dns.google.com. IN A ;; ANSWER SECTION: dns.google.com. 880 IN A 8.8.4.4 dns.google.com. 880 IN A 8.8.8.8 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 09 12:17:59 CEST 2021 ;; MSG SIZE rcvd: 103 On other hosts in my home, it works, too. But on one machine, it fails : [xavier@feanor ~]$ dig @numenor dns.google.com +trace ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace ; (1 server found) ;; global options: +cmd . 518400 IN NS m.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN RRSIG NS 8 0 518400 2021052117 2021050816 14631 . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev SroSeV9yXDURHqt8af+25bw 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw== couldn't get address for 'm.root-servers.net': not found None of the root servers can't be found. My root hint file is up to date. The network configuration on this machine : [xavier@feanor ~]$ nmcli device show enp10s0 GENERAL.DEVICE: enp10s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 04:7D:7B:02:68:67 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: Wired GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/3 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 192.168.100.25/24 IP4.GATEWAY: 192.168.100.254 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.100.254, mt = 100 IP4.ROUTE[2]: dst = 192.168.100.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[3]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.100.144 IP4.DNS[2]: 192.168.100.254 This is not an ACL problem, the whole subnet is allowed. Nmap and/or telnet shows no blocked port problem Trying on the secondary leads to the same behaviour Eventually, I am lost. Sorry, typed too quickly. Problem stands. -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[SOLVED] Re: Strange DNS behaviour
On 09/05/2021 12:32, Xavier Humbert via bind-users wrote: Hi, My DNS system if perfectly working : [xavier@numenor ~]$ dig dns.google.com ; <<>> DiG 9.16.15 <<>> dns.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 7b606d7c32a9990601006097b6d7f61894ea0a92dac2 (good) ;; QUESTION SECTION: ;dns.google.com. IN A ;; ANSWER SECTION: dns.google.com. 880 IN A 8.8.4.4 dns.google.com. 880 IN A 8.8.8.8 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 09 12:17:59 CEST 2021 ;; MSG SIZE rcvd: 103 On other hosts in my home, it works, too. But on one machine, it fails : [xavier@feanor ~]$ dig @numenor dns.google.com +trace ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace ; (1 server found) ;; global options: +cmd . 518400 IN NS m.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN RRSIG NS 8 0 518400 2021052117 2021050816 14631 . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev SroSeV9yXDURHqt8af+25bw 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw== couldn't get address for 'm.root-servers.net': not found None of the root servers can't be found. My root hint file is up to date. The network configuration on this machine : [xavier@feanor ~]$ nmcli device show enp10s0 GENERAL.DEVICE: enp10s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 04:7D:7B:02:68:67 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: Wired GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/3 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 192.168.100.25/24 IP4.GATEWAY: 192.168.100.254 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.100.254, mt = 100 IP4.ROUTE[2]: dst = 192.168.100.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[3]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.100.144 IP4.DNS[2]: 192.168.100.254 This is not an ACL problem, the whole subnet is allowed. Nmap and/or telnet shows no blocked port problem Trying on the secondary leads to the same behaviour Eventually, I am lost. Sorry for the disturbance, it was caused by faulty remnants of a VPN connection. I fixed that in /etc/systemd/resolved.conf Cheers -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Strange DNS behaviour
Hi, My DNS system if perfectly working : [xavier@numenor ~]$ dig dns.google.com ; <<>> DiG 9.16.15 <<>> dns.google.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12276 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 7b606d7c32a9990601006097b6d7f61894ea0a92dac2 (good) ;; QUESTION SECTION: ;dns.google.com. IN A ;; ANSWER SECTION: dns.google.com. 880 IN A 8.8.4.4 dns.google.com. 880 IN A 8.8.8.8 ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Sun May 09 12:17:59 CEST 2021 ;; MSG SIZE rcvd: 103 On other hosts in my home, it works, too. But on one machine, it fails : [xavier@feanor ~]$ dig @numenor dns.google.com +trace ; <<>> DiG 9.16.8-Ubuntu <<>> @numenor dns.google.com +trace ; (1 server found) ;; global options: +cmd . 518400 IN NS m.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN RRSIG NS 8 0 518400 2021052117 2021050816 14631 . IgUiqHrRXT5hTAa5wnubyCL0T9iq+iRAQIUQlIStRYqZh6Qp5W3sZLum 6O+EkYZALJda6RJwQY8oPEgQVQymGmGyAxcZBekX5vsMm8MgovQIA+Ev SroSeV9yXDURHqt8af+25bw 6YyUQEOblPehxyUYYkF9cP8FlieAUw1Fn HMvqpQlEn2sYS4UjA+euhcS2k7jnyEdBNbXbEZVq56zHK1aHPQIp2f4/ byHaC55zPJ5rgLwMUh+8JuP47wb4NWAKIj76EUlqcidfI8hxZI5KPoNZ vmIcEtQSfRYqVxoc+BiEEgalw5afAmXjEtvJaWm4v5383uatiQ1s9AgC MPQFHw== couldn't get address for 'm.root-servers.net': not found None of the root servers can't be found. My root hint file is up to date. The network configuration on this machine : [xavier@feanor ~]$ nmcli device show enp10s0 GENERAL.DEVICE: enp10s0 GENERAL.TYPE: ethernet GENERAL.HWADDR: 04:7D:7B:02:68:67 GENERAL.MTU: 1500 GENERAL.STATE: 100 (connected) GENERAL.CONNECTION: Wired GENERAL.CON-PATH: /org/freedesktop/NetworkManager/ActiveConnection/3 WIRED-PROPERTIES.CARRIER: on IP4.ADDRESS[1]: 192.168.100.25/24 IP4.GATEWAY: 192.168.100.254 IP4.ROUTE[1]: dst = 0.0.0.0/0, nh = 192.168.100.254, mt = 100 IP4.ROUTE[2]: dst = 192.168.100.0/24, nh = 0.0.0.0, mt = 100 IP4.ROUTE[3]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 IP4.DNS[1]: 192.168.100.144 IP4.DNS[2]: 192.168.100.254 This is not an ACL problem, the whole subnet is allowed. Nmap and/or telnet shows no blocked port problem Trying on the secondary leads to the same behaviour Eventually, I am lost. Could anyone help ? Thanks, Regards -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 OpenPGP_0x90B78A89BCC49C10.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dev] Change in the build system - please test
ed in the next major release (e.g. BIND 9.18). > However > because this is a big change, I would like to invite people interested in the > BIND 9 > development to actively go and try it. > > All you need to do is: > > git clone --depth=1 https://gitlab.isc.org/isc-projects/bind9.git > cd bind9 > autoreconf -fi > ./configure && make && make install # as usual > > Few things needs to be said: > > * You should read the main commit description: > https://gitlab.isc.org/isc-projects/bind9/-/commit/978c7b2e89aa37a7ddfe2f6b6ba12ce73dd04528 > > * You should look at the list of linked issues to the main (#4) issue which > contains list of not-yet-done work: > https://gitlab.isc.org/isc-projects/bind9/-/issues/4 > > If there’s an issue you found and it’s small, try to look at the list of > existing issues and add it if it fits, or > just add a comment on the issue #4. If the problem is reasonable big and > contained, feel free to open > new issue for it (and probably link it in the comment in issue #4). > > Thank you, > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem with zone delegation with private gTLD
On 08/04/2019 13:05, Matus UHLAR - fantomas wrote: > I believe there should be reserved gTLD for such usage. Is this not what the TLD /.invalid/ is supposed to be ? Xavier -- Xavier Humbert CRT Supervision et Exploitation de Niveau 1 Rectorat de Nancy-Metz 03 83 86 27 39 signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind master keeps saying it is not authoritative
The whole configuration, comments removed :
-- Master --
acl my-slaves {
any;// DEBUG
};
acl my-clients {
any;// DEBUG
};
options {
// IP config
listen-on port 53 {172.29.16.135; 127.0.0.1; };
listen-on-v6 port 53 {none; };
// Paths
directory"/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Behaviour
recursion no;
allow-transfer{ my-slaves; };
};
// rndc key
include "/etc/rndc.key";
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
// Logging
// omitted
zone "in.acv.orion.education.fr" {
type master;
file "/etc/named/internal/in.acv.orion.education.fr.db";
allow-transfer {my-slaves; };
};
-- Slave --
acl my-clients {
localhost;
any;//DEBUG
};
options {
// IP config
listen-on port 53 {172.29.16.133; 127.0.0.1; };
listen-on-v6 port 53 {none; };
// Paths
directory"/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
// Behaviour
recursion no;
allow-update{ 172.29.16.135; };
allow-transfer{ 172.29.16.135; };
};
// rndc key
include "/etc/rndc.key";
// Logging
// Omitted
zone "in.acv.orion.education.gouv.fr" {
type slave;
file "/etc/named/in.acv.orion.education.gouv.fr.db";
masters {172.29.16.135; };
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
--
Really, reall basic !
Thanks
--
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Bind master keeps saying it is not authoritative
Hello, I cannot fix a master/slave problem on RHEL7 with bind 9.9.4. It
is a server in building process, in a LAN, so I cannot use tools like
Zonecheck. Please note that my boss explicitely asked me to anonymize
the zone name. I know this is useless.
I can provide named.conf files for both servers, but basically, I
disabled (commented out) all security related options, and added "any"
to all acls. The zones declaration are double checked :
Master :
zone "myzone.fr" {
type master;
file "/etc/named/internal/myzone.fr";
allow-transfer {my-slaves; };
};
Slave :
zone "myzone.fr" {
type slave;
file "/etc/named/slave/myzone.fr.db";
masters {172.29.16.135; };
};
When I initiate a zone transfer manually it works :
[root@slave etc]# dig @master axfr myzone.fr
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> @master axfr myzone.fr
; (1 server found)
;; global options: +cmd
myzone.fr. 86400 IN SOA master.myzone.fr. dnsmaster.myzone.fr.
2017021602 28800 7200 604800 86400
...etc...
But, in normal operation (all zones loaded OK), when I look at the
master I got this :
xfer-out: info: client 172.29.16.133#57190 (myzone.fr): bad zone transfer
request: 'myzone.fr/IN': non-authoritative zone (NOTAUTH)
And on the slave :
general: info: zone myzone.fr/IN: refresh: unexpected rcode (REFUSED) from
master 172.29.16.135#53 (source 0.0.0.0#0)
general: info: zone myzone.fr/IN: Transfer started.
xfer-in: info: transfer of 'myzone.fr/IN' from 172.29.16.135#53: connected
using 172.29.16.133#53836
xfer-in: error: transfer of 'myzone.fr/IN' from 172.29.16.135#53: failed while
receiving responses: NOTAUTH
xfer-in: info: transfer of 'myzone.fr/IN' from 172.29.16.135#53: Transfer
completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)
I'm really lost. I've configured dozens of DNSs with no such problems.
Did I miss something obvious ?
Thanks in advance,
Xavier
--
Xavier Humbert
CRT Supervision et Exploitation de Niveau 1
Rectorat de Nancy-Metz
03 83 86 27 39
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
