Re: Referencing by cname from one authoritative zone to another authoritative zone
On 03.10.24 09:21, 大浦 義 wrote: ・9.9.4→OK # dig @ns1.bbb.co.jp time1.aaa.ne.jp ;; ANSWER SECTION: time1.aaa.ne.jp. 3600IN CNAME ns2.bbb.co.jp. ns2.bbb.co.jp. 900 IN A 1.2.3.5 ;; AUTHORITY SECTION: bbb.co.jp. 900 IN NS ns6-tk02.ccc.ad.jp. bbb.co.jp. 900 IN NS ns2.bbb.co.jp. bbb.co.jp. 900 IN NS ns1.bbb.co.jp. ;; ADDITIONAL SECTION: ns1.bbb.co.jp. 900 IN A 1.2.3.4 ・9.18.28→NG # dig @ns1-2024.bbb.co.jp time1.aaa.ne.jp ;; ANSWER SECTION: time1.aaa.ne.jp. 3600IN CNAME ns2.bbb.co.jp. Now do: dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp. what records does ns2.bbb.co.jp. have on ns1-2024.bbb.co.jp ? On 03.10.24 08:40, 大浦 義 wrote: Referencing by cname from one authoritative zone to another authoritative zone may not work properly depending on the version. Is this due to a specification change? Is there a way to handle this? I am running nslookup from a client that is not included in acl respectively. I would like to make the NG part become OK. -- One Server Has Two Zone. aaa.ne.jp & bbb.co.jp ・aaa.ne.jp time1 CNAME ns2.bbb.co.jp. time2 CNAME ns1.bbb.co.jp. ・bbb.co.jp ns1 A 1.2.3.4 ns2 A 1.2.3.5 timeCNAME ns2 ・Bind9.9.4→OK nslookup time2.aaa.ne.jp 名前:ns1.bbb.co.jp Address: 1.2.3.4 Aliases: time2.aaa.ne.jp ・Bind9.18.28→NG nslookup time2.aaa.ne.jp 名前:ns1.bbb.co.jp nslookup is NOT a good tool to resolve DNS problems. Use "dig" instead. dig time2.aaa.ne.jp @"IP of Bind9.9.4" dig time2.aaa.ne.jp @"IP of Bind9.18.28" -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse -- 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: Referencing by cname from one authoritative zone to another authoritative zone
On 03.10.24 08:40, 大浦 義 wrote: Referencing by cname from one authoritative zone to another authoritative zone may not work properly depending on the version. Is this due to a specification change? Is there a way to handle this? I am running nslookup from a client that is not included in acl respectively. I would like to make the NG part become OK. -- One Server Has Two Zone. aaa.ne.jp & bbb.co.jp ・aaa.ne.jp time1 CNAME ns2.bbb.co.jp. time2 CNAME ns1.bbb.co.jp. ・bbb.co.jp ns1 A 1.2.3.4 ns2 A 1.2.3.5 timeCNAME ns2 ・Bind9.9.4→OK nslookup time2.aaa.ne.jp 名前:ns1.bbb.co.jp Address: 1.2.3.4 Aliases: time2.aaa.ne.jp ・Bind9.18.28→NG nslookup time2.aaa.ne.jp 名前:ns1.bbb.co.jp nslookup is NOT a good tool to resolve DNS problems. Use "dig" instead. dig time2.aaa.ne.jp @"IP of Bind9.9.4" dig time2.aaa.ne.jp @"IP of Bind9.18.28" -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease -- 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: forwarding ".local" subdomains when "local" exist
On 16.08.24 19:55, Tim Maestas wrote:
You need to have the delegation in the parent in order for the forwarding
to kick in. It can be bogus, but it has to be there. You'll find the same
behavior when you're authoritative for the root zone; any type forwarded
zones will need to also have NS in the root ( or closest enclosing
authoritative zone).
Thanks, this worked.
I created ".local" zone (copied from db.empty) with dummy NS for
"example.local" and forwarding works, just as ".local" is resolved locally.
On Fri, Aug 16, 2024, 7:13 AM Matus UHLAR - fantomas
wrote:
our customer has private .local zone "example.local"
(I know this should be used for multicast...)
so I have configured forwarding queries for this domain to his servers:
zone "example.local" {
type forward;
forward only;
forwarders {
192.168.0.1;
};
};
zone "168.192.in-addr.arpa" {
type forward;
forward only;
forwarders {
192.168.0.1;
};
};
Since some queries for ".local" zone were leaking out of their network,
I have long ago locally configured empty zone "local":
zone "local" {
type master;
file "/etc/bind/db.empty";
};
Now, the resolution od "example.local" does not work, named returns
"nxdomain", doesn't forward the query.
when I commented out the "local" zone, named started working,
I just needed to add
validate-except { "local"; };
guess I understand why.
From the history I remember that defining zone (example.local) with no
delegation in the parent zone (local) does not cause issues (locally).
Is "type forward" special in this case?
Debian 12, BIND 1:9.18.28-1~deb12u2
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them
--
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
forwarding ".local" subdomains when "local" exist
Hello,
our customer has private .local zone "example.local"
(I know this should be used for multicast...)
so I have configured forwarding queries for this domain to his servers:
zone "example.local" {
type forward;
forward only;
forwarders {
192.168.0.1;
};
};
zone "168.192.in-addr.arpa" {
type forward;
forward only;
forwarders {
192.168.0.1;
};
};
Since some queries for ".local" zone were leaking out of their network,
I have long ago locally configured empty zone "local":
zone "local" {
type master;
file "/etc/bind/db.empty";
};
Now, the resolution od "example.local" does not work, named returns
"nxdomain", doesn't forward the query.
when I commented out the "local" zone, named started working,
I just needed to add
validate-except { "local"; };
guess I understand why.
From the history I remember that defining zone (example.local) with no
delegation in the parent zone (local) does not cause issues (locally).
Is "type forward" special in this case?
Debian 12, BIND 1:9.18.28-1~deb12u2
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Honk if you love peace and quiet.
--
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: qname minimisation per domain
On 15 Jul 2024, at 23:27, Matus UHLAR - fantomas wrote: I have noticed that especially DNS blocklist cause errors like: Jul 14 01:41:28 fantomas named[1854]: success resolving 'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain' and blocklists like spamhaus are sensitive to too many queries. is it possible to disable query minimisation for particular domains? On 16.07.24 09:23, Mark Andrews wrote: Is it really too much effort for the servers to return NOERROR instead of an incorrect NXDOMAIN for the intermediate names? That would get rid of the log message. These seem to run rbldnsd which is optimised for memory usage and speed of response, and returning different replies would I guess affect speed. It’s changing 1 bit (0 vs 4 for the rcode) in the DNS header. They don’t even have to lookup if there are names below the query. The server can just assume that there are records there and return NOERROR for [0..255].zen.spamhaus.org, [0..255].[0..255].zen.spamhaus.org and [0..255].[0..255].[0..255].zen.spamhaus.org. Really we would like to be able to move to strict QNAME minimisation so we don’t need to make all the other queries after the first NXDOMAIN response but broken implementations like this are making that difficult. It’s not like this is a new requirement. A NOERROR response goes back the RFC 1034. I see there's issue and merge containing exactly this change: https://github.com/spamhaus/rbldnsd/issues/17 The discussion also mentions things like There is also quite a lot of consensus in the SMTP World that qname minimization shouldn't be used on the resolvers used by mail servers and For the IP(v4 and v6) datasets, all of them, we could implement a hackish solution so that when a query for a "partial" ip address is received, rbldnsd doesn't reply NXDOMAIN but NOERROR instead. Additionally Spamhaus controls how often resolvers re-query. 10 seconds is a very short negative response TTL. If they don’t like the query rate they can control it by returning longer negative cache responses. Named does check in the cache for negative cache entries to determine whether or not to make the intermediate QNAME minimisation queries. Lower negative TTLs allow for faster listing detection. I also believe that it is in Spamhaus interest to have more paying clients (although this may not be the primary reason for short negative TTLs). I guess for now, since the qname minimization increases number of queries sent and resolving time, I should disable qname-minimization on all named instances used by mail server. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. -- 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
qname minimisation per domain
Hello, I have noticed that especially DNS blocklist cause errors like: Jul 14 01:41:28 fantomas named[1854]: success resolving 'D.C.B.A.zen.spamhaus.org/A' after disabling qname minimization due to 'ncache nxdomain' and blocklists like spamhaus are sensitive to too many queries. is it possible to disable query minimisation for particular domains? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Atheism is a non-prophet organization. -- 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: Problem with a certain domain
Am 2024-06-04 15:28, schrieb Greg Choules: Firstly, I doubt you actually need to kill and restart `named`. Flushing the cache would probably work, either all of it or just selected names. Secondly, take a packet capture of this happening and analyse what BIND is really doing, in Wireshark. - If it shows up that certain NS are causing the problem you can avoid them, in config. - If it's a DNSSEC issue, you can get around that on a per-domain basis, if needed. - If it turns out that qname minimization is the issue, you can play with settings for that, too. In short, there are plenty of tools in the kit bag. But understand what the problem is first and to do that, gather data (pcaps and logs) that can be used to paint a picture of what's really happening. On 04.06.24 19:17, Thomas Barth via bind-users wrote: The newsletter is only sent out once a day, so I would have to wait until tomorrow. I'll record it then. I have already experimented with tshark and recorded port 53. What I noticed as a network layman is that a certain response takes much longer on server 1 with the problems than on server 2. if the problem happens again, you can call 'rndc dumpdb' to dump named's cache and see all records your named remembers about mallorcazeitung.es and epi.es perhaps they can help to explain why named can't resolve anything. It's the message: No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is a part of the recording of server 1 with the problem, almost a delay of 2 seconds! (tshark -w dns-mx1-l5.pcap -i eth0 -f "src port 53") [...] 6 18:35:38,719369034 216.239.32.106 213.136.83.xxx DNS 141 Standard query response 0x69ac A ns3.prensaiberica.net A 34.175.122.60 OPT 7 18:35:40,333128992 34.175.122.60 213.136.83.xxx DNS 162 Standard query response 0xf393 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:35:40,370838540 194.69.254.1 213.136.83.xxx DNS 1219 Standard query response 0xaadc DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 9 18:35:40,402465454 34.175.171.102 213.136.83.xxx DNS 165 Standard query response 0x7bfa A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es Here is the part of the recording of server 2 (tshark -w dns-mx2-l5.pcap -i eth0 -f "src port 53") 5 18:32:03,019743724 213.4.119.2 167.86.126.xxx DNS 139 Standard query response 0x36bf A ns4.prensaiberica.net A 34.175.171.102 NS ns1.epi.es NS ns2.epi.es 6 18:32:03,052680383 194.69.254.1 167.86.126.xxx DNS 1219 Standard query response 0x5643 DS mallorcazeitung.es NSEC3 RRSIG SOA ns1.nic.es RRSIG NSEC3 RRSIG OPT 7 18:32:03,087003657 34.175.122.60 167.86.126.xxx DNS 162 Standard query response 0x3d78 No such name NS _domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es 8 18:32:03,120746561 34.175.171.102 167.86.126.xxx DNS 165 Standard query response 0x3a41 A s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es SOA ns1.epi.es I therefore suspect that the delay will be even greater tomorrow again when the newsletter arrives, so that the "communication error" will occur again. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? -- 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: Problem with a certain domain
On 03.06.24 18:46, Thomas Barth via bind-users wrote: I cannot send them an email to inform about a dns problem. The mail gets stuck in the queue. postqueue -p (Host or domain name not found. Name service error for name=mx.renr.es type=A: Host not found, try again) r...@mallorcazeitung.es Bind reports a communication error. dig mx.renr.es ;; communications error to 127.0.0.1#53: timed out I could enable the bind logging: 03-Jun-2024 18:34:22.681 client @0x7f014c88ed68 127.0.0.1#54496 (mallorcazeitung.es): query: mallorcazeitung.es IN MX +E(0)K (127.0.0.1) 03-Jun-2024 18:34:36.098 client @0x7f014ef48168 127.0.0.1#59706 (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) 03-Jun-2024 18:34:41.106 client @0x7f014dd71768 127.0.0.1#56423 (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1) Should I perhaps ask the mail user to unsubscribe from this website due to troubles of bad configuration? yeah I guess you should, their DNS servers are pretty much messed up: % dig ns epi.es @213.4.119.2 ; <<>> DiG 9.18.24-1-Debian <<>> ns epi.es @213.4.119.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42145 ;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;epi.es.IN NS ;; ANSWER SECTION: epi.es. 259200 IN NS ns3.epi.es. epi.es. 180 IN NS ns1.epi.es. epi.es. 300 IN NS ns1.epi.es. epi.es. 300 IN NS ns2.epi.es. epi.es. 3600IN NS ns2.epi.es. % dig ns1.epi.es @213.4.119.2 ; <<>> DiG 9.18.24-1-Debian <<>> ns1.epi.es @213.4.119.2 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57889 ;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 5, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.epi.es.IN A ;; ANSWER SECTION: ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ns1.epi.es. 300 IN A 213.0.95.2 ;; AUTHORITY SECTION: epi.es. 259200 IN NS ns3.epi.es. epi.es. 180 IN NS ns1.epi.es. epi.es. 300 IN NS ns1.epi.es. epi.es. 300 IN NS ns2.epi.es. epi.es. 3600IN NS ns2.epi.es. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: "Let God Debug It!". -- 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 and IPv6
On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote: rinetd manages 2 separate connections and should work with PMTUD. On 28.05.24 22:17, Peter wrote: I'm wondering how it would. The connections are TCP, the PMTU works via ICMP6. No, Path MTU discovery works with TCPv4 using ICMPv4 as well. (although it was/is quite common to block ICMP packets which can make it not work properly) So I would assume, the ICMP "packet too big" message reaches the host where rinetd runs, is swallowed by the kernel, and the kernel sets the MTU in it's hostcache. Or something along that line. The TCP traffic however gets forwarded by rinetd to the internal appserver(s) - which never get the message that they should reduce their MTU. The data from one TCP connection are sent through another TCP connection, where both connections are separate with separate MTU and PMTUD. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody -- 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: queries for "_.domain"
On 18.05.24 07:10, Mark Andrews wrote: Correct. Later versions use NS queries as that allows named to cache the non-existence of the NS RRset. I see this happened since 9.18.17 Luckily Debian 11/backports and Debian 12 have incorporated this version. Using _.domain doesn’t allow that to happen. Which I guess caused my problem. Looking at the docs, I can only turn it off in previous versions. (QNAME minimization was added in 9.13.2) NS queries do however expose broken delegations. Make sure you have working NS records at the zone apex and at the delegation point. This is especially important when the server serves multiple levels in the zone hierarchy as intermediate delegations are often not seen without QNAME minimisation but are with QNAME minimisation. Luckily this is resolving-only server. We have had bug reports due to all delegating NS records referring to non-existing servers. We have had bug reports due to garbage records at the zone apex. I encountered problems like this in the past. And then people wonder they DNS work properly. The "google (8.8.8.8) works" argument is problematic because google violates DNS in cases like this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet. -- 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
queries for "_.domain"
Hello, I have noticed that BIND sends strange (for me) queries. 5 0.198221 192.168.0.1 → 193.108.88.128 DNS 105 Standard query 0x15a4 A _.net.akadns.net OPT 8 0.204738 193.108.88.128 → 192.168.0.1 DNS 159 Standard query response 0x15a4 No such name A _.net.akadns.net SOA internal.akadns.net OPT 9 0.205400 192.168.0.1 → 193.108.88.128 DNS 112 Standard query 0x3413 A _.office.net.akadns.net OPT 10 0.211944 193.108.88.128 → 192.168.0.1 DNS 166 Standard query response 0x3413 No such name A _.office.net.akadns.net SOA internal.akadns.net OPT 11 0.212646 192.168.0.1 → 193.108.88.128 DNS 128 Standard query 0x70df A _.omexexternallfb.office.net.akadns.net OPT 12 0.218782 193.108.88.128 → 192.168.0.1 DNS 182 Standard query response 0x70df No such name A _.omexexternallfb.office.net.akadns.net SOA internal.akadns.net OPT Is this a known feature I have missed? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The early bird may get the worm, but the second mouse gets the cheese. -- 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: SRV on multiple subdomains
On 14.05.24 14:20, DEMBLANS Mathieu wrote: A part of the subdomains are managed by us, others subdomains by an other entity. If you really have multiple subdomains for exanmle.com managed by different entities, then yes, wildcard is not good idea. This applies to A and MX records as well. So we can't configure a generic target for all subdomains as each entity has its own target for SRV entries. You can't even setup wildcard for *.example.com to provide server1.example.com A/MX record, because the _imap._tcp.server1.example.com would make the wildcard invalid for server1.example.com. Simply, wildcarding is not for case like this. -Message d'origine- De : bind-users De la part de Matus UHLAR - fantomas Envoyé : mardi 14 mai 2024 15:58 À : bind-users@lists.isc.org Objet : Re: SRV on multiple subdomains On 14.05.24 13:08, DEMBLANS Mathieu wrote: I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general domain definitions with wildcard but is there a way to do so for SRV without having to define all subdomains (we have several dizains of it) ? We have to define some SRV entries with the same target like : _imap._tcp.server1.example.com IN SRV main.exemple.com _imap._tcp.server2.example.com IN SRV main.exemple.com I assume that _imap._tcp should be configurable per domain, so there should not be needed any need for things like _imap._tcp.server1.example.com - you should use _imap._tcp.example.com For example something like _imap._tcp.*.example.com IN SRV main.example.com. I read in a doc that the < * > can only be the leftmost label in the name. correct. Is there an other way to simplify or does I have to add each entry individually? no, but the question is if you really need this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself. -- 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: SRV on multiple subdomains
On 14.05.24 13:08, DEMBLANS Mathieu wrote: I have a question about configuration simplification for SRV configuration (maybe it can be applyed for other entries). We manage multiple subdomain of a main one (server1.example.com, server2.example.com,...). For A and MX entries, we use a general domain definitions with wildcard but is there a way to do so for SRV without having to define all subdomains (we have several dizains of it) ? We have to define some SRV entries with the same target like : _imap._tcp.server1.example.com IN SRV main.exemple.com _imap._tcp.server2.example.com IN SRV main.exemple.com I assume that _imap._tcp should be configurable per domain, so there should not be needed any need for things like _imap._tcp.server1.example.com - you should use _imap._tcp.example.com For example something like _imap._tcp.*.example.com IN SRV main.example.com. I read in a doc that the < * > can only be the leftmost label in the name. correct. Is there an other way to simplify or does I have to add each entry individually? no, but the question is if you really need this. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. -- 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: transfert master slave
On 25.03.24 11:34, sami.ra...@sofrecom.com wrote:
I'm trying to configure a DNS slave server (192.168.56.157) . I want to
allow notifications only from the master (192.168.56.154). I added the
directive "allow-notify {192.168.56.154;};" and it works. However, when I
try to test the prohibition of notification by adding "allow-notify
{none;};" at the slave, it still receives updates from the master. The
transfer on the master is as follows:
allow-notify will not stop the master to send notifies. They will just
be ignored.
allow-transfer {192.168.56.157;};
also-notify {192.168.56.157;};
notify explicit;"
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"One World. One Web. One Program." - Microsoft promotional advertisement
"Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler
--
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: occasional SERVFAIL error
On 29.02.24 15:20, Ludovit Koren wrote: occasionally I get the following SERVFAIL error: dig www.jiscd.sk ; <<>> DiG 9.18.24 <<>> www.jiscd.sk ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good) ;; QUESTION SECTION: ;www.jiscd.sk. IN A ;; Query time: 17 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) ;; WHEN: Wed Feb 28 14:27:16 CET 2024 ;; MSG SIZE rcvd: 69 I can get rid of it only after issuing: rndc flush Afterwards it works for uncertain time. Could it be I have a configuration problem of my server (I have prefetch 0 set in options section of my server)? Is it a problem of the authorized domain server? I have looked onto it manually, so far found nothing. rndc dumpdb could generate named output where you should be able to find out the culprit. the difference between current version of zone between ns1.gov.sk and ns2.gov.sk could affectg this problem. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question! -- 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: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01.03.24 08:24, Ondřej Surý wrote: The "sortlist" option allows to define a complicated rules when and how to reorder the resource records in the responses. The same caveats as with the "rrset-order" apply - relying on any specific order of resource records in the DNS responses is wrong. We are not aware of any other (major) DNS server that would have similar behaviour as this was never specified in the DNS protocol. If you know of any software or hardware relying on any specific order of the resource records in the DNS messages, it needs to be reported as a bug to the respective vendor. I don't know about _requirement_, but I have used this option as poor man's way to implement geographically local IP addresses - to anyone return topologically closer IP addresses first, others next. I found it especially nice because it doesn't matter which service are we using - if there are multiple IP's for _anything_, return topologically closer first. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- 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: error: 'allow-update' is not allowed in 'slave' zone
On 14.02.24 17:06, trgapp16 via bind-users wrote:
I configured Bind 9.18.12 as slave DDNS with dynamic updates from DHCP (ISC
DHCP 4.4)
running on the same server (Ubuntu 22.04 server)
When I run "named-checkconf named.conf", I get the following error
"named.conf:2018: option 'allow-update' is not allowed in 'slave' zone
'zonename.com'"
Following is the named.conf file (part)
zone "zonename.com" {
type slave;
file "com/zonename/sec.zonename.com";
masters {
IP address;
};
allow-update {
key rndc-key;
};
allow-transfer {
IP address;
};
};
I am clueless what is going wrong. Any help is greatly appreciated
your nameserver does not update secondary(slave) zones, therefore
allow-update does not make sense.
you should remove it or replace with allow-update-forwarding so all received
updates are forwarded to primary(master) server.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux is like a teepee: no Windows, no Gates and an apache inside...
--
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: Question on ISC BIND DNS Server
On 22.11.23 23:44, Turritopsis Dohrnii Teo En Ming wrote: I have Virtualmin / Webmin web hosting server control panel. I have 2 Virtual Private Servers in Germany and 1 Virtual Private Server in Japan. Can I upgrade BIND DNS Server manually? Will it cause problems with Virtualmin / Webmin? I think this is question for webmin/virtualmin, but from what I know about webmin it tends to edit local configuration, so I guess it will edit primary zone file. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Posli tento mail 100 svojim znamim - nech vidia aky si idiot Send this email to 100 your friends - let them see what an idiot you are -- 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: Forwarders working differently on bind9.8 & bind9.11
On Tue, Sep 19, 2023 at 7:28 AM Prashasti Arora
wrote:
I have configured a new zone to forward certain queries to my application
on 2 VMs (One local and the other in my network) through a specific port. I
have 2 similar setups - they are identical, except that one uses bind9.8
and the other uses bind9.11. Configuration is also identical for both.
On the first setup (using bind9.8): the traffic I send gets distributed
uniformly.
On the second setup (using bind9.11): the traffic gets distributed barely.
99% of the traffic is sent to one VM.
BIND wants to get responses as soon as possible, thus it queries servers who
respond fastest.
BIND keeps track of how fast servers are responding, and which server
responds faster, will get queries more often.
Time to time, BIND re-checks other servers to see if they perform better,
because that can change over time.
What is the problem?
I have verified that forwarding is working correctly on both, the issue is
not with the application because both VMs on each setup can handle traffic
individually, the firewall is not blocking the queries, and the
configuration is correct.
This is the zone:
zone "example.com" IN {
type forward;
forwarders { 127.0.0.1 port xxx; a.b.c.d port xxx; };
forward only;
};
Please share any other possible solutions.
On 19.09.23 08:25, Bob Harold wrote:
Note that the 'forwarders' line, from the BIND 9.11 manual: "There may be
one or more forwarders, and they are queried in turn until the list is
exhausted
or an answer is found." So the first one will get all the traffic, the
second is just a backup to be used if the first fails.
If you expect that to do load balancing, it will not. Try a real load
balancer, or 'dnsdist'.
I think this behaviour changed to the one I described above a long time ago.
Perhaps after BIND 9.8
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Support bacteria - they're the only culture some people have.
--
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: Dynamic updates to multiple masters
On 02.08.23 11:53, Shailendra Gautam wrote: I have four authoritative dns servers, all running in master mode for my zone for high availability, currently they all pull a static zonefile. I'm trying to implement dynamic updates but I am wondering if there is any way to avoid sending an update to each of them, and send the update only once and it should sync to all 4. Would like to know if anyone has faced this problem before. Microsoft's AD supports something like this, the domains are kind of synchronized between servers. As a downside, when using AD server as primary for zones in AD, you can't use multiple servers as the zones are often not in sync. I would either create hidden primary that would process dynamic updates. For DNSSEC and inline signing, hidden primary looks as best option to me. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. On the other hand, you have different fingers. -- 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: Bind to Bind DNS Lookup - Returns wildcard value for defined A record
On 16.07.23 02:08, OwN-3m-All wrote: I've got a bind recursion DNS server setup that is returning the wrong value for an outside domain that I also maintain and host on another server running a bind DNS server. Yet Google's DNS and other major DNS providers respond with the correct IP address A record when querying. I can't figure out why my recursion enabled instance is not returning the correct IP address for a specific host. Rather, it returns the wildcard value from the zonefile rather than the specifically specified A record entry created for that host. It appears bind to bind is returning the wildcard value for a specifically defined host in the zonefile from the server it's hosted on. Is this a recent bug in bind? More information about my setup and issue can be found here: https://serverfault.com/questions/1136914/bind-recursion-dns-server-returning-wildcard-address-for-host-despite-exact-entr From what I found online, if there's a specific host A record entry defined, it should always return that IP. Wildcard is only for those not defined. Yet, when I remove the wildcard from the zonefile, my bind recursion instance returns the correct value, but not when the wildcard entry is there. But Google and other major DNS providers return the non-wildcard value as expected. Please provide concrete example, I can't query fun.test.test.me. nor test.test.me. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- 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: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?
On 28.06.23 15:45, Ubence Quevedo wrote: My question is, is there any way to "properly" return a hostname/IP based on what network the request is coming from? bind has "sortlist" statement that could do what you want. It will provide all IPs but sorted differently. Otherwise, you can set up multiple views with different versions of the same zone, configured to provide different verision according to source IP. This is much harder to set up. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- 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: latency and response time
On 27.06.23 16:22, sami.ra...@sofrecom.com wrote: Hello In DNS benchmarking which is more important latency or response time? for a DNS server what is the difference between the two values? I don't see any difference between those two. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 -- 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: Controlling which interface named uses
On Sat, 10 Jun 2023 19:24:03 +0200 Ondřej Surý wrote: You are over-complicating things. If unconfigured, named binds the outgoing UDP to 0.0.0.0 (::0), which means the chosen IP address is picked by the kernel. You need to configure priorities on your interfaces in the kernel - ip route is your friend. And for goddess’ sake, don’t do anything wild like proposed round robin across default routes. That would be a living hell to debug. On 11.06.23 10:34, Paul Kosinski via bind-users wrote: If you have some external interfaces you *don't* want named to use, but might want other outgoing traffic to use, you would need some "policy based routing", which can get complicated. In Linux, this is controlled by "ip rule" (not "ip route"). note that query-source settings affects source IP of packet, while "ip rule" affects outgoing interface (unless you also configure SNAT for those packets), so they are not exactly the same. In some cases you may need both. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I don't have lysdexia. The Dog wouldn't allow that. -- 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: migration to new isp - now private addresses showing up publicly?
On 23.05.23 12:22, Kaya Saman wrote:
I've got a very strange problem that has emerged somehow after
migrating my isp.
My setup previously used 2x servers in master/slave configuration for
my public "view" and then had 3x servers for the "internal" view. This
was working fine for years and I have been regularly testing using
online dns healthcheck sites such as mxtoolbox etc...
Now when I try to run any type of check from mxtoolbox or other site
eg. https://dnschecker.org/ I am getting my private IP's showing
instead of the public ones?
Initially it started off by my external zone files not transferring
which I managed to see that the information was trying to traverse my
NAT (I know, not the best practice to have all dns servers on the same
network).
As a result external emails from my mail server are not working too
well with a hit and miss type thing going on right now.
Just to go over, my zone files are fine as the 'external' ones only
have public ip addresses in them and do not include any type of
internal addressing whatsoever.
Here's an example of the config in named.conf for the master:
view "external" {
match-clients { !internals; any; };
[...]
view "external" {
match-clients { !internals; any; };
I don't see your definition of "internals".
Also, I don't see your definition of internal view.
if internal IP addresses are visible on the internet, obviously the internet
sources fall into your internal view, not into this one.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.
--
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: resolver: DNS format error from
On 17.05.23 11:31, Greg Choules via bind-users wrote: TL;DR 9.18 is stricter than 9.16 at handling junk responses from authoritative servers. I think there were even "DNS flag day"s when operators were supposed to install/configure systems that comply to standards. After next DNS flag say (none announced afaik) we should expect broken servers stop being supported - whoever owns one, will have troubles. Looking at a packet capture for this from my own BIND server (9.18.14) the response from 195.178.56.17 is FORMERR, which tends to mean that it objects to something in the query. The correct response to something you don't like is to ignore it, so this server is not obeying protocol and 9.18 is not going to try and work around broken behaviour. I disabled sending of cookies to this server and now it works. It could be that it doesn't like cookies, or just any EDNS option that it doesn't know what to do with. Either way, it should be fixed. On Tue, 16 May 2023 at 15:53, Alex wrote: I have a bind-9.18.7 system on fedora37 and having some strange errors with some queries. $ host info.apr.gov.rs Host info.apr.gov.rs not found: 2(SERVFAIL) in my bind logs I have the following: 16-May-2023 10:37:49.800 resolver: DNS format error from 195.178.56.17#53 resolving ns1.apr.gov.rs/ for : server sent FORMERR 16-May-2023 10:37:49.800 lame-servers: received FORMERR resolving ' ns1.apr.gov.rs//IN': 195.178.56.17#53 16-May-2023 10:37:49.800 lame-servers: timed out resolving ' info.apr.gov.rs/A/IN': 212.62.49.194#53 16-May-2023 10:37:49.800 query-errors: client @0x7f9d546d5168 127.0.0.1#59712 (info.apr.gov.rs): query failed (failure) for info.apr.gov.rs/IN/A at ../../../lib/ns/query.c:7717 In the limited search results I've found for this, I believe it has something to do with dnssec or EDNS, but I really don't know how to troubleshoot this. Is this a known problem? It also appears to be happening with even hosts like ticketmaster? 16-May-2023 10:21:09.348 lame-servers: FORMERR resolving ' engage.ticketmaster.com/NS/IN': 205.251.194.123#53 The host resolves fine on my bind-9.16.38 system using the exact same configuration, as well as most or all public resolvers. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. -- 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: host restriction
On 15.05.23 20:58, Kereszt Vezeték wrote: Can someone help me with the following problem ? I have a dns server in my private network with a local domain. The dns server forward the public request to the google dns server . why? BIND server can resolve perfectly without fdorwarding anywhere. I wold like separate hosts in the inside network. One group allow only the local host resolve, not forward to the 8.8.8.8 .Other group allow the local hosts resolve, and able to forward to the google dns server. Are there any way to solve this problem with bind9 ? Local subnet 192.168.1.0/24 192.168.1.10 allow forward to 8.8.8.8 192.168.1.11 allow forward to 8.8.8.8 192.168.1.20 disable forward 8.8.8.8 192.168.1.21 disable forward 8.8.8.8 And how should request from these IPs be resolved? If really neede (see my comment above), I recommend using views for this. Mostly because they can have separate cache. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Your mouse has moved. Windows NT will now restart for changes to take to take effect. [OK] -- 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: Bind dns amplification attack
On 3/28/23 11:28 AM, Matus UHLAR - fantomas wrote: Yes, this is one of the problem "authoritative zones for local use". On 28.03.23 12:18, Grant Taylor via bind-users wrote: Authorizing the /zone/ for local use wasn't the problem. The problem was that the world could get some of that zone's data from the query cache even if they couldn't query the zone directly. when was this? querying cache is by default allowed for the same clients as recursion, perhaps unless it was old BIND version. The default root "hint" zone is only available for those who have recursion available. I feel like the "root hint zone" is considerably different than "root zone" proper. The fact that they have different zone types seems to support that. yes. The content of hint zone is abused to generate aplification attack: Mar 26 16:03:53 fantomas named[1654]: client @0xe7379d50 195.88.25.138#59467 (.): query (cache) './ANY/IN' denied If you have local root zone, response is provided by default, it can be huge: % dig +noanswer +noadditional +nocomments +nocmd +noquestion -t any . @fantomas.fantomas.sk ;; Query time: 0 msec ;; SERVER: 195.80.174.185#53(195.80.174.185) ;; WHEN: Wed Mar 29 09:23:27 CEST 2023 ;; MSG SIZE rcvd: 2904 but default "type hint" root is treated as cache and REFUSED is sent. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. On the other hand, you have different fingers. -- 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: Bind dns amplification attack
On 3/28/23 10:48 AM, Matus UHLAR - fantomas wrote: If your server has authroritative zones for internal use, yes, in such case allow-query is good idea. On 28.03.23 11:02, Grant Taylor via bind-users wrote: The server that I first set this on had a secondary copy of the root zone for my systems use. I ended up adding additional restrictions to prevent the world from querying it in addition to the public zones that are allowed to be queried by the world. Yes, this is one of the problem "authoritative zones for local use". The default root "hint" zone is only available for those who have recursion available. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. -- 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: Bind dns amplification attack
On 3/28/23 6:30 AM, Matus UHLAR - fantomas wrote:
Great, this means that only clients with those IP addresses can
query your server for non-local information.
On 28.03.23 10:16, Grant Taylor via bind-users wrote:
I used to think the same thing.
Then I learned that I needed to also add similar configuration for
`allow-query {...};` and `allow-query-cache {...};`
allow-query-cache defaults to content of allow-recursion if only the latter
is defined.
allow-query is safe to configure if nobody is supposed to query your server
from outside - e.g. your server does not provide authoritative zones for
use from internet.
If your server has authroritative zones for internal use, yes, in such case
allow-query is good idea.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I'm not interested in your website anymore.
If you need cookies, bake them yourself.
--
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: Bind dns amplification attack
On 28.03.23 18:48, Nyamkhand Buluukhuu wrote:
Like below in named.conf:
acl recclients {
43.228.128.2/32;
202.70.32.17/32;
103.29.147.0/29;
103.99.103.0/24; }
allow-recursion { recclients; };
Great, this means that only clients with those IP addresses can query
your server for non-local information.
So, your server should NOT be part of Amplification attack.
(unless you run VERY OLD version of BIND)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!
--
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: Bind dns amplification attack
On 28.03.23 16:04, Nyamkhand Buluukhuu wrote: No, I have an access list that allows only our ISP zones. zones? access lists are meant to limit clients. how do your access limits look like? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) -- 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: Deprecation notice for BIND 9.18: (root-)delegation-only option
On 22.03.23 17:36, Ondřej Surý wrote: in line with our deprecation policy, I am notifying the mailing list about our intent to deprecated the delegation-only and root-delegation-only options. This is again adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated in BIND 9.18. On 23. 3. 2023, at 17:57, Matus UHLAR - fantomas wrote: what's the reason? Code cleanliness? Or is it problematic to maintain? On 23.03.23 19:11, Ondřej Surý wrote: Those are wrong questions to ask - the right question to ask is whether this bring any value - and the answer is that it doesn't, then it becomes unmaintained and untested cruft. my question was related to the next one. The (root-)delegation-options were introduced as a countermeasure for the infamous Site Finder by Verisign[1]. With the controversy around this and introduction of DNSSEC, the likelihood of this happening is infinitesimal. If you don't even know what those options does, the TL;DR is that it disables the non-delegation records for configured domains (TLD), this in turns might break legitimate TLDs like .de, .fr, .museum and others [2][3]. If you know a legitimate reason to keep those options, please describe the use case here or in the issue mention below. well, if "just for sure no other AH tries that again" is not a reason for you... No, it will not happen again, at least not at the TLD level. The community has learned and ICANN has learned too. this is what I wanted to hear. Unfortunately there are companies that do this for their customers. If this should happen at any level, what are the possibilities to discard such responses? Use RPZ that will rewrite specific A/ records into NODATA/NXDOMAIN? We'd need the specific address(es) to rewrite but we could live with that. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. -- 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: Deprecation notice for BIND 9.18: (root-)delegation-only option
On 22.03.23 17:36, Ondřej Surý wrote: in line with our deprecation policy, I am notifying the mailing list about our intent to deprecated the delegation-only and root-delegation-only options. This is again adept for expedited deprecation - it will be removed in BIND 9.20 and deprecated in BIND 9.18. what's the reason? Code cleanliness? Or is it problematic to maintain? The (root-)delegation-options were introduced as a countermeasure for the infamous Site Finder by Verisign[1]. With the controversy around this and introduction of DNSSEC, the likelihood of this happening is infinitesimal. If you don't even know what those options does, the TL;DR is that it disables the non-delegation records for configured domains (TLD), this in turns might break legitimate TLDs like .de, .fr, .museum and others [2][3]. If you know a legitimate reason to keep those options, please describe the use case here or in the issue mention below. well, if "just for sure no other AH tries that again" is not a reason for you... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Honk if you love peace and quiet. -- 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: Deprecation notice for BIND 9.18: Differentiated Services Code Point (DSCP) support
> On 5. 1. 2023, at 14:46, Robert M. Stockmann wrote: > This is like Mercedes Benz announcing they will only sell > the Baby Benz model, which is a Volkswagen EV barebonez with > the VW logo replaced with a plastic Mercedes Benz star On Thu, 5 Jan 2023, [utf-8] OndÅej Surý wrote: I've asked for a strong use-case and all I've got was a snark. Do you actually have a real-world use for DSCP or are you just in bad mood? On 05.01.23 15:21, Robert M. Stockmann via bind-users wrote: From /usr/share/doc/bind-9.9.9P6/FAQ : there's no DSCP mentioned here. Are you aware that only the DSCP flags are deprecated, not all *source and *forwardes etc options themselves? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Christian Science Programming: "Let God Debug It!". -- 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: bind-users Digest, Vol 4123, Issue 2
022) DSChange: 20221125053555 (Fri Nov 25 00:35:55 2022) DNSKEYState: omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent DSState: omnipresent GoalState: hidden -- Subject: Digest Footer ___ 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 ------ End of bind-users Digest, Vol 4123, Issue 2 *** -- 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 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages. -- 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: Reverse lookups not working when Internet connection failed.
On 07.11.22 15:57, David Carvalho via bind-users wrote: Finally had the opportunity to get back to this. Having internet connection restored, everything seems to be working as supposed to. One simple query from my client and one response from my server. Output from wireshark: 1 0.0010.0.0.199 193.136.66.1DNS 85 Standard query 0x000b PTR 8.66.136.193.in-addr.arpa 2 0.016660193.136.66.110.0.0.199 DNS 204 Standard query response 0x000b PTR 8.66.136.193.in-addr.arpa CNAME 8.0-28.66.136.193.in-addr.arpa PTR meteo.di.ubi.pt NS dns.di.ubi.pt NS dns2.di.ubi.pt A 193.136.66.1 A 193.136.66.2 Just 2 packets. great, it works. But on the command line I get the following, and I'm confused why the "non-authoritive answer": Non-authoritative answer: ---here!??? 8.66.136.193.in-addr.arpa canonical name = 8.0-28.66.136.193.in-addr.arpa this happens your server is not authoritative for the 66.136.193.in-addr.arpa domain. I guess your servers don't fetch 66.136.193.in-addr.arpa from your ISP. I also wasn't able to reach your servers: 8.66.136.193.in-addr.arpa. 86400 IN CNAME 8.0-28.66.136.193.in-addr.arpa. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns2.di.ubi.pt. 0-28.66.136.193.in-addr.arpa. 86400 IN NS dns.di.ubi.pt. ;; Received 121 bytes from 193.136.2.228#53(ns02.fccn.pt) in 56 ms % dig -x 193.136.66.8 @dns.di.ubi.pt. dig: couldn't get address for 'dns.di.ubi.pt.': failure % dig -x 193.136.66.8 @dns2.di.ubi.pt. dig: couldn't get address for 'dns2.di.ubi.pt.': failure so there's another problem to solve. IN NS dns.di.ubi.pt. IN NS dns2.di.ubi.pt. looks like your servers dns.di.ubi.pt (193.136.66.1) and dns2.di.ubi.pt (193.136.66.2) aren't reachable from internet. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... -- 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: automatic reverse and forwarding zones
On 7. 11. 2022, at 16:19, Matus UHLAR - fantomas wrote: while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. On 07.11.22 16:28, Ondřej Surý wrote: That's not any different than wildcard record in a forward zone. The resolvers already have to deal with garbage in the cache and cache eviction algorithms. I'm afraid that this problem can become really huge when someone creates huge amount of generated records, e.g. using proposed module. The DNS server doesn't live among rainbows and unicorns, so we prepare for the worst to come from network, not the best. Let's hope such problem won't appear. I was only curious if it may happen, if there's need to consider it. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse -- 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: automatic reverse and forwarding zones
On 7. 11. 2022, at 15:50, Matus UHLAR - fantomas wrote: sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? On 07.11.22 16:07, Ondřej Surý wrote: How do you know it's a garbage? One woman's trash is another woman's treasure... That is the point. If anyone generates generic DNS records for /64 (16Ei addresses) as the OP asked for: https://lists.isc.org/pipermail/bind-users/2022-October/106846.html ...it will most probably be just garbage. while it's doable, and with using BIND plugin at generating server it won't need much of memory, any server that will be repeatedly asked to resolve IPs from that range will fill its cache with generated records. Won't this cause troubles on any server? I don't know - it might. if it does, do we have anything against it? Won't this cause even more problem on server generating those records? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody -- 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: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. On 07. 11. 22 15:23, Matus UHLAR - fantomas wrote: what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. On 07.11.22 15:42, Petr Špaček wrote: That's part of normal resolver operation: Garbage in - garbage out - garbage eventually cleaned out from cache. There is nothing special about PTR records in that regard. sooner or later, but filling up cache with garbage could result in other non-garbage records being flushed out. Are there any mechanisms that would wipe this garbage before other records, used more often even if not very recently? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... -- 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: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 On 28. 10. 22 9:29, Matus UHLAR - fantomas wrote: this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. On 07.11.22 15:06, Petr Špaček wrote: Yes, that's exactly why plugin is needed. The plugin can generate answers on the fly without having all of them in memory. what about BIND receiving those records? I don't want my resolving DNS server to fill out cache by reverse records of any remote ipv6 range/ranges. We'd need to clean those too. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod -- 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: Reverse lookups not working when Internet connection failed.
On 11/6/22 11:12 AM, Carl Byington via bind-users wrote: or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone which has a slight advantage when the same client has multiple disjoint parts of the same /24. On 06.11.22 20:08, Grant Taylor via bind-users wrote: I find that $CLIENTNAME or some other stand in for the client is a potential for information lek. I agree, the client may want to stay private. There is nothing inherent in the CNAME to non-identifying RNAMEs that leaks any client identifying information. Conversely the client is in charge of what information they put in the sub-zone, so it's not the ISP leaking client identifying information. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Two words: Windows survives." - Craig Mundie, Microsoft senior strategist "So does syphillis. Good thing we have penicillin." - Matthew Alton -- 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: Reverse lookups not working when Internet connection failed.
On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote: 3. allow your servers to to fetch 66.136.193.in-addr.arpa. On 06.11.22 20:05, Grant Taylor via bind-users wrote: Is this 3rd step documented somewhere? I searched for it in RFC 2317 but didn't find it. Maybe I over looked it. This step is not necessary for classless reverse DNS delegation. This step is however necessary for OP's DNS server being able to reverse resolve its own IP range, when its connectivity is down (this the OP's question), because OP's clients will try to resolve names in 66.136.193.in-addr.arpa. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. N.B. I've had some problems with the forward slash character "/" in domain names multiple times in the past. I'd stick with the hyphen "-" for compatibility. I've had no problem with that one in the past. TMTOWTDI -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. If Barbie is so popular, why do you have to buy her friends? -- 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: Reverse lookups not working when Internet connection failed.
On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote: Thank you all for the replies. For what I understand after reading your replies (I might be wrong :) ), reverse lookups fail when I have no outgoing connection because some caching or or transfer is needed from 66.136.193.in-addr.arpa. , wich I don't control. This is divided in several networks, 2 of them under my control. correct. Admin of that zone is supposed to: 1. create proper CNAME records: 0.66.136.193.in-addr.arpa. CNAME 0.0-28.66.136.193.in-addr.arpa. ... 15.66.136.193.in-addr.arpa. CNAME 15.0-28.66.136.193.in-addr.arpa. 2. delegate 0-28.66.136.193.in-addr.arpa. to your servers, make their servers secondary for this zone (optional) 3. allow your servers to to fetch 66.136.193.in-addr.arpa. step 1. creates proper aliases step 2. creates working delegation step 3. allows you to see reverse records when your connection is down. alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 0-15.66.136.193.in-addr.arpa. instead of 0-28.66.136.193.in-addr.arpa. I'll have to read more carefully your suggestions to see if I find an alternative way to achieve this only by modifying my zone files, without messing up my current setup. I'll let you know how it goes. On 11/4/22 2:07 PM, Mark Andrews wrote: Any ISP that offers these delegations should be allowing their customers to transfer the zone that contains the CNAMEs for the customer address space by default. I've had enough trouble getting ISPs to support 2317 delegation period. I think that asking them to allow me to do a zone transfer would have been a hard no. I certainly don't think this would be allowed /by/ /default/. I just checked and § 5.1 of RFC 2317 mentioned having the parent do a secondary zone transfer of the child zone. But I don't see any mention of the child doing a secondary zone transfer of the parent zone. I think that would be a good idea. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. -- 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: Reverse lookups not working when Internet connection failed.
On 04.11.22 15:41, David Carvalho via bind-users wrote: We've had an internet failure for a few days last week and as services got online I found the following: Dns queries about my.domain from my.domain worked as expected. Since there was no internet connection, I obviously couldn't query the outside world. Reverse (PTR) Dns queries about my.domain from my.domain didn't work. Now that the internet connection is restored, everything is ok. The reverse entries are in the format "z.y.x.in-addr.arpa."for IP x.y.z Aren't they supposed to work locally when no outside connection is available? if they are properly configured, yes. What could I be missing? can you provide an example of an IP and configured reverse zone, and the zone file? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. -- 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: Classless reverse zones CNAME and PTR resolution issue
On 31.10.22 15:04, Nagesh Thati wrote:
Hello,
Hello,
gmail sucks very much when it comes to formatting plaintext portions of e-mail.
That makes mail hard to read.
I recommend you using different mail client, mozilla trhunderbird should be
fine.
I am facing an issue with CNAME and PTR records resolution issues when
classless reverse zones are defined in the BIND 9.16.* version (Without
recursion), but it used to work in 9.11.* version (Without recursion).
Below example shows what reverse zones are created and how the dig output
is giving,
*zone "22.10.13.in-addr.arpa" IN {type master;file
"/var/named/zones/masters/db.22.10.13.in-addr.arpa";check-names
ignore;zone-statistics yes;};*
*zone "0-25.22.10.13.in-addr.arpa" IN {type master;file
"/var/named/zones/masters/db.0-25.22.10.13.in-addr.arpa";
check-names ignore;zone-statistics yes;};*
as I say, sucks very much.
2.0-25.22.10.13.in-addr.arpa. 1200IN PTR
3G00051Phone.india.com.
2.22.10.13.in-addr.arpa. 1200 IN CNAME 2.0-25.22.10.13.in-addr.arpa.
I am getting the answer as only CNAME, not getting the exact A record for
that IP address. This used to work in BIND 9.11.* version, recently I
upgraded to 9.16.* latest version and from that I am facing this issue.
But when I enable the recursion on BIND 9.16.* then I am getting the
expected answer as below,
Can someone help me why this behaviour is seen on BIND 9.16.* version.
perhaps there's an error in your zone 22.10.13.in-addr.arpa.
and named did not load it.
try executing "rndc reload" and see what named logs tell you
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins. -- Daffy Duck & Porky Pig
--
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: automatic reverse and forwarding zones
On 28.10.22 08:26, Ondřej Surý wrote: BIND 9 have support for writing plugins, and we would accept a well written plugin that would allow generating the forward/reverse plugins on the fly. There’s already a feature request for it here: https://gitlab.isc.org/isc-projects/bind9/-/issues/1586 this request for ipv4 too. I really don't think making generic named for ipv6 addresses within range bigger then e.g. /112 (64Ki addresses) makes any sense. prehaps it may for small subsets of IP addresses /64 is 18446744073709551616 addresses, that can't be scanned in meaningful time and this number of DNS records would just mess up any DNS servers' memory. making BIND resilient against overflowing memory this way would make more sense than creating generic addresses. Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: Edit the corresponding REVERSE zone & add following line in the end $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. Dont forget to Reload bind config & you are done. On 27.10.22 07:58, Marco wrote: How is the syntax for IPv6? Is it possible to do it for an entire /64? On 27. 10. 2022, at 10:12, Matus UHLAR - fantomas wrote: this would create HUGE amount of records, they wouldn't fit into memory. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.* -- 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: automatic reverse and forwarding zones
Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED: Edit the corresponding REVERSE zone & add following line in the end $GENERATE 1-255 $ IN PTR 10-11-11-$.example.com. Dont forget to Reload bind config & you are done. On 27.10.22 07:58, Marco wrote: How is the syntax for IPv6? the syntax for $GENERATE is the same, just the records are different. Is it possible to do it for an entire /64? this would create HUGE amount of records, they wouldn't fit into memory. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0... -- 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: dig +norecurse behaviour changed with 9.16.33
On 27.10.22 09:08, Veronique Lefebure wrote: yes, here is a concrete example: # ip-dns-1 runs BIND 9.16.33: dig @ip-dns-1 spectrum.cern.ch +short +norecurse spectrum-lb.cern.ch. <- Here we get only the CNAME # ip-dns-0 runs BIND 9.11: dig @ip-dns-0 spectrum.cern.ch +short +norecurse spectrum-lb.cern.ch. xxx.xxx.xx.140 < Here we get in addition the IP of spectrum-lb.cern.ch. And yes, a capture shows confirms indeed that dig returns less information when the BIND 9.16.33 DNS server is used. I guess you can easily reproduce that behaviour, unless it is due to a mis-configuration bit on our DNS server ? I could not reproduce as the query currently returns NXDOMAIN AFAIK different servers may return different results depending if they have the requested record in cache or not. +norecurse only asks server not to send query out, it doesn't prevent returning cached record. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool. -- 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: Question About Internal Recursive Resolvers
On 18.10.22 09:23, Bob McDonald wrote: There are no outside clients. In this example, I'm only discussing inside clients on inside DNS. The recursive resolvers that ALL inside clients connect to will seek responses from the DNS root servers AFTER determining that the response can not be determined from the internal DNS zones. There is no access provided to outside (internet centric) clients to inside DNS. The determination of known/unknown clients is via a NAC layer and further, the classification of unknown gets automatically assigned to those clients combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most organizations with a NAC layer in place have procedures to allow unknown clients temporary access at some level (e.g. vendors, etc.). this way the situation is even easier. you can use two distinct serves for internal and wi-fi clients, where only internal server will contain internal zones. you can achieve the same effect with views, no other DNS servers are necessary -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller -- 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: Question About Internal Recursive Resolvers
On 15.10.22 16:03, Bob McDonald wrote: OK, if a known client accesses DNS on the internal network, that client is pointed at a recursive resolver (e.g by DHCP). That resolver either provides access to the internal DNS zones (e.g. via stub zones) or sends the client query to the root servers on the internet. An unknown client (e.g. guest WiFi) will be given the same resolver address for its DNS server. At this point it would require ACLs to prevent that unknown client from accessing the internal DNS zones. All DNS traffic from that client would be sent to the internet. Another way to achieve that would be to have a separate set of DNS resolvers for unknown clients (resolver addresses handed out via DHCP). That's my current view of how to get things done in this case. What I'm discerning from the discussion so far is that this isn't strictly necessary. The internal DNS zones can/should reside on the recursive resolvers. The question of unknown client access to internal DNS zones is resolved (no pun intended...). bind supports views, which work like virtual DNS servers, you can define some zones only in internal views. you can even support multiple views for internal, wi-fi and external clients, where the internal clients will get recursion and see internal zones, wi-fi clients get recursion w/o seeing internal zones, and external zones only see public zones. You can separate these clients by their source IPs, without any need to configure separate servers with separate iP addresses. you may want to share dns cache between internal and wi-fi zones using attach-cache directive, and share public zones to the internal and wi-fi directives by configuring thoze zones using "in-view". RPZ COULD be implemented on ANY of the recursive DNS resolvers. note that RPZ is designed to prevent/redirect access to destinations, not to clients - it's not designed to separate clients and access to zones this way. The tsig key discussion is around its use as a method of allowing updates to internal DNS zones. Strictly hypothetical. Don't get hung up on it. Tsig is good security measure to only allow specific clients to submit updates. You can configure tsig key to belong to particular view even without having proper client IP address. Thank you all for the information. You've provided answers to my questions and have renewed my faith in geekdom. If anyone is still confused, I'd be glad to discuss this offline until we have a final solution. Then we can publish if necessary. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Microsoft dick is soft to do no harm -- 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: Question About Internal Recursive Resolvers
If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. #truth On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote: forward zones - named sends recursive query to the primary servers stub zones- named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. On 15.10.22 11:50, Grant Taylor via bind-users wrote: Please clarify where recursion needs to be allowed; the BIND server clients are talking to and / or the back end server that BIND is talking to on the client's behalf. I'm not completely clear and I think it's better to ask than to assume incorrectly. recursion must be allowed on the BIND server that is supposed to forward queries from clients, and those clients need to have recursion enabled on that BIND server. the Bob mentions copnfiguring recursive server so I assume everything is already allowed, I just noted that recursion is needed for zone types above. On 10/15/22 10:03 AM, Bob McDonald wrote: If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Sorry if I'm being particularly dense this morning, but I'm not following ~> understanding Bob's and Matus's statements like I want to. How does hosting the zone on an internal server provide any additional security? Or are you simply relying on other security mechanisms to prevent non-secure clients -- as Bob described them -- from accessing the server ~> zone? Company has internal/recursive servers only accessible by internal clients. If you configure internal zones on these servers, all internal clients will immediately have access to these zones, no measures needed (though possible) If you configure internal zones on separate servers, you must: - configure recursive servers to direct lookups to authoritative servers - control access to those zones on authoritative servers. so, you must take two more measures. I feel like, by default -- as Bob described, any hosted zone is going to be accessible by any client that can query the server. Bob describes moving internal zones to non-recursive servers. https://lists.isc.org/pipermail/bind-users/2022-October/106756.html Which requires those measures above, without obvious need, except the misunderstood principle "separate recursive and authoritative servers". With this in mind, I feel like the type of zone; primary / secondary / mirror / stub / static-stub / forward, makes little difference in and of itself. Rather, it would be dependent on global and / or per-zone allow-* statements to protect the server / zone(s) at the BIND application level. Does that make sense? What am I missing / misunderstanding? the point is to make the system simple and robust. separating DNS servers may make DNS more robust and it may make DNS less robust. Bob describes access to different zones from different clients (internal, wi-fi, ...) configured on recursive server. There's no visible gain if Bob moves internal zones to another server. However there are still some questions to this https://lists.isc.org/pipermail/bind-users/2022-October/106764.html - where/how/why is TSIG used - how is the DNS configured now, don't internal recursive servers have access to the internet now? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fighting for peace is like fucking for virginity... -- 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: Question About Internal Recursive Resolvers
I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. why? On 15.10.22 12:03, Bob McDonald wrote: My understanding has always been that the recommendation is/was to separate recursive and non-recursive servers. Now I understand I'm talking about an INTERNAL environment and the rules have over the years become somewhat lax... In this case I also believe this would provide a more granular approach to using security features such as tsig keys to control updates. This is a common misconception. Yes, it's a good idea to separate recursive servers accessed/used by your clients from authoritative servers accessed/used by whole internet. But this does NOT mean that internal/recursive servers must not, nor should not containt your internal zones, nor it means you should put your internal zones to your publicly accessible authoritative servers. If you have own zones for your own usage, exactly the same way you have recursive servers, it makes rarely sense to put them to other servers than your internal/recursive servers, just put internal zones to internal servers. If you are an ISP/registry/DNS provider, it makes sense to separate authoritative zones for your clients' domains, for all those cases your client move their domains somewhere else without notifying you (hell, they do that too often), or to be able to prepare moving domains to your servers. The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers)> Again, my understanding is that forwarding would require recursion. Thanks for the info about stub zones etc. forward zones - named sends recursive query to the primary servers stub zones - named fetches NS records from primary servers and uses them for resolution static-stub zones - named forwards iterative (non-recursive) requests to primary servers clients accessing any of these zones must have recursion allowed and recursion must be enabled in BIND. Access to the internal DNS zones would be controlled by location. if you have recursive servers in internal network, you don't need control access on auth-only servers If a non-secure client (read the next sentence...) accesses the same recursive server as a regular client, it will have access to the internal zones by default.. Therefore we need to have some sort of access controls in place. and THIS is exactly the reason you SHOULD put your internal zones on your internal server. Please forgive me if my post was confusing, arrogant, or naive. neither one. I'm simply trying to seek the wisdom of those on the list that have more experience or different experience than myself. Hopefully, I can gain from that wisdom and we can provide a kind environment where those less educated feel mentored. that's why we are here. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 -- 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: Question About Internal Recursive Resolvers
On 14.10.22 12:08, Bob McDonald wrote: I'm thinking about redesigning an internal DNS environment. To begin with, all internal DNS zones would reside on non-recursive servers only. why? That said, all clients would connect to recursive resolvers. don't they now? The question is this; do I use an internal root with pointers to the internal zones (as well as the outside DNS world) or do I include stub zones to point at the non-recursive internal servers? stub zones, forward zones (forward with recursion bit set) or static-stub zones (send iterative queries to configured servers) Access to the internal DNS zones would be controlled by location. if you have recursive servers in internal network, you don't need control access on auth-only servers. (e.g. guest WiFi devices would NOT have access to internal DNS zones...) Recursive resolvers would allow implementation of features such as RPZ, etc. do you need RPZ for internal zones? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors -- 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: Mailing list questions (DMARC, ARC, more?)
another test done I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. On 25.08.22 18:10, Alessandro Vesely wrote: Please tell us. On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" On 04.09.22 12:56, Alessandro Vesely wrote: They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. I haven't studied the ARC standard, but this looks correct. However, I was repeatedly unable to make opendmarc to accept arc result: Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=itqgpF3K; dkim-atps=neutral Authentication-Results: fantomas.fantomas.sk; spf=pass (sender SPF authorized) smtp.mailfrom=lists.isc.org (client-ip=149.20.1.60; helo=lists.isc.org; envelope-from=bind-users-bounces+uhlar=fantomas...@lists.isc.org; receiver=) Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 arc.chain="isc.org:isc.org:isc.org" From: frank picabia - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) I have tried both, no result. When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal: Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header? - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml this is not in debian distribution. when tried it, it shows correct: uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml RESULT: pass uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest RESULT: pass however, I was unable to make my dkim/dmarc PASS on a mail from this list that was: - arc-signed by ISC - DKIM fail (not munged) - not from ISC ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (body has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (body has been altered) (arc-verify.pl is a copy of the module's synopsis[*].) Then I tried it on Ged's message, earlier in this thread, and got: ale@pcale:~/tmp$ arc-verify.pl < arc2.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (message has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (message has been altered) So both messages seem to be valid, if you trust isc.org. The failure in the signature reflects that only the body was altered in your message, while also the header was altered in Ged's one. As ARC allows mediators to modify messages, only the last signature is significant. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? Mailman options[†] don't include something like *From munging*: Set this option to /Disabled/ to receive messages with the original From: line intact. Keep in mind that disabling this option will fail DMARC, so keep it enabled unless your MTA either doesn't check DMARC or accepts ARC overrides. It doesn't seem difficult to implement. It requires trusting the users, though. I'm going to ask Mailman developers. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this ad
Re: Mailing list questions (DMARC, ARC, more?)
On 25.08.22 18:10, Alessandro Vesely wrote: The lack of interest by others proves that From: munging is not so much of a nuisance as they say... On Mon 29/Aug/2022 12:09:10 +0200 Matus UHLAR - fantomas wrote: This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) On 01.09.22 12:07, Alessandro Vesely wrote: So do I, relying on SPF for DNSs. if DSN contains domain in From: address, they can be signed as well. microsoft messed this up. - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. Which is insecure. yes, but due to the above, since DSNs aren't DKIM-signed, they could be easily dropped, I assume either nobody tried to set DMARC policy to other than none or they had problems. While I keep p=none, anyone can post a spoof using my email address as From: and pretend to be me. It never happens, but some people believe it /cannot/ happen. I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges. -- 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: Mailing list questions (DMARC, ARC, more?)
On 25.08.22 18:10, Alessandro Vesely wrote: Thanks Ged for all the feedback. The lack of interest by others proves that From: munging is not so much of a nuisance as they say... This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. On Tue, 23 Aug 2022, Alessandro Vesely wrote: I see the list operates both From: munging and ARC sealing. While I'm clear about the former, I'm curious about how ARC works: Do any subscribers trust the seal by isc.org? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them -- 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: Question about additional section in BIND-responses
On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote: Using BIND-9.18.5 as a recursive server: What's the reason, that BIND answers with the additional section for the the following query where for example Knot resolver and also PowerDNS resolver doesn't add the additional section for the same query? [...] Any hints why BIND adds the additional section while other resolvers doesn't? Is there an option in BIND to behave like Knot/PDNS? On 8/17/22 02:27, Evan Hunt wrote: The option is "minimal-responses". If you set it to "yes", it will omit authority and additional section data except when necessary. The default is "no-auth-recursive", which omits authority section data when it isn't strictly necessary, but will still add additional data for records in the answer section. On 8/17/22 06:45, Tom wrote: I've already set "minimal-responses yes;", but the additional section/data is still shown. So based on your explanation, BIND assumes, this data is necessary, why? And why behaves BIND different here than Knot/PDNS where no additional section is shown for the same query? On 22.08.22 15:06, Tom wrote: Does an BIND expert has an idea or an explanation, why the additional section is still shown, although "minimal-responses yes;" is set? And why the additional section seems necessary for BIND and not for example for Knot/PDNS for the same query? ftp://ftp.isc.org/isc/bind9/9.18.5/doc/arm/html/reference.html#namedconf-statement-minimal-responses yes: the server only adds records to the authority and additional sections when such records are required by the DNS protocol (for example, when returning delegations or negative responses). This provides the best server performance but may result in more client queries. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. -- 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: Can't modify an existing SPF record
On 08.07.22 13:04, Roberto Carna wrote: Dear all, I add "a:relay.company.com" using the CLI in the BIND master: company.com. 3600IN TXT "v=spf1 mx a:relay.company.com -all" But after restart, this change never goes to the slaves. If I add "ip:x.x.x.x" for example, this change goes ok to the slaves. And from webmin interface, if I add the "a:relay.company.com" I get this error: Failed to save record : 'relay.company.com' is not a valid host to allow sending from relay.company.com does not exist: % host -t a relay.company.com relay.company.com has no A record % host -t relay.company.com relay.company.com has no AAAA record you must add a host that does exist. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I just got lost in thought. It was unfamiliar territory. -- 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: resolving www.ecb.europa.eu tages ages
On 20.06.22 17:44, Sten Carlsen wrote: From my corner of Eurpoa it looks worse. % time dig www.ecb.europa.eu [...] dig www.ecb.europa.eu 0.00s user 0.01s system 0% cpu 8.609 total With dig +trace it takes longer: dig +trace www.ecb.europa.eu 0.01s user 0.02s system 0% cpu 1:24.75 total I believe this is what Borja mentioned: https://lists.isc.org/pipermail/bind-users/2022-June/106338.html https://lists.isc.org/pipermail/bind-users/2022-June/106339.html (thanks). so there are some delegations that SOMETIMES cause long delays in resolution. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease -- 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
resolving www.ecb.europa.eu tages ages
g+57Z2V5Zj7lvdDDG8f2IeJ QY75DcTLFuWriUS1Qos1+koXYox4qmAXjq6BgN8/T82iVpYqPjBMxoVJ pjcWnEO/GYzcVOZXQefDNPivF3TeeojbgPt5pmBhz29MlflPi0i1GAna mg1soT9JnEDFmK1y6Va7yVrOPFbpuslSfJSX710JFwVEZsEBfXSWt7ZE sp7gYQ== ecb.europa.eu. 1800IN RRSIG NSEC 8 3 1800 20220715202454 20220617040450 33483 europa.eu. CsLsmCuiFgHEzpPIFcecZojRcm8CmuV6laZJP0kca+xmbUMKiYV9aDoZ Yq9+DAPHJBdnYXUHAGPjLuxC+jfWSwUg2k3t/obrFFYz3MOV2xf802Az mrwjQKbozUVVfiftuPl+n+iaw60ocqyfH1Ev8qDBjiMJ3a382VUWFu5r DP2mpJ9vl9xvAMxN51uZ38lSkXArVEU8t84OMr7Dh6zikvcIlbwaj3TH RFsqoDIB3yfPuAAJksqvxWg8DPARONUHfHZ7njiWef3njjwfcGnRv7sn MecG5j0hL2SrfHxI4eqbxRabOzZ2gzLUh37aIFnptHHcZy84fJgT0Ve1 sE1iOg== ;; Received 891 bytes from 147.67.12.4#53(ns3lux.europa.eu) in 15 ms www.ecb.europa.eu. 300 IN CNAME www-ecb-europa-eu.ax4z.com. ;; Received 86 bytes from 156.154.65.109#53(pdns109.ultradns.net) in 11 ms real0m5.117s user 0m0.011s sys 0m0.035s -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "One World. One Web. One Program." - Microsoft promotional advertisement "Ein Volk, ein Reich, ein Fuhrer!" - Adolf Hitler -- 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: Bind failures following update/reboot w/ 9.18.1
On 13.05.22 10:06, Philip Prindeville wrote: After rebooting my OpenWRT router with Bind 9.18.1 yesterday, I started seeing a lot of: May 12 19:24:06 OpenWrt named[11061]: validating ./NS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving './NS/IN': 192.203.230.10#53 May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 8.8.4.4#53 May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 8.8.4.4#53 May 12 19:24:06 OpenWrt named[11061]: validating net/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'net/DS/IN': 66.232.64.10#53 May 12 19:24:06 OpenWrt named[11061]: validating com/DS: no valid signature found May 12 19:24:06 OpenWrt named[11061]: no valid RRSIG resolving 'com/DS/IN': 66.232.64.10#53 doesn't your ISP block or intercept DNS queries? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Holmes, what kind of school did you study to be a detective? - Elementary, Watkins. -- Daffy Duck & Porky Pig -- 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: DNS traffic tracking
On 09. 05. 22 10:34, Alex K wrote: The initial and current approach is to provide DNS free of charge, which simplified things for me. Though the traffic in question is satellite traffic with monthly allowances of roughly 4 to 8GB, thus every MB counts. The problem now is that I see sometime 700MB of DNS traffic for 2GB of Internet browsing within one month. On 09.05.22 10:47, Petr Špaček wrote: Sounds like either: - Broken caching or, - Random subdomain attack to me. maybe someone uses VPN over DNS... in such case, rate limiting of client comes to mind... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. -- 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: Is anyone here forwarding your bind-users messages to gmail or a google-hosted domain?
Dan Mahoney writes: We've seen a number of messages reported to us as having an isc.org "from" address, and as having our dkim signatures, but the signatures failing to verify, perhaps because a forwarder may have added a subject tag or rewritten some other header. Of course, SPF also fails because those servers aren't in our SPF record. On 20.04.22 10:55, Bjørn Mork wrote: I don't forward to gmail, but I've noticed that my DKIM signature on messages to this list fail verification. I believe this problem is specific to this list, as it doesn't happen with most other lists. I assume the reason is the body modfications by the list server. apparently. from what I know, mailman only modifies From: if the headers/body are changed AND dmarc policy of the originator domain is set to reject. yours is "none. I encountered this problem with different mailing list and also got customer ticket with the same problem. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "Where do you want to go to die?" [Microsoft] -- 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: Access denied Bind9
On 08.03.22 04:44, Ritah Mulinde wrote: Just got my primary and secondary name servers running. primary and secondary for your domains, or primary and secondary to provide DNS service for your clients? if the latter, you must allow recursion for your IP ranges (and ONLY for your IP ranges) However, when i reload rdnc and tail the syslogs all i get is "(.xx.com): query (cache) '.xx.com/A/IN' denied" does your server provide domain xx.com? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night. -- 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: Forwarding zone, setup
On 2/28/22 1:47 PM, Gregory Sloop wrote: I figured before I beat my head against the wall for too long, I'd ask the real experts! :) On 28.02.22 22:27, Grant Taylor via bind-users wrote: I'm definitely not an expert. I don't even pretend to be one on T.V. But I do wonder what, if any, sort of restrictions you are placing on recursion on your system. It's my (mis)understanding that recursion has some effect on forwarding queries. My limited understanding is recursion is another way of saying if the server should chase the answer for you or not. If it doesn't have it in it's own data (authoritative and / or cache), then it's recursion setting comes into play. If I'm mistaken, please correct me. you are right, forwarding queries requires recursion. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool. -- 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: copy EDNS options to resolver response
On 19.02.22 12:31, Brian J. Murrell wrote: I have a BIND9 server configured as a resolver for the local network to forward all requests to 1.1.1.1. what's the point of this setup? BIND can resolve by itself perfectly and you wouldn't rely on 3rd party service Given that that 1.1.1.1 includes (RFC8914) EDE EDNS options in it's responses, can I configure the BIND resolver to forward those EDNS options in it's response to the client? bind uses edns by default unless you turn it off. Or unless your firewall blocks it, in which case you can't enable it. While I know BIND9 doesn't yet do EDE itself, I am hoping for an option in BIND to just blindly copy whatever EDNS options it receives to it's client. no, bind uses edns as it needs, not as client asks it to. communication with clients is independent from communication with servers -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages. -- 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: Using Wildcards in Subdomain Records
On 17.02.22 11:08, muhanad wrote: Hello allI have a main domain (aa.example.com) that have hundereds of sub-domain ( bb.aa.example.com). I am setting a wildcard in the record file for the main domain so it forwards all subdomains to a number of addresses in a round-roben fashion( the record as follows "* IN A 192.168.1.x ) the issue I am facing is the wildcard forwards any subdomain regardless wether it is a true subdomain ( bb.aa.example.com ) or it is not a true subdomain ( xx.bb.aa.example.com ) These are subdomains too. And this is how wildcards work, you can't change it. If you don't like it, you'll have to list all records. if there are the same records with multiple addresses, you can define wildcard.example.com. A 192.0.2.1 A 192.0.2.2 A 192.0.2.3 bb.aa.example.com. CNAME wildcard.example.com. cc.aa.example.com. CNAME wildcard.example.com. etc. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. LSD will make your ECS screen display 16.7 million colors -- 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: ISC BIND & Windows
On 02.02.22 00:14, jukka.pakka...@qnet.fi wrote: Just read from the 9.18.0 release notes that Windows is not supported. Since don't remember reading expressly stated that Windows support would end with 9.16.x branch, inquiring if there is more information about future Windows compatibility available... is the plan to include support to Windows at some point, to some current or future Windows Server version, or is it a fact already, that no more Windows past 9.16.x? there were discussions starting here https://lists.isc.org/pipermail/bind-users/2021-April/104506.html further in may and june -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) -- 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: test - ignore
On 26 Jan 2022, at 17.14, Matus UHLAR - fantomas wrote: Altering the body or headers at all (whch lists do) will often break the hashing. For this reason, most recent versions of mailman have an option to rewrite your mail from: On 26.01.22 17:30, Sten Carlsen wrote: When the dkim is set up, you can select which parts of the header you want to include in the signature. this is not possible for body: modification of body (which this list does) will always break DKIM signatures. modifying list of headers to sign should be done carefully, to avoid either breaking and faking. I have selected a smaller part of the headers for my signature, so does this go through? since domain s-carlsen.dk don't have dmarc policy, mailman does not care and leaves dkim as is (broken) as described below. ...but only in the event you have a restrictive DMARC policy. this explains why both your and Benny's mail did fail here, while Eduard's did not - that one was signed by mailman because of his domains' restrictive policy. however, this discussion should be probably closed as it's not anymore related to this mailing list operatiorns. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself. ___ 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: test - ignore
On Jan 25, 2022, at 8:50 AM, Benny Pedersen wrote: Authentication-Results: lists.isc.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z On 25.01.22 12:25, Dan Mahoney wrote: The headers you cite are lying to you. :) The message passed DKIM on the way IN to lists.isc.org (the dedicated vm that runs our lists), but then, when the message got to the mailman python scripts and then shot back out via the MTA, they had an altered body and no longer passed, and the header was rewritten to say "fail". (This is visible from the logging on the servers, but nowhere else). there were multiple headers when that mail came here: Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=isc.org header.i=@isc.org header.b="q/vOEba5"; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=isc.org header.i=@isc.org header.b="ozeUkO/Z"; dkim-atps=neutral Authentication-Results: lists.isc.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isc.org header.i=@isc.org header.b=q/vOEba5; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isc.org header.i=@isc.org header.b=ozeUkO/Z obviously when the mail came to list, DKIM was fine, not so after it left (thanks to list signature) will my dkim fail aswell ? it did... Altering the body or headers at all (whch lists do) will often break the hashing. For this reason, most recent versions of mailman have an option to rewrite your mail from: [...] ...but only in the event you have a restrictive DMARC policy. this explains why both your and Benny's mail did fail here, while Eduard's did not - that one was signed by mailman because of his domains' restrictive policy. I missed this part before. I've argued that it should be possible to do so for *any* dmarc policy, even p=none, but that option is not present in mailman 3, at least. I agree. spam filter is something that can use dkim fail and should not be ignored. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. ___ 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: zone forwarding
On 17.01.22 10:46, ONRUBIA AVILES Carlos (CCS/MST) wrote:
Maybe someone can help me with the following problem:
My name server is authoritative with the following domain "toto.be":
zone "toto.be." {
type master;
file "/etc/masterdns.db";
But I would like that a subdomain "titi.toto.be" is not searched in my
masterdns.db file but via the normal process via internet.
I have tried to 2 solutions but it do not work:
1. Adding a forward for this subdomain:
zone "titi.toto.be." {
type forward;
forwarders {1.2.3.4; 5.6.7.8;}; (ip's from dsn cache servers)
forward only;
};
* Seems not to work. Not possible to add a subdomain forwarding?
it is possible, but will only work for recursive clients of your DNS server.
1. Using directly the cache servers as NS:
Cache.proximus.be. INA 1.2.3.4
Cache.proximus.be. INA 5.6.7.8
Titi.toto.be. INNS cache.proximus.be.
this should work properly.
* Not always working as if "titi.toto.be" is not at this moment in the
cache, the cache will answer SERVFAIL and not do the recursion. (I
guess the query via this method is done with flag "Recursion Desired"
set to false)
this also requires forwarding to be allowed from your IP address on the
server you are querying.
but, any recursive server should be able to query your server for Titi.toto.be
and then query 1.2.3.4 or 5.6.7.8
So my question is: Is it possible to configure what I am trying to do?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Despite the cost of living, have you noticed how popular it remains?
___
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: Failing DNS Server Diagnostic Help Requested
On 13.01.22 14:29, Tim Daneliuk via bind-users wrote: Environment: Master/Slave with Split Horizon both on FreeBSD-STABLE Bind 9.16.24_1 Master out in a cloud server Slave on a physical server with a static IP on Comcast Business Problem: After years of stable behavior, Slave intermittently not resolving addresses a few months ago, and then completely stopped working yesterday. We also noticed that the Slave will not update its files upon notify from the Master. Action Taken: Replaced Slave with a clone of the Master instance. That new Master does properly resolve names inside our zone, whether the requestor is on our LAN our one of our trusted servers out on the internet that are allowed to see internal names. HOWEVER, that new master instance will not resolve names in zones other than ours. We're working around this by forwarding these failed lookups to our original master - that is working fine. So, we have two masters with the same configuration and tables, but one resolves outside names and one does not. We've tried disabling DNSSEC validation and opening up our firewalls and got nowhere. When the lookups outside our zone fail, we see this: 13-Jan-2022 14:28:09.702 resolver: notice: DNS format error from 192.203.230.10#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.702 lame-servers: info: FORMERR resolving './NS/IN': 192.203.230.10#53 13-Jan-2022 14:28:09.721 resolver: notice: DNS format error from 192.36.148.17#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.721 lame-servers: info: FORMERR resolving './NS/IN': 192.36.148.17#53 13-Jan-2022 14:28:09.741 resolver: notice: DNS format error from 193.0.14.129#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.741 lame-servers: info: FORMERR resolving './NS/IN': 193.0.14.129#53 13-Jan-2022 14:28:09.763 resolver: notice: DNS format error from 199.7.91.13#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.763 lame-servers: info: FORMERR resolving './NS/IN': 199.7.91.13#53 13-Jan-2022 14:28:09.781 resolver: notice: DNS format error from 202.12.27.33#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.781 lame-servers: info: FORMERR resolving './NS/IN': 202.12.27.33#53 13-Jan-2022 14:28:09.801 resolver: notice: DNS format error from 199.7.83.42#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.801 lame-servers: info: FORMERR resolving './NS/IN': 199.7.83.42#53 13-Jan-2022 14:28:09.820 resolver: notice: DNS format error from 192.58.128.30#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.820 lame-servers: info: FORMERR resolving './NS/IN': 192.58.128.30#53 13-Jan-2022 14:28:09.837 resolver: notice: DNS format error from 198.41.0.4#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.837 lame-servers: info: FORMERR resolving './NS/IN': 198.41.0.4#53 13-Jan-2022 14:28:09.855 resolver: notice: DNS format error from 198.97.190.53#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.855 lame-servers: info: FORMERR resolving './NS/IN': 198.97.190.53#53 13-Jan-2022 14:28:09.875 resolver: notice: DNS format error from 192.5.5.241#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.875 lame-servers: info: FORMERR resolving './NS/IN': 192.5.5.241#53 13-Jan-2022 14:28:09.893 resolver: notice: DNS format error from 192.112.36.4#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.893 lame-servers: info: FORMERR resolving './NS/IN': 192.112.36.4#53 13-Jan-2022 14:28:09.921 resolver: notice: DNS format error from 199.9.14.201#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.921 lame-servers: info: FORMERR resolving './NS/IN': 199.9.14.201#53 13-Jan-2022 14:28:09.937 resolver: notice: DNS format error from 192.33.4.12#53 resolving ./NS for : non-improving referral 13-Jan-2022 14:28:09.937 lame-servers: info: FORMERR resolving './NS/IN': 192.33.4.12#53 13-Jan-2022 14:28:09.938 resolver: info: resolver priming query complete So ... could this be Comcast munging about in the DNS traffic? looks like exactly it. Other suggestions of where to look appreciated as well ... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux - It's now safe to turn on your computer. Linux - Teraz mozete pocitac bez obav zapnut. ___ Please visit https://lists.isc.org/mailman/lis
Re: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?
On 1/3/22 12:15 AM, Borja Marcos wrote: If you separate the roles it is much simpler to implement an effective access control. On 03.01.22 10:35, Grant Taylor via bind-users wrote: The problem I have with separating recursive and authoritative servers has to do with internal LANs and things like Microsoft Active Directory on non-globally-recognized domains. In short, how do you get a /purely/ /recursive/ server to know that internal-corp-lan.example (or any domain not in the global DNS hierarchy) is served by some other /purely/ /authoritative/ DNS server inside the company? you configure your recursive server with internal-corp-lan.example as type forward or static-stub pointing to your authoritative server. however, the "purely recursive" and "purely authoritative" split is not designed to cover domains like "internal-corp-lan.example" but "example.com" that has to be seen from the world clients. I feel like anything you do to the /purely/ /recursive/ DNS server to get it to know that it needs to route based on the DNS domain information slides away from the /purely/ /recursive/ role to somewhat /mixed/ /recursive/ & /authoritative/ role. This is to prevent recursive servers from providing domains to the public. in these cases I recommend setup purely authoritative servers for "example.com" to be accessible from the internet and "purely recursive" server accessible from your LAN, even if it would fetch "example.com" domain from your public authoritative servers. Just don't point NS record for "example.com" to this server as it's designes as internal recursive server. This niche role is the one nagging thing that I have that prevents me from supporting and proselytizing the role separation anywhere and everywhere. -- I've been looking for, but have not yet found, what I consider to be a good method that maintains strict separation of roles in this niche use case. Note: I'm completely on board with the separate roles for public / Internet facing servers. then, you should understand the need for separation of roles well. just the "recursive only" and "authoritative only" have a bit different meaning I tried to explain above. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ 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: transfer-source / notify-source warnings if a port is specified
On 29.12.21 18:58, Duncan wrote: Is there any option to suppress warnings if using transfer-source / notify-source specifying ports ? yes, don't specify source port. /etc/bind/named.conf:90: 'notify-source': specifying a port is not recommended /etc/bind/named.conf:91: 'notify-source-v6': specifying a port is not recommended /etc/bind/named.conf:88: 'transfer-source': specifying a port is not recommended /etc/bind/named.conf:89: 'transfer-source-v6': specifying a port is not recommended I know that this is NOT recommended, just looking for an option to suppress these warnings. what's the reason for specifying source port for zone transfers? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. There's a long-standing bug relating to the x86 architecture that allows you to install Windows. -- Matthew D. Fuller ___ 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: Strange named freezing
On 27.12.21 17:04, Nikita Druba wrote: More, than enough. During last freeze server has ~30Gb free RAM and ~ 2-3% CPU load and more than 200Gb free storage space for this jail. DC jail dont have any resources limitations. Its very strange, because during using previously DC in the similar jail on this server I dont have this trouble. you don't know what entrypy is, right? on linux do: # cat /proc/sys/kernel/random/entropy_avail 3940 if this number gets to 0, you'll have problem with using /dev/random (which is a blocking device) that leeds to problems like you have described. using /dev/urandom instead should help. there are daemons like haveged that can help you provide entropy. some HW random number generators provide entropy source. 27.12.2021 11:07, Ondřej Surý пишет: Does the jail have enough entropy? That would be my first guess… On 13. 12. 2021, at 7:18, Nikita Druba wrote: What can be wrong here? How I can more localize the problem? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot. ___ 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: Millions of './ANY/IN' queries denied
You don't understand what kind of blacklist I want; I want to blacklist the domain name being asked for, so I don't answer for it. I'm not looking to blacklist forged IP addresses of requestors (since we all know criminals don't use their own identities; they use the identities of innocent bystanders). Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not a rootserver, and never will be. these answers are minimal, so the problem is made as small as possible. Reindl Harald writes: Am 16.12.21 um 14:22 schrieb Andrew P.: AGAIN: you don't gain anything by not responding on a UDP protocol because the client can't distinct no response and packet loss On 16.12.21 13:56, Andrew P. wrote: AGAIN, the criminal DDoS attacker who's creating these forged requests isn't looking for replies to themselves; they're looking to abuse some poor victim. And the victim can't make the attacker shut up. I use fail2ban to block these, so while a few packets always pass, the rest gets blocked. so you *increase* the load by retries on the client No, the attacker is going to send their packets as often as they feel like it regardless of whether I answer, and they won't know if the load on the victim is sufficient to crush them (or if I am participating), since the attacker isn't receiving the attack. They won't speed up on me just because I refuse to participate in their ugly little games because they won't know I'm not playing along (at least until they decide to attack _me_ instead of someone else). don't get me wrong but you need to understand the implications of what you are doing - for DOS attacks "Response Rate Limiting" was invented and for non-DOS requests there isn't any valid reason to take action Please tell me what non-DOS requests would be asking _my_ name server to dump the root domain. I'm not running a caching-only public nameserver (such as an ISP might run for their customers), so _no_ _one_ should be asking my nameserver for the entire root domain. Even webcrawlers don't need to harrass non-root-nameservers for root domain information. Note I haven't done anything yet; I'm asking if there _is_ a way to do it presently implemented in Bind. none I know so far. I'd be glad if someone told me there's better way and what it is. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have. ___ 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: insecurity proof failed for a domain
On 13.12.21 08:18, John Thurston wrote:
If you update your resolver to 9.16, I think you can do exactly what
you want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
On 14.12.21 16:58, Matus UHLAR - fantomas wrote:
thanks, this helped.
I assume I need to put "local" into validate-except {}.
This should not be a problem since .local is reserved.
I guess .local should have negative trust anchor in root zone.
looks like I possibly could achieve the same with bind 9.11 by using
rndc nta local
to "temporarily" disable checking of "local" domain.
BIND would periodically re-check (and fail) and prolong the nta anchor
apparently forefer.
the "validate-except" is however cleaner solution.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."
___
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: insecurity proof failed for a domain
On 13.12.21 08:18, John Thurston wrote:
If you update your resolver to 9.16, I think you can do exactly what
you want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
thanks, this helped.
I assume I need to put "local" into validate-except {}.
This should not be a problem since .local is reserved.
I guess .local should have negative trust anchor in root zone.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.
___
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
insecurity proof failed for a domain
Hello,
I need to internaly forward domain to different nameserver:
zone "x.local" {
type forward;
forward only;
forwarders {
100.1.2.3;
};
};
when I do this with bind 9.11 (debian 10), I get these messages:
Dec 13 14:26:55 mail named[13112]: validating x.local/A: got insecure
response; parent indicates it should be secure
Dec 13 14:26:55 mail named[13112]: insecurity proof failed resolving
'x.local/ANY/IN': 100.1.2.3#53
Dec 13 14:26:55 mail named[13112]: validating x.local/NS: got insecure
response; parent indicates it should be secure
Dec 13 14:26:55 mail named[13112]: validating x.local/SOA: got insecure
response; parent indicates it should be secure
looks like I could avoig this by disabling dnssec but is there any way to
disable this checking only for domain "local" or "x.local"?
I have tried to create empty "local" domain but then I only received empty
responses for any requests.
(I know .local is for mdns, but I can't do anything with that).
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
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: BIND caching of nxdomain responses
On 22.10.21 09:57, Dan Hanks wrote: >As I understand RFC 2308, when receiving an NXDOMAIN response, and when >deciding how long to cache that NXDOMAIN response, a resolver should use >whichever value is lower of the SOA TTL, and the SOA.minimum value as the >length of time to cache the NXDOMAIN. > >I have a situation where I am seeing different behavior from that in BIND. >Given the following SOA record: > >azure.mongodb.net. 900 IN SOA ns-1430.awsdns-50.org. >awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60 > >I am finding that BIND (9.11.x) is caching the NXDOMAIN response for 900s >(SOA TTL), instead of the expected 60s (SOA.minimum). > >I have noticed that many auth servers out there will drop the SOA TTL to >match the SOA.minimum value when attaching the SOA record to an NXDOMAIN >response. Is BIND expecting this to happen, and just opting to use the SOA >TTL value (and not the SOA.minimum value if they disagree)? On Fri, Oct 22, 2021 at 10:29 AM Matus UHLAR - fantomas wrote: are you authoritative server for azure.mongodb.net? if not, BIND will use cache time that came from authoritative server adn won't parse the SOA itself. On 22.10.21 10:56, Dan Hanks wrote: I am not authoritative, I'm just making recursive queries against this domain. When you say, "BIND will use cache time that came from authoritative server", what 'cache time' are you referring to? Are you referring to the values in the SOA record included in the AUTHORITY section of the NXDOMAIN response? I assume that BIND will keep the TTL as it was received from upstream servers (of course, local TTL restrictions may override it) If the upstream sends SOA record with TTL 900 second, BIND will keep it at 900 seconds, no matter what the SOA minimum says. if the TTL returned above is 900 seconds, BIND will return 900 and cache the record for up to 900 seconds. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer. ___ 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: BIND caching of nxdomain responses
On 22.10.21 09:57, Dan Hanks wrote: As I understand RFC 2308, when receiving an NXDOMAIN response, and when deciding how long to cache that NXDOMAIN response, a resolver should use whichever value is lower of the SOA TTL, and the SOA.minimum value as the length of time to cache the NXDOMAIN. I have a situation where I am seeing different behavior from that in BIND. Given the following SOA record: azure.mongodb.net. 900 IN SOA ns-1430.awsdns-50.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60 I am finding that BIND (9.11.x) is caching the NXDOMAIN response for 900s (SOA TTL), instead of the expected 60s (SOA.minimum). I have noticed that many auth servers out there will drop the SOA TTL to match the SOA.minimum value when attaching the SOA record to an NXDOMAIN response. Is BIND expecting this to happen, and just opting to use the SOA TTL value (and not the SOA.minimum value if they disagree)? are you authoritative server for azure.mongodb.net? if not, BIND will use cache time that came from authoritative server adn won't parse the SOA itself. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question! ___ 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: bind9 forwarder query
On 23.09.21 06:18, Sonal Pahuja wrote: We have configured a forward zone in bind9 for e164.arpa and in forwarders we are giving 2 IPs. Just wanted to know the mechanism/routing/ Load balancing policy by which bind9 forwarding to different IPs. I can see sometimes it routes to same IP always, sometime it forward it in round robin way. bind keeps track of servers that responds fastest and periodically rechecks the rest. it's called SRTT algorithm, web search should give some explanations. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Nothing is fool-proof to a talented fool. ___ 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: Getting the name of responding server(s)
On Tue, Sep 07, 2021 at 10:48:57AM -0400, Matthew Pounsett wrote a message of 32 lines which said: Yeah, you can pretty reliably get the answer in one or two steps by requesting the NS set for the FQDN. You'll either get your answer, or get an SOA with the name of the enclosing zone. Second lookup gets you the NS set for the enclosing zone. In message , Stephane Bortzmeyer wrote: Indeed (unless you find a broken resolver that fail to send the SOA). On 09.09.21 03:20, Ronald F. Guilmette wrote: I don't want and don't need SOA records. I want and need only the relevant NS records. server in some cases send the SOA. I was thinking of another issue: if the goal of the OP is to find which domain names are on the same authoritative name servers... Thank you but no, that was not among my goals. I just want the names of the final and actual name servers that would / should respond to the given query. dig +trace finds those. Note that some domains can be horribly broken and different nameservers can send different NS, or no NS at all but SOA. asking the NS may not be sufficient, if a name server is known by several names (for instance, a.nic.sex and a.nic.sucks are the same machine). So, the OP may have to do a resolution of nameservers' names into IP addresses, as well. Thank you. I am well and truly aware of that fact that multiple name server names may resolve to some single common IP address. Fortunately, for what I am doing, this fact is not of any relevance. what exactly is your goal? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. REALITY.SYS corrupted. Press any key to reboot Universe. ___ 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: Does BIND supports ANAME RR
On 09.08.21 13:55, Klaus Darilion via bind-users wrote: >But honestly SVCB will not solve the ANAME problem. I will take years > until all resolvers/client would support SVCB whereas ANAME would be > implemented in the authoritative name server resolving on authoritative server could in fact help, and wouldn't need protocol change at all, but the problem above is crucial (what would you do in case of failure? refuse whole zone?) On 09.08.21 14:37, Klaus Darilion via bind-users wrote: Resolving is done when there is an incoming query, not on zone loading. So if the auth's resolver (either a full blown resolver or a stub resolver which forwards to another resolver) fails to resolve I would just forward this error to the client's resolver. This would not change the fact that you are asking authoritative server to resolve record which is by definition not the job of authoritative server. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good. ___ 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: Does BIND supports ANAME RR
On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote: > I need the help in figuring out whether BIND supports ANAME ? If yes, > then from which version on wards ? No, it doesn't. The effort to standardize ANAME stalled, and I doubt it'll be coming back. The new HTTPS and SVCB records look like a better approach anyway. BIND will have support for those pretty soon. On 09.08.21 13:55, Klaus Darilion via bind-users wrote: But honestly SVCB will not solve the ANAME problem. I will take years until all resolvers/client would support SVCB whereas ANAME would be implemented in the authoritative name server recursive - authoritative server is not there to resolve remote hostnames, if it doesn't provide recursion. (well, it COULD try to resolve just as it resolves NS IPS for sending notifies, but that's different). resolving on authoritative server could in fact help, and wouldn't need protocol change at all, but the problem above is crucial (what would you do in case of failure? refuse whole zone?) and hence would work for every client/resolver as client/resolver never sees the ANAME but only the A/AAAA record. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I drive way too fast to worry about cholesterol. ___ 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: Odd A record in our hosts zone file
On 25.06.21 18:29, Bruce Johnson wrote: Thank you…this is very useful information; I thought TTL could only be specified on a per-zone basis, not per-host. not even per-host. Different RR types for the same host can have different TTL. mail1m IN A xxx.xxx.xxx.52; dhbex1 mail1m IN A xxx.xxx.xxx.54; dhbex2 mail1d IN TXT "v=spf1 a -all" mail1h IN MX 0 mail etc. Only same RR types MUST have same value so e.g.: mail1m IN A xxx.xxx.xxx.52; dhbex1 mail2m IN A xxx.xxx.xxx.54; dhbex2 would be incorrect and server will choose one of those to implement for all RRs (see rfc 2182 section 5.2) -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... ___ 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: Reverse Lookup / PTR record
On 21.06.21 09:41, techli...@phpcoderusa.com wrote: I am configuring a home office PHP webserver on my cable company's business connection that allows for servers. My cable company provides the reverse lookup / PTR record. Given that, I'm thinking I need to provide only the zone file, no reverse lookup. if your ISP provides reverse lookup, you don't need reverse zone file at all. Any thoughts are much appreciated. what is your question? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "The box said 'Requires Windows 95 or better', so I bought a Macintosh". ___ 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: Need Help with BIND9
On 15.06.21 09:14, Lyle Giese wrote: I think I stumbled upon a problem with the zone records for keiththewebguy.com. It could be the root issue you are having. If I run dig ns +trace keiththewebguy.com I got the following for the last record from your name servers: ns1.keiththewebguy.com. 86400 IN A 98.191.108.149 keiththewebguy.com. 86400 IN NS ns1. keiththewebguy.com. 86400 IN NS ns2. this is the problem. OP's NS records point to nonexistent hosts, and these are authoritative, so after each nameserver fetches them, it uses them and fails. Most probably it's the "ns1" and "ns2" in zone end with "." which means that current $ORIGIN (apparently keiththewebguy.com) is not appended to them. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Depression is merely anger without enthusiasm. ___ 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: Need Help with BIND9
On 11.06.21 18:19, Sten Carlsen wrote: From my place I resolve both to: 98.191.108.149 keiththewebguy.com. does not actually have the two nameservers required though that is not the problem. (ns1 and ns2 have same IP) BIND seems to work ok but your local settings probably don't point your hosts to the right NS. On 14.06.21 14:26, techli...@phpcoderusa.com wrote: I do have the same IP in both "glue" records. GoDaddy calls them host records. those might be different records, haven't checked godaddy's dictionary. Server was probably off. Thank you for your help!! it's apparently down again. some registrars provide you with their own nameservers that don't go down, why don't you use those? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux IS user friendly, it's just selective who its friends are... ___ 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: Disable limitation
On 14.06.21 05:37, Roee Mayerowicz wrote: I'm trying to use BIND9 as a recursive DNS server for my internal crawler. After a few hundred queries, my queries have started to get dropped. What configuration or requirements is needed for "unleash the beast"? none, it should work by default. Is there anything in logs? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 42.7 percent of all statistics are made up on the spot. ___ 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: Need Help with BIND9
On 11.06.21 18:19, Sten Carlsen wrote: From my place I resolve both to: 98.191.108.149 keiththewebguy.com. does not actually have the two nameservers required though that is not the problem. (ns1 and ns2 have same IP) BIND seems to work ok but your local settings probably don't point your hosts to the right NS. looks like you have registered domain on two servers, but failed to provided the servers' IPs. "glue records" is what your domain needs KEITHTHEWEBGUY.COM. 172800 IN NS NS1.KEITHTHEWEBGUY.COM. KEITHTHEWEBGUY.COM. 172800 IN NS ns2.KEITHTHEWEBGUY.COM. CK0POJMG874LJREF7EFN8430QVIT8BSM.COM. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.COM. 86400 IN RRSIG NSEC3 8 2 86400 20210617042404 20210610031404 54714 com. X4G7euDX4ox5altSUvf+DfLyijD3A+97OxtkehYEGpUotSvAXXYdriAO rWhfqctrjb7pjNyMApY2lbkuHeqXHACUq26uunHKCoFbLkQ1l56mK2sW mX8qmzImJOaTysXQlH9pJggtlsjvT5+dA+wojtVxlQc7+uq2245G0q0i Nf8JseTw9JzSK66G4IOzl8Z9iQ6KXCKhIKFT4kQXeZP1rA== AG1GER7HG6VFFKTUSO2FO8IDL76AC4B7.COM. 86400 IN NSEC3 1 1 0 - AG1HFAOR0D4AHNGRNHE5M02CMA12RRD4 NS DS RRSIG AG1GER7HG6VFFKTUSO2FO8IDL76AC4B7.COM. 86400 IN RRSIG NSEC3 8 2 86400 20210618044614 20210611033614 54714 com. Z0rbk8cLOj6ZOZRiW74uGgP5rPtdtr0gtKXhxgyVBcmBUjZ2WZcskJ5H YYK6D9KZJYhEvIdvIF+AVBDbyY/7BaRegq44a3Z0pSNlD+nk2fJMqlbA sj+9FkyADAp20dojAXPP+RxoCo2e9hz9XW/S0OKrVxv5NtXqvBOUnahr 7hQOtJCD7uJeb2XLNAHGdOeleIJQhn3E/1CGApoSTxJTaw== couldn't get address for 'NS1.KEITHTHEWEBGUY.COM': failure couldn't get address for 'ns2.KEITHTHEWEBGUY.COM': failure dig: couldn't get address for 'NS1.KEITHTHEWEBGUY.COM': no more -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95 ___ 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: [UNSOLVED] Re: Strange DNS behaviour
On 09.05.21 14:35, Xavier Humbert via bind-users wrote: But on one machine, it fails : [xavier@feanor ~]$ dig @numenor dns.google.com +trace are you aware that +trace sends queries across the servers from root to leaf, it doesn't go through the server numenor? 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. Sorry, typed too quickly. Problem stands. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux is like a teepee: no Windows, no Gates and an apache inside... ___ 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: How to return REFUSED
On 06.05.21 18:41, Axel Rau wrote: This NS has some other clients in the DMZ LAN, so I need Views. you need multiple views if you are going to provide multiple versions of the same zones, different forwardings for different domains or alike. Not just if you have other clients. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Linux is like a teepee: no Windows, no Gates and an apache inside... ___ 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: How to return REFUSED
On 05.05.21 21:09, Axel Rau wrote:
allow-query { any; };
allow-query-cache { recursive-users; };
allow-recursion { recursive-users; };
How can I make sure that none recursive-users get a REFUSED if query is
recursive?
I thought this is the default...
PS: I want to minimize the responses to this amplification attack:
19:05:18.703238 185.230.55.130.30120 > 91.216.35.71.53: [no udp cksum] 1+
RRSIG? pizzaseo.com.(30) (ttl 249, id 33043, len 58)
19:05:18.703568 91.216.35.71.53 > 185.230.55.130.30120: [udp sum ok] 1- q:
RRSIG? pizzaseo.com. 0/13/14 ns: com. NS j.gtld-servers.net., com. NS
m.gtld-servers.net., com. NS c.gtld-servers.net., com. NS b.gtld-servers.net.,
com. NS d.gtld-servers.net., com. NS e.gtld-servers.net., com. NS
l.gtld-servers.net., com. NS f.gtld-servers.net., com. NS h.gtld-servers.net.,
com. NS i.gtld-servers.net., com. NS a.gtld-servers.net., com. NS
k.gtld-servers.net., com. NS g.gtld-servers.net. ar: m.gtld-servers.net. A
192.55.83.30, l.gtld-servers.net. A 192.41.162.30, k.gtld-servers.net. A
192.52.178.30, j.gtld-servers.net. A 192.48.79.30, i.gtld-servers.net. A
192.43.172.30, h.gtld-servers.net. A 192.54.112.30, g.gtld-servers.net. A
192.42.93.30, f.gtld-servers.net. A 192.35.51.30, e.gtld-servers.net. A
192.12.94.30, d.gtld-servers.net. A 192.31.80.30, c.gtld-servers.net. A
192.26.92.30, b.gtld-servers.net. A 192.33.14.30, a.gtld-servers.net. A
192.5.6.30, m.gtld-servers.net. 2001:501:b1f9:
:30(490) (ttl 63, id 11754, len 518)
... exactly because of this reason.
Which named version do you run?
do you use views?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
2B|!2B, that's a question!
___
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: Need Help With Setting up a Recursive Nameserver
On 30.04.21 17:50, Sainik Biswas via bind-users wrote: I need some help setting up a recursive nameserver for my internal network using BIND 9. The recursive name server is not resolving any domains. Error Log [resolver.log] 2021-04-30T11:58:17.784Z notice: DNS format error from 198.41.0.4#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.788Z notice: DNS format error from 193.0.14.129#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.792Z notice: DNS format error from 192.36.148.17#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.796Z notice: DNS format error from 192.33.4.12#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.800Z notice: DNS format error from 192.58.128.30#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.804Z notice: DNS format error from 202.12.27.33#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.808Z notice: DNS format error from 198.97.190.53#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.808Z notice: DNS format error from 199.7.91.13#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.816Z notice: DNS format error from 199.9.14.201#53 resolving ./NS for : non-improving referral 2021-04-30T11:58:17.816Z info: resolver priming query complete My ISP most probably uses some kind of transparent DNS proxy. I have come to that conclusion based on running the test at dnsleaktest.com. It does not matter which DNS I set in my laptop or desktop, the DNS IP always shows up as the ISP's DNS [203.171.240.10, 203.171.240.11]. The only way I could bypass this was by using DNSCrypt Proxy. Is it possible that my ISP is preventing the root nameservers from resolving correctly which is preventing my caching nameserver from working correctly? It's most probably the reason. Ask your ISP. Or maybe I have incorrectly configured something? Can anyone help me figure out what exactly is the problem? your ISP probably -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. M$ Win's are shit, do not use it ! ___ 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: NXDOMAIN processing
On 26.04.21 20:45, bamberg2000 via bind-users wrote:
BIND 9.11.5, I forward the request ("forward zone" or global "forward
first") to another server and I get NXDOMAIN. Is it possible to process
NXDOMAIN other than "redirect zone"? I just want to repeat the request to
another forwarder.
It's not possible.
the NXDOMAIN response means that the rquested domain definitely does not
exist, so there's no logical need to verify this from another source.
maybe if you explained us what you're trying to do, we could give you better
advice.
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Quantum mechanics: The dreams stuff is made of.
___
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: Name server delegation
On 26.04.21 16:07, John W. Blue via bind-users wrote: Since "" is a subzone inside of the example.com zone the answer is yes, it can be delegated. however, the delegation must be done on example.com server (1.1.1.1) local forwarding resolution of domains example.com and .example.com to different server is different issue. From: Karol Nowicki via bind-users Sent: Monday, April 26, 2021 10:24 AM To: bind-users@lists.isc.org Subject: Name server delegation Its possible to delegate tld domain example.com to 1.1.1.1 name server and .example.com to 2.2.2.2 name server ? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Eagles may soar, but weasels don't get sucked into jet engines. ___ 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: Re: Does bind9 support adding acl and view through commands, not by updating config file?
On 15.04.21 20:53, Zhengyu Pan wrote: The "intelligent" means that dns server return the corresponding A record IP address according to the source IP address of the tenants. My dns server is an Authoritative dns server. It hosts the zones of different tenants. do you mean, the same domains with different content, depending on clients' IPs? That's common multiple-view setup (nothing special or intelligent). I need to update config file name.conf frequently Because The views and ACLS are added frequently. Why? Do you have that many clients constantly with changing IPs? Maybe they could use local DNS server talking to your DNS server using TSIG, and instead of IPs you'd define TSIG keys. So i want to know whether have commands or API to add acl and view like the command "rndc addacl" or "rndc addview"? I'm afraid for now there's no way to make this via rndc. You'll have to generate named config per-client. Updating config file frequently may affect other zones in this dns server. I don't understand how/why it should affect other zones. At 2021-04-15 15:08:26, "Matus UHLAR - fantomas" wrote: On 15.04.21 15:35, Zhengyu Pan wrote: I want to implement intelligent DNS through bind9. I need to add a custom line(IP address ranges) to bind9 using acl and view when add a user. Because when add a tenant, i need to define a new acl and view. I don't want to update named.conf config file frequently. what is supposed to be intelligent there? I mean, why? are you going to provide recursive service to someone who pays for that? Does bind9 support adding acl and view through commands or API, not by updating config file? like the command "rndc addacl" or "rndc addview". I don't think so, looks a bit too complicated. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. - Have you got anything without Spam in it? - Well, there's Spam egg sausage and Spam, that's not got much Spam in it. ___ 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: Does bind9 support adding acl and view through commands, not by updating config file?
On 15.04.21 15:35, Zhengyu Pan wrote: I want to implement intelligent DNS through bind9. I need to add a custom line(IP address ranges) to bind9 using acl and view when add a user. Because when add a tenant, i need to define a new acl and view. I don't want to update named.conf config file frequently. what is supposed to be intelligent there? I mean, why? are you going to provide recursive service to someone who pays for that? Does bind9 support adding acl and view through commands or API, not by updating config file? like the command "rndc addacl" or "rndc addview". I don't think so, looks a bit too complicated. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Save the whales. Collect the whole set. ___ 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
