Hi,
we're running BIND 9.14.1 in a pretty much "standard"
configuration; this one instance does query forwarding but also
"forward first".
Today this one instance decided to exit, and in the log I find:
May 11 15:02:51 named[5567]: resolver.c:10515: REQUIRE(fetchp != ((void
*)0) &&
> BTW is there any chance that you and Havard share any common
> bits of configuration?
That would be coincidental; we've not coordinated our configs.
However, it is true that I'm also monitoring my BIND instances,
using collectd, and as far as I know it's using the XML-based
monitoring
>> I think there must be something wrong with the log message. It
>> seems excessive to log this message about once per query,
>> especially since it seems to (misleadingly?) indicate an error
>> condition? I'm not intimate enough with the code to suggest what
>> the exact problem is, though.
>>
Hi,
I'm resurrecting an old thread:
>> Is there a workaround/configuration-directive not to log every request with
>> this "error"? One way would be using BIND 9.9.9-P2 (because this code was
>> added in 9.10.x...), but I would prefer 9.10.x.
>
> (1) Don't use regular BIND 9.9 for RPZ. For using
Hi,
our BIND recursors apparently intermittently return ServFail
error code for lookups e.g. of bugs.FreeBSD.org, and now I've
caught it in the act.
I've used http://dnsviz.net/ on both FreeBSD.org, isc-sns.net,
isc-sns.info and isc-sns.com (names for the name servers of
FreeBSD org sits in
> BIND 9.14.8 (Stable Release)
> When I start the server, I get such a prompt. Are there any parameters I
> [can] turn off? After all, not all servers implement DNSSEC
>
> 09-Dec-2019 16:17:46.497 dnssec: warning: managed-keys-zone: Unable to
> fetch DNSKEY set '.': timed out
This appears to be
> This was an accident - we did *not* do this on purpose - but infact,
> this is a good time for anyone who still has dlv.isc.org configured
> to REMOVE it from your BIND configuration.
This advice may be misunderstood. Use of dlv.isc.org is usually
implied, not explicitly stated in named.conf,
Hi,
we got reports about a temporary resolution failure for some names
under norid.no this morning. Digging through the logs, the first
instance appears to be
Apr 24 08:35:02 resolver named[244]: validating zabbix-test.norid.no/CNAME: bad
cache hit (norid.no/DNSKEY)
and a couple of minutes
>> [...] There are two invocations of dns_resolver_addbadcache() in
>> lib/dns/resolver.c, with fairly complicated preconditions to reach
>> each of those two points.
>
> I've had a very quick look at the code, and it looks to me like one
> case is due to lack of authoritative server IP addresses,
> OS settings and the system environment
...
> 2e) Make sure your socket send buffers are big enough. (not
> sure if this is obsolete advice, do we need to tell people how
> to tell if their buffers are causing delays?)
2e#1) Make sure your UDP socket *receive* buffers are big enough.
> is there a way to know that a query has already been tried a few
> minutes ago, and failed?
>From whose perspective?
A well-behaved application could remember it asked the same query
a short while ago, of course, but that's up to the application.
Or is the perspective that of a recursive
> Still, being able to differentiate a local network congestion from a
> remote bad configuration would help.
That's true. There's
https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-16
which look promising, trying to make it possible to distinguish
between the various reasons a
> Yeah, by the time it lands on Debian's glibc we'll have grown a long
> long beard. I'm still missing RES_TRUSTAD...
Oh, this set me off on a tangent. I hadn't heard of RES_TRUSTAD
before, so I found
https://man7.org/linux/man-pages/man5/resolv.conf.5.html
which under "trust-ad" contains
>> So ... I can't get the glibc behaviour to mesh with the standard
>> on this particular point.
>
> It's set in RFC 6840:
I stand corrected, thanks.
- Håvard
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this
> I am getting the following warning:
>
> The following NS name(s) were found in the authoritative NS
> RRset, but not in the delegation NS RRset (i.e., in the com
> zone): (a DNS server)
This sounds like there is a mismatch between the NS RRset for the
zone on the authoritative NSes for the
> Don't know if that helps, but if I query my local Bind DNS for a CNAME,
> that doesn't exists, dig gives me the SOA record:
>
>> dig cname nonexisting.example.com @mydns
>
> ; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<-
> I am trying to create an NXDOMAIN response-policy for the
> following example domain:
>
> x.yy.*.*.dns.*
>
> I have reviewed RFC1034 & RFC4592 and many online articles and
> blog postings, but thus far have not found anything suggesting
> that this type of match is possible. Am I expecting too
> On 2022-05-02 18:01, Timothe Litt wrote:
>> Still, overall DNS seems to generate more problems than fun, so if LOC
>> provides amusement, it's a good thing.
>
> I know one of my users found them quite amusing. I can't recall what
> location they picked or why, but it had some sort of personal
>
>> 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.
>
> Thanks.
> How is the syntax for IPv6?
> Is it possible to do it for an entire /64?
The full syntax of the
> Do wildcard records work with multiple labels? I was thinking that they
> didn't, but it's that wildcards in PKIX do not work with multple labels,
> alas.
As far as I understand, yes, wildcard "works with multiple labels", at
least in the meaning that a wildcard can expand more than one label
> >To "fill" an ip6.arpa zone for a /64 requires 18446744073709551616
> > records (yes, that's about 18 x 10^18 if my math isn't off). I predict
> > you do not posess a machine capable of running BIND with that many
> > records loaded -- I know we don't.
>
> It sure would be
> > It probably does not play well with DNSSEC, although I was thinking
> > about whether some amount of wildcards in the signed reverse could
> > help, but I don't think so.
>
> Well, what if the reverse is an NSEC3 does that let the server
> make up stuff with having to sign it
Hi,
I tried using BIND 9.18.10 as a downstream name server of an
OpenDNSSEC 2.1.8 installation, but after sorting out the ACL
issues on the OpenDNSSEC side, zone transfers failed with
messages such as these:
Jan 21 17:15:34 new-ns named[22056]: transfer of '4.38.158.in-addr.arpa/IN'
from
Hi,
I recently made an upgrade of BIND to version 9.18.11 on our
resolver cluster, following the recent announcement. Shortly
thereafter I received reports that the validation that lookups of
"known entries" in our quite small RPZ feed (it's around 1MB
on-disk) no longer succeeds as expected,
Hi,
by default, the files written by BIND when acting as a slave is
not in "text" format, but is some binary file format, I beleive
what is referred to as "raw" format.
Once in a while it's desireable to be able to see the contents of
the slave zone file as plain text. To that end I have
> Named-checkzone and named-compilezone are the same executable.
> Named-checkzone looks up remote records to more completely
> detect configuration errors. See the man page for details.
Thanks for the hint, I apparently need to complicate my script
even more to avoid the network lookups.
You
>> I recently made an upgrade of BIND to version 9.18.11 on our
>> resolver cluster, following the recent announcement. Shortly
>> thereafter I received reports that the validation that lookups of
>> "known entries" in our quite small RPZ feed (it's around 1MB
>> on-disk) no longer succeeds as
> The consistency checks are not new. The message indicates that
> the IXFR contained a delete request for a record that doesn't
> exist or an add for a record that exists. Named recovers be
> performing an AXFR of the zone.
Interesting.
BIND 9.16.36 does not produce this log message, so it was
> Our CentOS/RHEL 8 package are not just random BIND 9 snapshot.
Then please let me suggest that there is possibly an issue with
identification (customer said "9.16.23") and documentation of the
actual changes that are incorprorated in your distribution, compared
to the upstream-maintained patch
> I suspect you don't need the NS records in challenge.state.ak.us and
> if you remove them then the records in challenge.state.ak.us are
> simply part of the state.ak.us zone since they're served off of the
> same server.
Unfortunately "not quite".
While a publishing name server will respond
>>and if I run straight "upstream" code, it's fairly straight-
>>forward to upgrade to this version, modulo, of course, the fact
>>that this involves building it from source.
>
> It may not be necessary to build from source. There are packages for
> some distros maintained by ISC
>
> You do not have to sift through lists.
That depends entirely what one wants to do. I see a couple of
scenarios where that may be required:
1) Let's say someone has flagged to you as a BIND administrator that
your BIND installatin is susceptible to CVE-2022-3924. This
could be done via
Hi,
a partial response:
> If it's possible, can anyone confirm zone transfers from master
> to slave would still work even if the servers ran different
> major versions?
Yes, "of course", because the details of that transfer is
specified by the DNS protocol standards.
Regards,
- Håvard
--
> I was curious about the additional section count dig is
> reporting. I had to do a packet capture to prove it to myself,
> but there is an additional records section returned in the
> answer from 183.47.126.169. It is the edns OPT pseudosection
> which is also shown in my dig output:
You
> You are wrong if you think the SOA record is only informal.
> It's not, see https://www.rfc-editor.org/rfc/rfc2308 for more
> details.
Exactly. The SOA record included in the "Authority section" of an
NXDOMAIN ("name does not exist") or NODATA ("answer count" = 0,
i.e. indicating "name exists,
> On 02/06/2023 13:59, Jesus Cea wrote:
>> On 2/6/23 10:38, Cathy Almond wrote:
>>> Has this just started - as in, it worked before ... when?
>>
>> No idea. We have been biten by this because a new client. The issue
>> could be for ages, no idea.> That may be so. For the client, they're
>>
> The facts are:
>
> * 191.131.in-addr.arpa is served from awsdns
Correct. And it's delegated to from the 131.in-addr.arpa zone,
maintained by ARIN.
> * It delegates 85.191.131.in-addr.arpa with fs838.click-network.com
> and ns102.click-network.com above the zone cut.
Correct.
> *
37 matches
Mail list logo
