Hi,
I wondered a while whether this would be more appropriate to post
here or as an issue in ISC's gitlab, but came to the conclusion
that for now the best place would be here. The reason is that
the "how to reproduce the problem" bit is quite fuzzy.
If someone from ISC wants this reported as a
> On our production name servers we have check every 30s if bind
> is alive by sending a SOA query to bind. Today I upgraded a few
> nodes from 9.18.x (x between 17 and 27) to 9.20.1 (Ubuntu 24.04
> with packages from ISC ppa).
>
> Since that, we have sporadic timeouts (3s). On the nodes with
> mor
> On Mon, Aug 26, 2024 at 06:05:19PM +0200, Havard Eidnes via bind-users wrote:
>> Thanks. I found it, and it's more than a little embarassing.
>>
>> This is what you get when not building with --with-libxml2: an
>> "un-rendered" xsl file as a result, i
> If I was debugging this I would:
> - compared strace output from working and non-working server
I did parts of that, ref. that other message I sent.
> Unfortunately you are the only person who reported this problem and I
> can't reproduce it either, so it's probably up to you to find needle
> i
BTW,
I got an off-line question how the chrooting is done in my case,
i.e. whether the "chroot" program is used, or the "-t" option to
BIND is used.
In my case it's the latter:
-t directory
This option tells named to chroot to directory after processing
the com
Hi,
and thanks for the suggestions.
This is not an issue of broken clocks, all the involved machines
run ntp and have good sync status traceable to at least a GPS clock.
This does however appear to have something to do with the
chroot'edness of this particular installation, and it's evident that
>> Hi Håvard.
>> Have you tried a different browser?
>
> Not yet. Will do tomorrow.
Latest Chrome on MacOS: just the same; it displays the raw XML
which isn't exactly user-friendly.
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC
Looking a bit further, I find in the XML output:
Server Status
Boot time:
So no actual value? Is there a required post-processing step
which is omitted? I see xsl is mentioned both here and in the
style
> Hi Håvard.
> Have you tried a different browser?
Not yet. Will do tomorrow.
> Having said that, I just started 9.20.0 with this config:
>
> statistics-channels { inet 127.0.1.0 port 8080 ; };
>
> Then pointed three different browsers at that address/port and it looks
> fine to me in all of the
Hi,
I'm mostly running BIND 9.18.x, and have configured statistics
publishing via
statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
inet "actual-address" port 8053 allow { prefix1/24; prefix2/24; };
};
I've started testing 9.20.x.
I see BIND 9.20.x stats publi
>> That being said. It's preposterous to complain about free software.
>
> https://biplane.com.au/blog/?p=375
Well said!
The original poster did not supply any information which might be
of assistance in characterizing what he observed. He only said
"1300 zones", and showed a "top" display. Not
> I use bind9 on my mail server so that Spamassassin can perform the
> necessary DNS blocklist queries. Since it has already happened several
> times that I have to restart bind9 so that a certain domain can still
> be resolved, I wanted to ask if anyone knows where I have to set
> something.
>
>
> this has been planned, but unfortunately other stuff got into the way.
>
> It is still on our roadmap though.
OK, thanks, it's reassuring that I hadn't overlooked something
this time around, and it's good to see it's already thought about
and on your roadmap. It's also on my wishlist, FWIW. :)
> I frontend DoH and DoT traffic with nginx and use that for
> analytics/statistics.
Thanks, but I think that violates the KISS principle.
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with
> Doesn't dig already offer DoT using +tls and DoH using +https?
You're right, it does.
I need to sort out my $PATH...
Regards,
- Håvard
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support sub
Hi,
I recently had reason to enable BIND 9.18.27 to do DoT and DoH
(done via unbound earlier), and it all appears to work well so
far.
I have configured
statistics-channels {
inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
inet port 8053 allow { blah; };
};
The former for collec
>> Sorry if this has already been hashed through, but I cannot
>> find anything in the archive. Is there any chance someone can
>> make dig and nslookup DNSSEC aware and force it to use DoT or
>> DoH ports - TCP 443 or 853 only?
>
> Not sure about that. However, the "kdig" utility from the "knot"
> Sorry if this has already been hashed through, but I cannot
> find anything in the archive. Is there any chance someone can
> make dig and nslookup DNSSEC aware and force it to use DoT or
> DoH ports - TCP 443 or 853 only?
Not sure about that. However, the "kdig" utility from the "knot"
name s
> 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.
> * Be
> 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 appea
> 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
>> getting
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
--
Vis
>>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
> (ht
> 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 a
> 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 r
> 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 wit
> 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 di
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 previou
>> 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 exp
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, but
> 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 e
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 158.38.
> 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 in
> > 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 al
> >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 ni
>> 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 $GENER
> 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
> s
> 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 m
> 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<<- op
> 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 zone
>> 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 l
> 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 th
> 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 recur
> 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 resol
> 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.
>> [...] 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,
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 lat
> 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, t
> 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 an
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 these
> 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 interface.
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) && *fetchp
>> 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
>> I don't suppose there exists a configuration option in BIND which
>> corresponds to Unbound's so-rcvbuf: and so-sndbuf: configuration
>> options?
>
> There is only `./configure --with-tuning=large` which enables
> more sockets and bigger socket buffers.
Hmm, I already have that, but I wonder, h
Hi,
I don't suppose there exists a configuration option in BIND which
corresponds to Unbound's so-rcvbuf: and so-sndbuf: configuration
options?
It would be useful to have those available to adjust only the
"server sockets" BIND handle, instead of having to apply the
corresponding settings system-
Hi,
I recently upgraded one of our caching resolvers to BIND 9.12.3, and
it is configured to do forwarding via
options {
forwarders {
;
;
};
// But if both are dead (unlikely), do resolution ourselves
forward first;
};
The resolver
Hi,
reviving an old thread with some new information:
> On Fri, Mar 09, 2018 at 12:32:41PM +0300,
> Diarmuid O Briain wrote
> a message of 122 lines which said:
>
>> Mar 09 08:11:43 as112 named[3787]: internal_send: 2620:4f:8000::42#53:
>> Invalid argument
>> Mar 09 08:11:43 as112 named[3787
> It would be difficult, and possibly impossible, to continue to
> process queries and format a report on queries simultaneously
> without losing information in the report. To have a separate
> thread creating the report, it might have to stop query
> processing, take a snapshot of the data at tha
>> Is that pulling the old-style stats file, or the HTTP-based stats channel?
As should be evident from my other message, this is using the
HTTP-based stats channel.
> If the latter... the zone list (and by extension the root
> document) seems to take a long time to process, and involves
> some s
>> The stats channel output relating to running tasks and memory contexts
>> is very extensive.
>
> Either way I would not have expected use of the statistics
> channel to negatively impact the query performance. Is the query
> channel processed with "no-delay", so that a thread doesn't get
> stuc
>> some further local discussion has made me aware that us running
>> "collectd" for monitoring BIND may be contributing to the
>> problem; collectd fetches data each 10s by using the BIND-
>> configured statistics-channel, thus BIND is processing a TCP
>> connection to deliver the statistics data.
Hmm...
some further local discussion has made me aware that us running
"collectd" for monitoring BIND may be contributing to the
problem; collectd fetches data each 10s by using the BIND-
configured statistics-channel, thus BIND is processing a TCP
connection to deliver the statistics data.
It's
Hi,
one of my users made me aware of this rather unexpected behaviour
in our recursors running BIND 9.10.5-P3 on NetBSD/amd64:
It seems that every 10s, "on the clock", BIND will temporarily
increase the query response time rather drastically for a short while,
only to settle down to normal behavi
> Upgrade.
:) So 9.9.10 should have a fix for this?
(Its release had passed under my radar.)
Regards,
- Håvard
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists
Hi,
one of our recursive resolvers running BIND 9.9.9-P6 stopped last
night, in the log I find:
Apr 19 22:26:30 named[14737]: resolver.c:4751: INSIST(fctx->type ==
((dns_rdatatype_t)dns_rdatatype_any) || fctx->type ==
((dns_rdatatype_t)dns_rdatatype_rrsig) || fctx->type ==
((dns_rdatatype
Hi,
we are experiencing that our recursive resolver running BIND
9.9.9-P6 is sometimes apparently spuriously returning SERVAIL to
certain queries.
I suspect this is related to expiry of entries from the cache, as
this sort of error appears to occur more often for entries which
are published with
Hi,
I just tried firing up BIND 9.10.0a2 on one of our recursive
servers, and after a relatively short while I got:
Feb 17 09:34:26 oliven named[19939]: name.c:534: REQUIREname) != ((void
*)0)) && (((const isc__magic_t *)(name))->magic == ((('D') << 24 | ('N') << 16
| ('S') << 8 | ('n')
>> So I'm sitting here scrathing my head even more confused than
>> usual. Anyone have any insights?
>
> The SOA has the wrong owner name. Bind followed a referral for
> map.media6degrees.com but the SOA wrongly says the zone apex is
> media6degrees.com.
>
> https://lists.isc.org/pipermail/bind-us
Hi,
I've semi-recently updated a public resolver to running a bit newer
version of BIND, currently at 9.8.4-P3.
I've noticed that quite a number of query responses it receives
are logged with "DNS format error" ... "invalid response". Some
semi-random examples picked from the log:
apis.markets.
> Assuming a case where there is an empty CNAME chain, but no
> error, [...]
...
> ;; ANSWER SECTION:
> www.apple.com. 281 IN CNAME www.isg-apple.com.akadns.net.
> www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net.
> www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.ne
72 matches
Mail list logo
