"not exact" error message
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.x.yy#53: failed while receiving responses: not exact Jan 21 17:16:42 new-ns named[22056]: transfer of 'ufisa.no/IN' from 158.38.x.yy#53: failed while receiving responses: not exact Downgrading BIND to 9.16.36 made this work, so this appears to be a new consistency check introduced with the newer version which isn't being done by 9.16.36. Any idea what this new check consists of, and what I should hint to the OpenDNSSEC developers to fix? I did a "dig axfr -y " of one of the zones from the OpenDNSSEC host, and I found the TSIG record used to support the zone transfer embedded in the result (twice!), and when I fed the resulting file to named-checkzone, it didn't want to validate the zone before I removed the two TSIG records. This, however, may be unrelated; I do not know. Best 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 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: "not exact" error message
> 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 easy to be misled to conclude that this was a new consistency check. Does 9.16.36 and 9.18.10 behave differently in terms of their usage of IXFR? The log message BIND 9.18.10 produces does not mention IXFR or that it's going to fallback to AXFR. I mis-interpreted it as a fatal error message, and downgraded to BIND 9.16.36 without verifying whether 9.18.10 actually worked as intended anyway (it does, I just re-instaled 9.18.10 and re-signed a zone and verified that it makes it through). 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 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
rpz testing -> shut down hung fetch while resolving
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 instead take a long time, finally gives SRVFAIL to the client, and associated with this we get this log message: Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving 'known-rpz-entry.no/A' Initially I thought that this was new behaviour between BIND 9.18.10 and 9.18.11, but after downgrading to 9.18.10 on one of the affected nodes, this problem is still observable there. Also, only a subset of our 4 nodes exhibit this behaviour, despite the unaffected ones running 9.18.11, which is quite strange. None of the name servers are under severe strain by any measure -- one affected sees around 200qps, another around 50qps at the time of writing. I want to ask if this sort of issue is already known (I briefly searched the issues on ISC's gitlab and came up empty), and also to ask if there is any particular sort of information I should collect to narrow this down if it is a new issue. 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 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: rpz testing -> shut down hung fetch while resolving
>> 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 instead take a long
>> time, finally gives SRVFAIL to the client, and associated with
>> this we get this log message:
>>
>> Jan 26 18:41:27 xxx-res named[6179]: shut down hung fetch while resolving
>> 'known-rpz-entry.no/A'
>
> This usually means there's a circular dependency somewhere in the
> resolution or validation process. For example, we can't resolve a name
> without looking up the address of a name server, but that lookup can't
> succeed until the original name is resolved. The two lookups will wait on
> each other for ten seconds, and then the whole query times out and issues
> that log message.
>
> The log message is new in 9.18, but the 10-second delay and SERVFAIL
> response would probably have happened in earlier releases as well.
This turned out to be related to the fact that we had configured
query forwarding from two of our nodes to two of the others with
the intention to build a larger central cache, and improve query
response time for the resolvers which did that forwarding.
Once I commented out the query forwarding, this problem no longer
occurred. Our forwarding config was of this form:
forwarders {
128.39.x.y;
158.38.z.r;
};
// But if both are dead (unlikely), do resolution ourselves
forward first;
This part is now commented out and I've done "rndc reconfig", and
the SERVFAIL responses to the "known rpz-blocked entries" no
longer occur. But ... the two resolvers will now have to build a
cache of their own, and do not benefit from the cache built on
the two more "central" nodes.
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 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
Converting between zone file formats
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 previously used named-compilezone to do this with named-compilezone \ -q -j -f raw -F text -o - \ $z \ $directory/$z However... This does not appear to work anymore. Earlier I ran BIND 9.16 on this host, but it has been upgraded to 9.18 (built and installed from local source). It seems that a while back (probably in the 9.16 era), named-compilezone was changed to a symlink to named-checkzone, and it also looks like BIND 9.18 no longer installs named-checkzone, so what I have as named-checkzone appears to come from BIND 9.16. Trying to use the procedure as above results in a named-checkzone which hangs in select(), which is a bit strange when it's only supposed to act on local files?!? What should I now use instead of the above to convert the binary zone file to back to the textual master zone file format? Please don't say "that's not possible"... (This might be important to be able to do if an upstream suffers a catastrophe of some sort, as a step along the path to convert this name server to be a master for the zone in question. Being a master implies being able to modify the zone, and doing that with a binary file is ... slightly inconvenient.) 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 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: Converting between zone file formats
> 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 didn't answer, though, whether the 9.16 named-checkzone will be able to read & correctly interpret the binary zone files 9.18 stores in the file system, or whether there is some other and more preferable way to accomplish what I want, either with 9.18 itself or otherwise. 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 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: Delegation NS-records when zones share an authority server
> 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 with data from the most specific zone available to it when queried (e.g. for the NS records for challenge.state.ak.us), this "overriding" or "leakage" does not happen when you do a zone transfer of the parent zone (state.ak.us). So ... if you have a publishing name server which is a name server for state.ak.us and not for challenge.state.ak.us, it will *not* have the delegation NS RRset for challenge.state.ak.us, and if a recursor happens to query this particular publishing name server as part of the process of resolving a name in challenge.state.ak.us, it will get an apparently-spurious NXDOMAIN response. I understand this isn't the case right now, but this is a problem which might come and bite your behind if you later decide to change the NS RRsets so that they are no longer equal for the two zones. So the long and short of my advice: do the delegations properly by copying the NS RRset from the child to the parent, plus any required address glue records, and this particular problem will not become an issue. Best 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 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: Fully automated DNSSEC with BIND 9.16
> 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 releases published since that release. Sifting through those two lists and juding what's "needed" and what isn't quite quickly becomes an unmanageable task. Stability of the base version of BIND (perhaps in particular) should not be mis-interpreted as an indication of continuing operational safety. Otherwise I have sympathy with Ondřey Surý's message. Best 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 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: Fully automated DNSSEC with BIND 9.16
> 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 an "external scan" and based on the BIND version returned (if your BIND is configured to reveal such details), or via other means. How do you as an administrator figure out if the version you actually run has the fix for this CVE included? From the BIND change log, I can see --- 9.16.37 released --- 6067. [security] Fix serve-stale crash when recursive clients soft quota is reached. (CVE-2022-3924) [GL #3619] 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. On the other hand, looking at a version produced by a package maintainer (RedHat, Debian, ...), and where the package maintainer insists on sticking with whatever base version they started from (strictly based on timing, in all probability) and selectively applying patches, it will be much harder to figure out whether the fix is actually included. And ... if the fix is indeed included, you'll as administrator in all probability have to mark the issue as "false positive" after having assured yourself that the fix is included. However, getting to this assurance can be quite a bit of work. 2) You will end up with a somewhat similar scenario for non-security-related functionality fixes -- you may hit a problem which has been fixed upstream since your distributor forked off BIND, and you may be able to find the entry for the fix in BIND's upstream change log, but figuring out if that fix is indeed included in the code you run will make it necessary to rummage through the "patch list" of the package administrator. > We provide quite detailed git branch with each change we > make. It has references to bugs related too. I admit changes > listed in release notes of bind9 releases are nicer. But we do > not hide what and why we do changes, publish them quite nice > way for c9s [1]. It would be the same c8s as well soon. > > For important changes they are mentioned in release notes of the minor > release. But I admit we do not mention explicitly each bug we fix the > way ISC does. It would make our documentation unreadable. > > In any case, even if we fall behind a couple of releases, any our > packages of bind 9.16 are capable of automated DNSSEC deployment just > fine. Sure, even we do not support it for RHEL7 or older. > > [1] https://gitlab.com/redhat/centos-stream/rpms/bind/-/commits/c9s I certainly do appreciate that this is a considerable effort, and that you do this as well as you can with all good intentions. Now, even though the change log is available as stated (which is good, of course) does not necessarily make it easy to find. And ... solving the above two issues still requires a detailed sift through the lists. 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 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: Fully automated DNSSEC with BIND 9.16
>>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 > (https://kb.isc.org/docs/isc-packages-for-bind-9). I stand corrected, thanks for reminding me. I come from the non-Linux open source side, so needs this reminder from time to time. BTW, if someone from ISC is listening in, the above KB URL currently returns The request is blocked. 04Mk/ZADbZIhApAs8So/u0PGqLpjUU1ZHMjBFREdFMDYyMgAxMTU1ZGM4Yy1kNzdiLTQ3YzQtOThjNS02NzBhNjQ3MGRhNzE= Best 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 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 it possible to upgrade bind from 9.11 to 9.18 directly?
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 -- 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> 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 a SERVFAIL from your resolver instead of 'there is no RR >> for oauth-login.cloud.huawei.com'. > > But they should be getting a query response for the A record for the > same name, and then using that - assuming that they do actually query > for the A record too? > > Is the client actually broken because of the broken provisioning of > the servers for cloud.huawei.com, or is the issue just the plague of > log messages you're seeing? > > (Aside: it is nevertheless a pity Huawei can't set up this delegation > properly - it might just be an incompletely/improperly configured > (maybe proxying?) set of load-balancers or something of that ilk). It definately looks like a load-balancer of some sort which doesn't sufficiently implement the DNS standards, and probably has no concept of "zone", or even knows anything about other RR types than "A". Ref. the answers you get to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. a (gives two IPv4 addresses) compared to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. dig @ns3.dnsv5.com. cloud.huawei.com. ns Both of the two latter say "NOERROR", "answer-count=0" and refers in the authority section to ;; AUTHORITY SECTION: huawei.com. 180 IN SOA ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1686041357 3600 180 1209600 180 However, asking one of the huawei.com name servers for the name servers for cloud.huawei.com as e.g. dig @nsall.huawei.com. cloud.huawei.com. ns gives this result: ;; AUTHORITY SECTION: cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org. cloud.huawei.com. 600 IN NS ns3.dnsv5.com. cloud.huawei.com. 600 IN NS ns4.dnsv5.com. So... Neither of those three appear to even implement the concept of "zone", and the observed behaviour ensues, as the SOA when asked for or NS records for that name results in an upwards referral, and that now triggers a SERVFAIL, as that doesn't progress the resolution of the name. 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 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: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> 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, but no record of this type exists")
indicates "under whose authority is this reply given", as indicated by
the owner name of the SOA record, and the version number of that zone
(as indicated by the version number in the SOA record).
Also, following up on an earlier part of this thread:
>>> It is at the core of delegation and trust model of DNS, now
>>> possibly enforced by DNSSEC.
Correct. It's a matter of how you divide the name space into
zones, what a minimal zone looks like from an external observer,
and how delegations work.
A minimal zone will need to contain a SOA record for the zone,
and the NS RRset for the zone. When a DNS name server which has
been delegated authority for a given zone, that name server had
better serve up the correct(!) SOA record with the correct owner
name when supplying an NXDOMAIN or a NODATA answer.
$ dig huawei.com. ns
...
;; ANSWER SECTION:
huawei.com. 2616IN NS nsall4th.huawei.cn.
huawei.com. 2616IN NS nsallsec.huawei.com.
huawei.com. 2616IN NS nsall.huawei.com.
huawei.com. 2616IN NS nsall3rd.huawei.cn.
...
Pick one, query:
$ dig @nsall.huawei.com. cloud.huawei.com. ns
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30727
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
cloud.huawei.com. 600 IN NS ns4.dnsv5.com.
cloud.huawei.com. 600 IN NS ns3.dnsv5.com.
cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org.
...
This means:
1) The zone cloud.huawei.com should exist
2) This entire zone is delegated to the named name servers (only
authority over the DS record for the zone name remains with the
parent NSes, if/when you do DNSSEC).
3) NXDOMAIN or NODATA responses from these name servers for names
in cloud.huawei.com should include the SOA record for the
cloud.huawei.com zone.
4) As stated above, both SOA and NS records for this zone should
be returned by these name servers (they do not, see below).
Side issue: note that the "additional" count above in the last
reply is wrong (there is no additional record in the reply).
$ dig @ns4.dnsv5.com. cloud.huawei.com. ns
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15950
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
Again, "additional" count is wrong. The owner name of the SOA
record is also wrong, since the reply from nsall.huawei.com above
states that cloud.huawei.com is a delegated zone. It is
therefore wrong by this name server to refer back up the zone
tree to the parent zone's authority for a name which is clearly
within the delegated zone.
Also, it failed to respond with a copy of the NS RRset for the
zone; it should have included that set in the answer section when
asked explicitly about it.
$ dig @ns4.dnsv5.com. .cloud.huawei.com. a
...
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37427
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
OK, here we get (correctly) a "name does not exist" error, since
the name truly doesn't exist, but again the owner name for the
SOA record in the response is wrong, and refers to the parent
zone, not the zone where the name would exist if it did exist.
Upwards referral => SERVFAIL. You get what you deserve for not
correctly implementing the delegation model and zone delination
rules.
$ dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com.
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22050
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
...
;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com.
enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
...
Again, "Additional" count is wrong, and the SOA owner name is
wrong -- it should have been cloud.huawei.com, since the copy of
the NS RRset from the huawei.com zone indicates that
cloud.huawei.com should be a zone.
Best 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 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/bin
Re: Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response
> 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 appear to be correct, and I stand corrected on this side issue. It doesn't really change the major problem that the name servers serving the cloud.huawei.com zone appear to have a deficient implementation of the concept of a zone. 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 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: Observation: BIND 9.18 qname-minimization strict vs dig +trace
> 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. > * Below the zone cut the nameserver claims to be authoritative for its > parent's zone (191.131.in-addr.arpa) instead of > 85.191.131.in-addr.arpa. (In other words it's lame.) Well, yes. When queried for the NS set for 85.191.131.in-addr.arpa it returns "NOERROR" with the 191.131.in-addr.arpa SOA record in the authority section. This is what is called an "upward referral", and indicates that the delegation structure and/or child name server setup is inconsistent with the delegation structure. Were I less charitable I would say "messed up". Basically what you say above -- it doesn't serve the delegated zone so is "lame". > * (Below the zone cut it also erroneously advertises one of its > nameservers as simply ns102. instead of ns102.click-network.com) Yep. > * There is no server which actually advertises itself as authoritative > for 85.191.131.in-addr.arpa Yep. Both of the resolveable NSes ns102.click-network.com and fs838.click-network.com claim authority over 191.131.in-addr.arpa, which they don't have according to the parent zone DNS delegations. 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 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: Make dig and nslookup DNSSEC aware?
> 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 server is able to do DoT and DoH (the latter only if configured to use libnghttp2), and in my case that was the shorter path to the goal of having a CLI tool to do DoT and DoH testing. 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 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: Make dig and nslookup DNSSEC aware?
>> 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 server is able to do DoT and DoH (the latter only if > configured to use libnghttp2), and in my case that was the > shorter path to the goal of having a CLI tool to do DoT and DoH > testing. I should perhaps make it clear that this only answers half of the question; "kdig" isn't any more "DNSSEC aware" than "dig". And, no, I'm not aware of any such plans to incorporate a DNSSEC validator in any of those tools. Not sure it makes technical sense, as it's a fairly large task. That's what a validating recursive resolver does; watch for the 'ad' flag from one such instead? 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 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
Counters for DNS transports?
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 collection of monitoring data using collectd, the
latter for interactive inspection.
However, I was somewhat surprised that there does not appear to
exist any stats counter couting the number of queries received
per transport, to make it possible to monitor and distinguish
between "via UDP/53", "via TCP/53" and "via TLS" or "via HTTPS".
Is this a missing feature?
I've not checked, but does perhaps BIND 9.19.x have an
improvement over 9.18 in this aspect?
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 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: Make dig and nslookup DNSSEC aware?
> 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 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: Counters for DNS transports?
> 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 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: Counters for DNS transports?
> 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. :) Best 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 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
> 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. > > A mail user regularly receives a newsletter from Spain. But the query > to check the DKIM signature sometimes leads to a communication error, > timeout and a write error. I am then informed of these errors by > e-mail so that I can restart bind9 promptly. Because then it works > smoothly again until this problem occurs again at some point. > > Domain of DKIM-request (duration when the problem occurs 4992 msec!) > > dig s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es My go-to DNS debugging site at https://dnsviz.net/d/s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/dnssec/ appears to indicte there is more than one problem, but the most serious one is probably this one: It might look like one or more of the publishing name servers responds incorrectly when queried for an "empty non-terminal" name (e.g. _domainkey...), which probably itself doesn't have any data on that node, but has data on "names below". The correct response code is then NOERROR with answer count=0 (aka. "NODATA"), not NXDOMAIN. When a recursor gets NXDOMAIN back, it is free to assume that the queried-for name does not exist (which is obvious), and nothing exists below that node either. See RFC 8020. 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 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: 9.18 horrendous
>> 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. Nothing about the
query load, nothing about whether the name server also performed
recursive lookup service, and nothing about anything significant
in the environment has changed since the "good old days of older
versions" -- in other words, nothing which can be used to narrow
down the cause of his observation.
Instead we get anger where the user uses swearwords and implies
that ISC staff are stupid ("with stupidity like this"), which I
can assure you of is not true.
I run several BIND installations in my work, both a resolver
cluster and several publishing name servers, and routinely see
query loads in the 2000 qps range for the resolver nodes and our
publishing nodes see between 100 - 400 - 1000 qps with no
noticeable load to speak of, all with relatively recent BIND
9.18.x versions. Yes, this is not particularly impressive
figures, which makes us a "small fish". Perhaps the original
poster wanted to implicitly brag that he is a "big fish"?
So what that original poster was going on about I have absolutely
no idea, and there's precious little posted in his message which
is actionable.
As both recipient and originator of error reports of various
types in my work, I appreciate the details the BIND issue tracker
asks for when submitting actual bug reports, and I try my best to
submit decent error reports with sufficient details for
reproduction of any problem I report.
But it's evident that the original poster had no intention of
contributing to improving BIND.
The fact that many if not most of us get all this for free is
further reason to not just complain for the sake of complaining.
Best 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 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
BIND statistics
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 publishing is ... different.
If I use firefox and visit http://actual-address:8053/ with BIND
9.18.x, I get a reasonably rendered HTML display which is easy to
view.
Not so for BIND 9.20.x; I get an XML document which firefox (in
this particular case version 120.0) informs me at the top
This XML file does not appear to have any style information
associated with it. The document tree is shown below.
and the document starts with
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js"/>