Re: DNSSEC and forwarding
Duchscher, Dave J via bind-users wrote: > We have an internal DNS server that we would like to forward its > outgoing queries to a main DNS server that connects to the outside world > and is doing DNSSEC validation. The problem is that the DNSSEC > validation doesn't work for queries from the internal DNS server. > Doing DNSSEC validation on the internal DNS server that is forwarding to > the main DNS server has been problematic with some domain failing > intermittently and others just not working at all. Is there a way to > allow the main DNS server handle DNSSEC validation? In this situation, with multiple tiers of caches, if you want DNSSEC validation, you should turn it on everywhere you can. It sounds to me like your outer server has somehow got data in its cache that can't be validated by the inner server (though I'm not entirely sure how that might happen). If they both validate then I would expect the problems to go away. -- Tony Finch(he/they) Cambridge, England Rockall, Malin, Hebrides: North or northeast 4 to 6, occasionally 7 at first. Moderate or rough. Wintry showers. Good, occasionally poor. -- 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
DNSSEC and forwarding
We have an internal DNS server that we would like to forward its outgoing
queries to a main DNS server that connects to the outside world and is doing
DNSSEC validation. The problem is that the DNSSEC validation doesn't work for
queries from the internal DNS server. Doing DNSSEC validation on the internal
DNS server that is forwarding to the main DNS server has been problematic with
some domain failing intermittently and others just not working at all. Is there
a way to allow the main DNS server handle DNSSEC validation?
Here is my test setup on my laptop:
First named config running on port 1:
logging {
category default {
_default_log;
};
channel _default_log {
file "/var/log/named/named-1.log" versions 10 size 1m;
severity info;
print-time yes;
};
};
options {
directory "/var/named-1";
listen-on port 1 { any; };
allow-query { any; };
allow-recursion { any; };
allow-query-cache { any; };
dnssec-validation no;
forwarders {
127.0.0.1 port 11000;
};
forward only;
};
Second named config running on port 11000:
logging {
category default {
_default_log;
};
channel _default_log {
file "/var/log/named/named-2.log" versions 10 size 1m;
severity info;
print-time yes;
};
};
options {
directory "/var/named-2";
listen-on port 11000 { any; };
allow-query { any; };
allow-recursion { any; };
allow-query-cache { any; };
dnssec-validation auto;
};
--
Dave
--
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: Periodic SERVFAIL for TLD .BY
"servfail-ttl 0" doesn't help. вт, 29 мар. 2022 г. в 18:16, Ondřej Surý : > The .by domain is kind of bonkers… > > Step 1: get nameservers for 103.by: > > $ dig +noall +authority IN NS 103.by. @a.root-servers.net > by. 172800 IN NS dns1.tld.becloudby.com. > by. 172800 IN NS dns2.tld.becloudby.com. > by. 172800 IN NS dns3.tld.becloudby.com. > by. 172800 IN NS dns4.tld.becloudby.com. > by. 172800 IN NS dns5.tld.becloudby.com. > > Step 2: get nameservers for becloudy.com: > > $ dig +noall +authority IN NS becloudby.com. @a.root-servers.net > com.172800 IN NS e.gtld-servers.net. > com.172800 IN NS b.gtld-servers.net. > […] > > $ dig +noall +authority IN NS becloudby.com. @a.gtld-servers.net. > becloudby.com. 172800 IN NS u1.hoster.by. > becloudby.com. 172800 IN NS u2.hoster.by. > > Step 3: get nameservers for hoster.by > > $ dig +noall +authority IN NS hoster.by. @a.root-servers.net > by. 172800 IN NS dns1.tld.becloudby.com. > by. 172800 IN NS dns2.tld.becloudby.com. > by. 172800 IN NS dns3.tld.becloudby.com. > by. 172800 IN NS dns4.tld.becloudby.com. > by. 172800 IN NS dns5.tld.becloudby.com. > > Step 4: get nameservers for becloudy.com: > > […] > > My guess is that it probably depends on the current state of the cache > whether `named` is able to break out of the loop using the existing data > or not. > > From the log, I can see that it’s hitting the SERVFAIL cache. > > You can disable the servfail caching with: > > ``servfail-ttl`` >This sets the number of seconds to cache a SERVFAIL response due to > DNSSEC >validation failure or other general server failure. If set to ``0``, >SERVFAIL caching is disabled. The SERVFAIL cache is not consulted if >a query has the CD (Checking Disabled) bit set; this allows a query >that failed due to DNSSEC validation to be retried without waiting >for the SERVFAIL TTL to expire. > >The maximum value is ``30`` seconds; any higher value is >silently reduced. The default is ``1`` second. > > And see if that helps. > > Ondrej > -- > Ondřej Surý (He/Him) > ond...@isc.org > > My working hours and your working hours may be different. Please do not > feel obligated to reply outside your normal working hours. > > > On 29. 3. 2022, at 16:02, Dzmitry Shykuts wrote: > > > > Hello! Can anybody help me with periodic and critical for me SERVFAIL? > Cannot determine the source of the problem. > > > > I have Debian 11.3 and BIND9 9.16.27 on it. There was no such problem > earlier. > > > > I do request: > > > > <<>> DiG 9.16.27-Debian <<>> 103.by +trace > > ;; global options: +cmd > > . 518377 IN NS e.root-servers.net. > > . 518377 IN NS a.root-servers.net. > > . 518377 IN NS h.root-servers.net. > > . 518377 IN NS k.root-servers.net. > > . 518377 IN NS b.root-servers.net. > > . 518377 IN NS i.root-servers.net. > > . 518377 IN NS j.root-servers.net. > > . 518377 IN NS d.root-servers.net. > > . 518377 IN NS c.root-servers.net. > > . 518377 IN NS m.root-servers.net. > > . 518377 IN NS f.root-servers.net. > > . 518377 IN NS g.root-servers.net. > > . 518377 IN NS l.root-servers.net. > > . 518377 IN RRSIG NS 8 0 518400 2022041105 2022032904 9799 . > keszTJZg3TCzY3s4UyinKYe7VwZGGf/8kHoWzJ2Ab3n4ctBt8gtleqC0 > UZqIIjc9Ez9srWGGeNn2gRUtB65QvL99oX5gD5VI6h1SY81OC0HcBx2c > 80SZJ0s9qpNmkDDcp4EUNlgoheDkBAtB3MsIRIVA6T746gBthcVKLHxC > rpOy7ELdgDtHwtq8jL5QIFae6QlIGuO95nflzk31VoL/yhCxvpzIXEfq > QJlJQf21YJtAtYnY7vJJwuDVT20y/cj5W7PNxSkNLMoukqUXOeH/w2yB > 0yNkwbKLBZUkyrE5tQmlq5AnScofbT7ffOYB9o9ug39DgCTcqSeNZDYX 0Gekmg== > > ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 3 ms > > > > by. 172800 IN NS dns5.tld.becloudby.com. > > by. 172800 IN NS dns2.tld.becloudby.com. > > by. 172800 IN NS dns3.tld.becloudby.com. > > by. 172800 IN NS dns4.tld.becloudby.com. > > by. 172800 IN NS dns1.tld.becloudby.com. > > by. 86400 IN DS 495 13 2 > 2D14284F8E47B53F839BD8068D438680B4B6C7A645769C9D89B47DF0 C5359B7B > > by. 86400 IN RRSIG DS 8 1 86400 2022041105 2022032904 9799 . > IAk+oEOmuQVbb8RyxB9ML/GOwnLIaQdi0XMD8Y7san2AIx2lXeEZp3AV > fNgYQfTnVrGyi3ylXNkVmQXnqDdrPK8iJu6mKvmaI40sQwv8xDyx5Fnz > VaNHcY4+J3fQwSp+TrFxQuAlW3g3CFaUVNLk20V/TQUycVA75c+3TrW4 > IQJ1aua0lDsG1JS7BigHryUH9Vy8nSyuikYOIiML0BTTTqFQN7yk4AiE > 3gbYMuCsMHQKfAIXpswc/i1eGEW7yi5USnQqza4P2YEDrUhSUps5N2u5 > /UwdS1BsmW17WZRbfDudeL4y471jwKhYgCCycGI1whtToDA452nvDJL2 it6mlg== > > couldn't get address for 'dns5.tld.becloudby.com': failure > > couldn't get address for 'dns2.tld.becloudby.com': failure > > couldn't get address for 'dns3.tld.becloudby.com': failure > > couldn't get address for
Expired secondary zone retry-interval?
Hi! I just experienced an outage where a zone is defined via catalogzone and the following is set: SOA Refresh 900 SOA Retry 300 SOA Expiry 3600 (i'm aware it's very short) Primary was intermittently unreachable and had wrong config for about 1.5h. According to logs the Secondary was retrying transfer every 7-8minutes as expected until the zone expired, after it expired it seems like it tried a couple times more then stopped trying for many hours. The only related config parameters i find are min-retry-time (default 5min) and max-retry-time (default 2 weeks) but there seems to be no mention if this is also related to the unreachability-cache for a certain master, or if this cache-time is even configurable. Now i wonder: Did it actually stop trying for many hours or was it retrying silently behind the scenes? If it did stop trying for many hours, how / where is this behavior defined (so i can learn to understand it) and can i cap it to retry failed zonetransfers at max X minute intervals if master is unreachable? 18:20:27 named: zone xx.yy/IN: expired 18:20:27 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 18:21:25 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 18:23:03 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 18:27:20 named: zone xx.yy/IN: refresh: retry limit for master aa.bb.cc.dd#53 exceeded (source 0.0.0.0#0) 18:34:53 named: zone xx.yy/IN: refresh: retry limit for master aa.bb.cc.dd#53 exceeded (source 0.0.0.0#0) 18:48:01 named: zone xx.yy/IN: refresh: retry limit for master aa.bb.cc.dd#53 exceeded (source 0.0.0.0#0) 18:50:19 named: zone xx.yy/IN: notify from aa.bb.cc.dd#54418: no serial 18:50:20 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 19:33:00 named: zone xx.yy/IN: notify from aa.bb.cc.dd#58236: no serial 19:33:00 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 19:59:42 named: zone xx.yy/IN: notify from aa.bb.cc.dd#50608: no serial 19:59:42 named: zone xx.yy/IN: refresh: skipping zone transfer as master aa.bb.cc.dd#53 (source 0.0.0.0#0) is unreachable (cached) 23:39:42 named: zone xx.yy/IN: sending notifies (serial 42) /Oskar -- 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 missing bind.keys
On Wed, Mar 30, 2022 at 12:16:05AM -0400, J Doe wrote: > I have a question about the bind.keys file and what happens when it is > not available. [...] > ** If I don't have bind.keys in my BIND directory but have: > dnssec-validation auto in my named.conf, is BIND automatically getting > the trust anchor and storing it in managed-keys.bind so that when my > recursive resolver does a lookup and performs DNSSEC validation, > validation works ? Or do I still need to download bind.keys from [1] ? There's a copy of bind.keys that's compiled directly in named. If the file isn't there, named will just use its own internal copy. The first time named starts up with 'dnssec-validation' set to 'auto', it fetches the current root key, validates it against its local copy (either from bind.keys or from its own built-in copy), and then keeps the key up to date according to the RFC 5011 protocol from then on. The recommendation to use bind.keys and not rely on the built-in version was based on some assumptions that are no longer true. First, `dnssec-validation auto` is now the default, so unless you disabled it on purpose, you've been validating and keeping the root key up to date since the first time you ran your server. Second, back in those days it was harder to get hold of regularly-updated packages for BIND, and scads of people were running outdated code. We were concerned that someone would be running an old version of named, the root key would change, and *then* they'd decide to turn validation on for the first time, and it wouldn't work. To smooth that out a bit, we added the bind.keys file to the release tarball, and when giving tutorials about turning on DNSSEC validation, we included a note that you should always check whether bind.keys needed to be updated. In today's world, I don't think it's inmportant anymore. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. -- 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
