Re: TLS Statistics
Am 2023-08-02 08:43, schrieb Ritterhoff, Florian: Hello everyone, we have activated DoT and DoH for a few days. We would like to make a statement regarding the use. Unfortunately, we are currently unable to find any explicit statistics or explicit log attribute or similar that would allow conclusions about the use of TLS. Can someone possibly help here? In theory, you could probably use bro/zeek to generate these. I haven't looked at this specifically, but I recently used it to make statistics about who still uses TLS 1.0 and 1.1 on our mailservers (before we shut it off). Rainer -- 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: DNSSEC adoption
Am 2022-08-03 15:27, schrieb Bob Harold: I think the best way to soften the effect, and make DNSSEC much less brittle, without losing any of the security, is to reduce the TTL of the DS record in the parent zone (usually TLD's) drastically - from 2 days to like 30 minutes. That allows quick recovery from a failure. I realize that will cause an increase in DNS traffic, and I don't know how much of an increase, but the 24-48 hour TTL of the DS record is the real down-side of DNSSEC, and why it is taking me so long to try to develop a bullet-proof process before signing my zones. These days, companies of all sizes are using ultra-short TTLs of 60s (and I've seen less) for all sorts of "fail-over" mechanisms and load-balancing schemes. One more thing should *in theory* not matter much. Personally, I'm not too happy about short TTLs. This trend is likely significantly undermining the stability and redundancy of the internet as a whole already. -- 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 BIND not iterated over all authoritative nameservers
> Am 30.10.2023 um 16:59 schrieb Michael Martinell via bind-users > : > > Thanks to all who responded. Putting qname-minimization disabled; in > named.conf resolves the issue in my testing. > > I did try specifying relaxed (which appears to be the default), but that > didn’t work either. > > I agree it would be great if the far ends would make sure what they publish > is correct, but it will take a large company to push them to do so. > I usually tell people that the other side needs to fix their stuff. Mostly happens when people fubar their DNSSEC setup. But this name server stuff (more often then not, it’s some Load-Balancer acting as a DNS-server) In both cases: I usually ask them if they can be absolutely sure if the other side hasn’t been hacked? You don’t go and try to override broken SSL certificate setups with HSTS, do you? That said, I’m still on 9.16, too. -- 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
https://intodns.com/mallorcazeitung.es
They have to fix this first, IMHO.
And that doesn’t take into account the problems found by zonemaster.
https://zonemaster.net/en/result/1041e4ac095c7018
> Am 01.06.2024 um 12:08 schrieb Thomas Barth via bind-users
> :
>
> Am 2024-06-01 04:34, schrieb Michael Batchelder:
>
>> Thomas, can you clarify whether all queries to 127.0.0.1/53 result in:
>> ;; communications error to 127.0.0.1#53: timed out
>> when this problem occurs, or do just queries for
>> s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es fail (or some level
>> of failure in between all queries and the ones for that one domain)?
>> And at that time, can you successfully query from the same system
>> using a public resolver (e.g. "dig @9.9.9.9
>> s1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es TXT")? And do you
>> have BIND's logging for the queries that fail?
>
> I have only observed this with this mallorcazeitung domain so far. Perhaps it
> has something to do with my server or the network environment of my server
> host. I have another identical server, but in a different network / on a
> different host system. And on the second server, the duration of the uncached
> query for this domain is normal (128 msec).
>
> Problem server 1
> ;; Query time: 3348 msec
>
> Server 2
> ;; Query time: 128 msec
>
> I restarted server 1, but this did not bring any improvement. But so far it
> only takes so long with this mallorcazeitung domain.
>
> I tried to activate logging (found it on a website), but the first attempt
> resulted in an error. I'm a bit too exhausted now, as I've been sitting in
> front of the PC all week and now need to take a break.
>
>
> mkdir /var/log/named
> chown bind:root /var/log/named
> chmod 0750 /var/log/named
>
> nano /etc/bind/named.conf.local
>
> logging {
>channel my_syslog {
>syslog daemon;
>severity notice;
>};
>channel my_file {
>file "/var/log/named/messages";
>severity info;
>print-time yes;
>};
>
>category default { my_file; };
> }
> --
> 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
Problem resolving a domain
Hi,
at work, I have a problem resolving the following domain:
myapplication.international.barclays.com
BIND 9.16.27, FreeBSD 12.3-P5.
2022Q2 ports.
I copied the config to a VM at home - but it did not work there, either.
I believe it must have happened on the update from BIND 9.16.26 to 9.16.27.
options {
directory "/usr/local/etc/namedb/working";
pid-file"/var/run/named/pid";
dump-file "/var/dump/named_dump.db";
statistics-file "/var/stats/named.stats";
allow-recursion {"rec";};
allow-query-cache { localhost; "rec" ; };
// CIS recommended:
// serverid none;
// dnssec-enable yes;
// dnssec-validation auto;
// dnssec-accept-expired no;
listen-on { 192.168.1.61; };
disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
disable-empty-zone
"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
disable-empty-zone
"1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
};
acl rec {
127.0.0.0/8;
192.168.1.0/24;
::1;
};
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
// RFCs 1912, 5735 and 6303 (and BCP 32 for localhost)
zone "localhost"{ type master; file
"/usr/local/etc/namedb/master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// RFC 1912-style zone for IPv6 localhost address (RFC 6303)
zone "0.ip6.arpa" { type master; file
"/usr/local/etc/namedb/master/localhost-reverse.db"; };
// "This" Network (RFCs 1912, 5735 and 6303)
zone "0.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Private Use Networks (RFCs 1918, 5735 and 6303)
zone "10.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "16.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "17.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "18.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "19.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "20.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "21.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "22.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "23.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "24.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "25.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "26.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "27.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "28.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "29.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "30.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "31.172.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "168.192.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
// Shared Address Space (RFC 6598)
zone "64.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "65.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "66.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "67.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "68.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "69.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "70.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "71.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "72.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "73.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "74.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "75.100.in-addr.arpa" { type master; file
"/usr/local/etc/namedb/master/empty.db"; };
zone "76.100.in-addr.arpa" { type
Re: Problem resolving a domain
Hi, Thanks for the hints! It does indeed work with these settings. The problem is also that google and quad9 and most of the rest of the internet seem to be able to resolve it. While I investigated this issue, I came around a posting from one or two years ago where similar problems with Barclays were reported. And now, because I already spent too much time on this, I did a little digging and found a few job descriptions on their site: https://search.jobs.barclays/job/knutsford/network-connectivity-engineer/13015/26345992688 So, they use Infoblox and F5 - though I guess the problem is more with the firewall before these products… Funnily enough, this problem was a reported to us by an entity (a subsidiary of our company) that uses Infoblox. I’m half-tempted to contact them so they can contact Barclays - but likely neither side is going to bother - because „It works with Google-DNS“. -- 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
ECS subnet
Hi, I have a setup where I have a BIND resolver behind an unbound resolver. The reason is that when I originally set this up, there was no way to integrate an RPZ feed into unbound. It seems possible now but I haven’t really wanted to try it out…. Of course, this leads to the situation where the actual RPZ-log of the BIND server doesn’t have any other IPs than that of the unbound resolver above it. I thought that with the "send-client-subnet: 127.0.0.1“ configuration in unbound, I could „send“ at least the client subnet to BIND. But is it possible to show this in the logs? Rainer -- 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: ECS subnet
> Am 14.02.2025 um 17:39 schrieb Greg Choules > : > > Hi. > Is this a question about BIND, or Unbound? > Note the name of the list. No, it’s a question about BIND. If an upstream resolver sends an ECS subnet (it’s in the packet header somewhere, from what I understand) - how can BIND show this in the logs? Rainer -- 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: ECS subnet
> Am 25.02.2025 um 01:06 schrieb Evan Hunt : > > On Tue, Feb 18, 2025 at 08:40:53AM +0100, Rainer Duffner wrote: >>> ECS is not supported in the open source version of BIND so I guess >>> it might not get logged. > > The open source version doesn't *send* client-subnet requests, > or cache the responses differently depending on client-subnet data > included in a response. > > However, it does recognize the option, and it will log it when it > sees it. Turn on query logging and, if there are ECS options present > in responses, you should see things like "[ECS 192.168/16/0]" in the > log. > > I don't know if this is any help to you, though. I don't think I've > understood what you're trying to do. Hi, it turns out, that to use the send-client-subnet option in unbound, it has to be compiled with the „subnetcache“ module - which is apparently not happening by default on FreeBSD. Once I rebuilt unbound with that option and passed the right IP for the downstream-server, the actual source IPs did show up. Thanks a lot for hint! Rainer -- 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: ECS subnet
> Am 17.02.2025 um 18:00 schrieb Petr Špaček : > > ECS is not supported in the open source version of BIND so I guess it might > not get logged. What you can do is enable PROXYv2 support, assuming Unbound > supports it. Unfortunately, it looks like it doesn’t support it sending requests downstream. :-( Rainer-- 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: ECS subnet
> One follow-up question: it seems the IP is not shown in the RPZ log. Can this be adjusted? -- 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
