RE: Can not query localhost
Hi. It was not oracle linux 9.16 but Bind 9.16. The problem seemed to be about broken dnssec validation, that's why commenting those entries solved. For now I'm not using dnssec, I will have to read about key rotation. If that is still a very manual process, I'll have to be quite confident before I mess with my servers. Thanks. David -Original Message- From: Mark Andrews Sent: 13 January 2023 22:48 To: David Carvalho Cc: bind-users@lists.isc.org Subject: Re: Can not query localhost Now you went from Oracle Linux 6 to Oracle linux 9.16 (b.t.w. no one keeps track of which BIND version ships which which random Linux distro, it is much better to report the BIND versions as well). In that time there has been a lot of change. Did you copy over just the local configuration changes or did you copy over everything? By local configuration changes I mean just the zone you added and any acls. Distros expect you to put local changes in isolated files so they can update defaults configurations without overwriting local config. Copying everything means that you are missing all those changes. > On 14 Jan 2023, at 03:48, David Carvalho via bind-users > wrote: > > > Ok, so apparently everything seems to be running fine. > > > I am not using dnsssec (dnssec-validation is auto ?!) and > "dnssec-enable yes" was considered obsolete by named-checkconfg, so it is > also commented. > I had to comment > > bindkeys-file "/etc/named.iscdlv.key"; Well what was in "/etc/named.iscdlv.key” ? I suspect it was grossly out of date. Anything that mentions DLV is out of date as that has been shutdown for years and is just returning a response that says there is no content here anymore. Also the Root’s DNSSEC keys rolled in 2017 and if it hasn’t been updated since before then the key is out of date. There should be nothing in there but public keys which are safe to publish. Commenting it out meant that you are now using the built in trust anchors. Defaults for DNSSEC have changed over time (validation is on by default) and using out of date trust anchors with newer versions of BIND will cause DNSSEC validation failures. > managed-keys-directory "/var/named/dynamic"; > > and everything worked. Still don't understand exactly why, I will > continue to investigate, but any feedback is welcome. Named logs why thing fail. Examine the logs. > Thanks > Regards > David > > > > -Original Message- > From: bind-users On Behalf Of David > Carvalho via bind-users > Sent: 13 January 2023 14:11 > To: 'Marco' ; bind-users@lists.isc.org > Subject: RE: Can not query localhost > > Thanks for the reply. > Yes > > ACL active. Exact same configuration as in old server named.conf, with > a different listening IP, of course, which belongs to my LAN ACL. > > Performing "dig @localhost any my.domain" works perfectly. If querying > just "dig @localhost" or "dig @my.ip", tcpdump shows it trying to > connect to top level IPs And I keep getting SERVFAIL. > > > Regards. > David > > > -Original Message- > From: Marco > Sent: 13 January 2023 11:33 > To: bind-users@lists.isc.org > Cc: David Carvalho > Subject: Re: Can not query localhost > > Am 13.01.2023 schrieb David Carvalho via bind-users > : > >> I get SERVFAIL when querying outside my domain. > > Have you enabled an ACL that allows any IP address to query your > public zones? > > You can only restrict recursive requests to your own IP addresses. > > -- > 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 > > -- > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- 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: Incremental transfers generate complete zone reloading
This is just conjecture but I'll take a stab at this problem. First, the fact that the zone is RPZ really doesn't have any bearing on this problem. Do you control both the primary and secondary zones? Please provide the SOA for the zone. This will allow the list to see some key timer values. 1) Updates are applied to the primary zone which triggers a notify to the secondary zone and a resulting incremental zone transfer. (IXFR) 2) Before the IXFR from item 1 is finished, the refresh timer expires triggering the secondary zone to request the SOA from the primary. Since the serial number on the secondary has not yet been updated as a result of the IXFR from item 1, the secondary requests ANOTHER IXFR from the primary. This can cause the overlap you are seeing. The following suggestions for possible workarounds depend on you having control of both primary and secondary zones. There are a couple of things that could help. the refresh timer for properly configured dynamically updatable zone sets needs to be set fairly high. I like 8 hours. YMMV. The updates to the primary zone can be effectively batched using the notify-delay value. This will require some further thought and testing. The ultimate value depends on the volume of updates being generated. Hope that helps, Bob -- 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: Incremental transfers generate complete zone reloading
On 16. 01. 23 15:02, Bob McDonald wrote: This is just conjecture but I'll take a stab at this problem. First, the fact that the zone is RPZ really doesn't have any bearing on this problem. Well, that's incorrect. Please see https://lists.isc.org/pipermail/bind-users/2023-January/107212.html -- Petr Špaček -- 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 Cookies Causing FORMERR
Sounds good. I will just buckle down and stay the course. As I encounter these
servers, I have been attempting to reach out to all of the organizations whose
DNS servers exhibit this behavior. Some are less responsive than others, as in
completely ignored. :/
Thanks for the feedback.
From: Mark Andrews
Sent: Friday, January 6, 2023 2:57 PM
To: Justin Krejci
Cc: bind-users@lists.isc.org
Subject: Re: DNS Cookies Causing FORMERR
Really there are very few servers that are broken and the numbers are
decreasing. They are well under 1%. Just contact the few remaining server
operators and inform them that they are broken. It should just be an upgrade
to the current version to fix.
The behavior for unknown EDNS options was tightened nearly 10 years ago (April
2013). It was unspecified in the original EDNS RFC and made ignored in in the
updated RFC which every vendor should have picked up. At the time some vendors
ignored unknown options and others returned FORMERR or NOTIMP or REFUSED.
Others just dropped the request. Some returned BADVER. It was a mess.
There are also implementations that don’t know how to return FORMERR properly.
You don’t echo back the request with rcode set to FORMERR and QR to 1 as that
produces broken responses but some implementations do that. Why would you send
a message that you don’t understand? Nowhere is there any instructions to do
this.
To send a FORMER you send a DNS message header with rcode set to FORMERR. If
you can parse the question section for QUERY copy that into the response. If
you understand EDNS you can add an OPT record. Similarly TSIG if appropriate
and you support it Yes you can sign a FORMERR.
--
Mark Andrews
On 7 Jan 2023, at 06:50, Justin Krejci wrote:
DNS Servers that do not properly support or properly ignore DNS cookies and
instead return FORMERR is annoying. This is not new. However I have been seeing
more or perhaps just have more users that are finding more domains that are
hosted on authoritative servers with this unfortunate behavior.
Example progrowth.com name severs.
Individual work arounds on caching BIND servers are not difficult to implement,
like this
server 47.206.74.18 {
send-cookie no;
};
server 209.131.228.178 {
send-cookie no;
};
However this workaround is problematic in terms of ongoing upkeep of this list
and the increasing need to add new entries to the list. I'd like to be able to
start sending cookies again if the servers begin to operate compliant to the
EDNS RFC and I would like to not have to write any tools to remove entries from
this list or schedule some regular calendar reminder to check or add to Nagios
or whatever. I'd also rather not just globally disable sending of DNS cookies
but it is something being considered.
In this article @ https://kb.isc.org/docs/aa-01387 it states near the bottom
"Nevertheless, mishandling of the COOKIE option has been known to cause errors
that are fatal to name resolution when the resolver is validating responses
coming from a signed zone, and the authoritative server returns either FORMERR
or BADVERS, or fails to respond to the query. named treats these answers as if
the server does not support EDNS (which it doesn't) so it stops sending any
EDNS queries at all, which makes it impossible to get a DNSSEC response back."
This statement indicates this fall-back method is only applicable to signed
domains. Is there a knob in BIND to apply this behavior to all domains?
Basically, if the authoritative server is behaving incorrectly in this way then
enable no-EDNS or no-COOKIE mode in the interest of allowing DNS queries to
continue to be answered for the end users.
My caching servers are running the BIND 9.18 branch
Thanks for any pointers or suggestions.
-Justin
--
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
--
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: Incremental transfers generate complete zone reloading
Mea Culpa. Apparently RPZ IS the issue here. I learn something new every time I read this list. My apologies for the waste of bandwidth. Bob On Mon, Jan 16, 2023 at 9:02 AM Bob McDonald wrote: > This is just conjecture but I'll take a stab at this problem. > > First, the fact that the zone is RPZ really doesn't have any bearing on > this problem. > > Do you control both the primary and secondary zones? > > Please provide the SOA for the zone. This will allow the list to see some > key timer values. > > 1) Updates are applied to the primary zone which triggers a notify to the > secondary zone and a resulting incremental zone transfer. (IXFR) > > 2) Before the IXFR from item 1 is finished, the refresh timer expires > triggering the secondary zone to request the SOA from the primary. Since > the serial number on the secondary has not yet been updated as a result of > the IXFR from item 1, the secondary requests ANOTHER IXFR from the primary. > This can cause the overlap you are seeing. > > The following suggestions for possible workarounds depend on you having > control of both primary and secondary zones. > > There are a couple of things that could help. the refresh timer for > properly configured dynamically updatable zone sets needs to be set fairly > high. I like 8 hours. YMMV. > > The updates to the primary zone can be effectively batched using the > notify-delay value. This will require some further thought and testing. The > ultimate value depends on the volume of updates being generated. > > Hope that helps, > > Bob > -- 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
