Re: CNAME and IPv6

[Peter]

On Tue, May 28, 2024 at 09:09:20PM +0200, Marco Moock wrote:
> Am 28.05.2024 um 18:48:38 Uhr schrieb Peter:
> 
> > On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
> 
> > > > Now we add an IPv6 address for 'myhost'. But portforwarding
> > > > doesn't work for IPv6. Instead we are required to use different
> > > > addresses all over, like so:
> > > 
> > > port forwarding would work, but is nasty here. Redirectors like rinetd
> > > can handle that, but I recommend against in this case.
> > 
> > I tried it, and didn't get around the Path MTU discovery: Forward SNMP
> > to one host, HTTP to another - which one then gets the ICMPv6 2.0
> > "message too big"? 
> 
> rinetd manages 2 separate connections and should work with PMTUD.

I'm wondering how it would. The connections are TCP, the PMTU works
via ICMP6. So I would assume, the ICMP "packet too big" message
reaches the host where rinetd runs, is swallowed by the kernel, and
the kernel sets the MTU in it's hostcache. Or something along that
line.
The TCP traffic however gets forwarded by rinetd to the internal
appserver(s) - which never get the message that they should reduce
their MTU.

> Did you use that or another way?

I didn't find that one. I tried two other tools for connection
forwarding, they were unsatisfactory. And then I did things with NPTv6
(which is fun). With NPTv6 I can forward the ICMP alongside with the
connection traffic, and that works - but obviousely to only *one*
internal host.

> PS: I still recommend pointing to the machines that host the stuff
> instead of having a middlebox that might create additional headache
> like improper logging, performance issues. :-)

Absolutely, in any regular business scenario where proper connectivity
is mandatory. But this here is my fancy evaluation site where I can
do all kinds of things that are too ambitioned (or too crazy) for
regular sites. ;) Like routing stuff half around the world for no
reason, Or running clockwork-orange...
yeah, this is clockwork orange: https://dnsviz.net/d/icall.icu/dnssec/
High availability, continuous rollover, changes keys every 4 days -
but then, too obese for normal operations. Anyway, mine is the
longest. :)

Okay, enough of the nonsense. Occasionally I just feel the need to
modestly ask how people would normally solve a task, before I start
hacking something crazy...

Cheerio & greetings,
PMc

P.S. I edited the quote-symbol for You. Hope I'll remember.
-- 
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: CNAME and IPv6

[Peter]

On Tue, May 28, 2024 at 12:25:03PM +0200, Marco Moock wrote:
! Am 28.05.2024 um 12:00:09 Uhr schrieb Peter:
! 
! >   if I understand corrently, the use of CNAME is just a convenience
! > and no technical feature, right?
! 
! It is technical because the query is redirected to the domain listed in
! the CNAME.

Seen that way, yes. Not using CNAME would then even be a load reducing
improvement.

! > Often, the webserver and other applications are not actually
! > running on node 1.2.3.4, but are internally portforwarded to
! > some other node, for various reasons.
! 
! This is bad IPv4 stuff, you should get rid off that ASAP.

Yes, that's the official stance...

! > Now we add an IPv6 address for 'myhost'. But portforwarding
! > doesn't work for IPv6. Instead we are required to use different
! > addresses all over, like so:
! 
! port forwarding would work, but is nasty here. Redirectors like rinetd
! can handle that, but I recommend against in this case.

I tried it, and didn't get around the Path MTU discovery: Forward SNMP
to one host, HTTP to another - which one then gets the ICMPv6 2.0
"message too big"? 

! > So, how would you do it? Is there a nice and elegant way?
! 
! www   CNAME   webserver1
! ftp   CNAME   ftp2
! 
! webserver1A   192.168.0.1
! webserver12001:db8::1
! ftp2  A   172.16.0.1
! ftp2  2001:db8:::1
! 
! That makes it possible to redirect it to the actual machines that runs
! the service.

Okay, looks good. Lets go that way.

Thanks for Your reply!
PMc
-- 
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

CNAME and IPv6

[Peter]

Hello,

  if I understand corrently, the use of CNAME is just a convenience
and no technical feature, right?

In lots of examples on the net, a zonefile for a domain might contain
things similar to this:

  @ORIGIN example.com.
  ..
  myhost   A1.2.3.4
  www  CNAMEmyhost.example.com.
  www1 CNAMEmyhost.example.com.
  someapp  CNAMEmyhost.example.com.
  xyz  CNAMEmyhost.example.com.
  ...

Often, the webserver and other applications are not actually
running on node 1.2.3.4, but are internally portforwarded to
some other node, for various reasons.

Now we add an IPv6 address for 'myhost'. But portforwarding
doesn't work for IPv6. Instead we are required to use different
addresses all over, like so:

NOT CORRECT:
  myhost   A1.2.3.4
  myhost    4321::1
  www  CNAMEmyhost.example.com.
  www   4321::10
  ...

Or, NOT CORRECT:
  myhost   A1.2.3.4
  myhost    4321::1
  internal  4321::10
  www  CNAME4   myhost.example.com.
  www  CNAME6   internal.example.com.
  ...

So, how would you do it? Is there a nice and elegant way?
-- 
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_dlz and views and samba

[Peter Carlson]

As I understand it bind_dlz does not support multiple views, I have to 
following scenario and am trying to figure out how to configure it:


 * Internal (192.168.10.0/24)
 o resolve internal domain xyz.com
 o resolve internal samba domain xyz.lab
 o resolve single address xyz.3cx.us to 192.168.10.25
 * External is resolved by a different server and xyz.3cx.us resolves
   to a public address
 * VPN (10.9.0.0/24)
 o resolve internal domain xyz.com
 o resolve internal samba domain xyz.lab
 o resolve single address xyz.3cx.us via normal public dns or
   alternatively resolve to external address

I initially set this up with views:


    acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; };
    acl vpn   { 10.9.0.0/24; };

    view trusted {
    match-clients { internals; };
    zone "MYDOMAIN.com" IN { type master; file 
"/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
    zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us"; 
allow-update { none; }; };

    };

    view vpn {
    match-clients { vpn; };
    zone "MYDOMAIN.com" IN { type master; file 
"/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };

    };


But this crashes as soon as I add:


dlz "AD DNS Zone" {
 database "dlopen 
/usr/lib/x86_64-linux-gnu/samba/bind9/dlz_bind9_18.so";

};


So I split out DNS from ADDC, configured bind on DC to forward to 
another DNS and setup views there, but that doesnt work either as all 
requests now come from IP of the DC and so the ACLs wont match.


Any ideas how I can accomplish this?

Peter

-- 
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: Switching from rhel base 9.16 to 9.18 copr

[Peter]

On Sun, May 05, 2024 at 06:15:13PM +0200, Luca vom Bruch via bind-users wrote:
! Hello,
! 
! I use bind (stock from alma 9.3) as a nameserver for a webhosting server
! with webmin/virtualmin.
! 
! If I install BIND via copr (RHEL9 and derivatives only offer 9.16 instead of
! 9.18 - I want to experiment with DoT for opportunistic TLS between
! nameservers, upcoming standard  
! RFC 9539 - Unilateral Opportunistic Deployment of Encrypted
! Recursive-to-Authoritative DNS (ietf.org) )
! 
! what are the necessary steps to make isc-bind read the existing config
! files? named.conf in /etc and zones in /var/named?

Don`t know Your OS details, but when I upgraded 9.16 to 9.18 on
FreeBSD, my entire site fell apart and nothing did work anymore.

I found the problem - after I managed to access the respective
system (my ssh utilizes DANE/SSHFP) - that I had to newly write my
config files because all the filesystem pathnames have changed
between 9.16 and 9.18.

So beware.
-- 
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

named 100% utilization

[Peter Carlson]

en-on port 53 { 192.168.10.11; 127.0.0.1; ::1; };

      minimal-responses yes;

      tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";

      };

   administrator@nc1:/etc/bind$ cat named.conf.local
   acl internals { 192.168.10.0/24; 192.168.11.0/24; localhost; };
   acl vpn   { 10.9.0.0/24; };

   view trusted {
    match-clients { internals; };
    allow-recursion { internals; };
    allow-query { "internals"; };
    allow-query-cache { "internals"; };
    recursion yes;

    zone "MYDOMAIN.com" IN { type master; file
   "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
    zone "3cx.us" IN { type master; file "/etc/bind/db.3cx.us";
   allow-update { none; }; };

    zone "localhost" { type master; file "/etc/bind/db.local"; };
    zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127"; };
    zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0"; };
    zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255"; };
   include "/var/lib/samba/bind-dns/named.conf";
   };

   view vpn {
    match-clients { vpn; };
    allow-recursion { vpn; };
    allow-query { "vpn"; };
    allow-query-cache { "vpn"; };
    recursion yes;

    zone "MYDOMAIN.com" IN { type master; file
   "/etc/bind/db.MYDOMAIN.com"; allow-update { none; }; };
   include "/var/lib/samba/bind-dns/named.conf";
   };


Peter
-- 
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: XFR killed by security

[Peter]

On Mon, Mar 04, 2024 at 03:43:48PM +0100, Ondřej Surý wrote:
! > On 4. 3. 2024, at 14:55, Peter  wrote:
! > 
! > I don't find it really surprizing that XFR would contain "multiple
! > RRSIG entries".
! 
! Unfortunately, this is obviously surprising to the vendor of the security 
device. This needs to be fixed there, not here. As for the CVE, you have the 
number that can be used, but here’s the blogpost for reference: 
https://www.isc.org/blogs/2024-bind-security-release/

Thank You, Ondrej, this link shortens my path. This is what I wanted
to know.
So the current version of BIND mitigates the issue, and the somehow
ill-devised security rule can then simply be excluded. Wonderful.

cheerio,
PMc
-- 
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

XFR killed by security

[Peter]

Hi folks,

  a few days ago I apparently lost the beneficence of my zone feeds,
and XFR started to get into timeout.

Looking at the usual culprits I then found this:
   DNS Response containing multiple DNSSEC RRSIG Entries (Algorithm
   14) - Possible CVE-2023-50387 Activity
   [Classification: Detection of a Denial of Service Attack]
   {TCP} 192.0.47.132:53 -> 

I don't find it really surprizing that XFR would contain "multiple
RRSIG entries". But, according to the strategy ("shoot first, ask when
the corpses stack to the ceiling"), this thing just kills the transfers.

So, what is it about? Is it something serious?

cheerio,
PMc
-- 
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: occasional SERVFAIL error

[Peter Davies]

Hi Ludovit,

   It looks like you have two version of the jiscd.sk zone.

host -C jiscd.sk
Nameserver 2001:67c:1bd4:8080::20:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 195.49.191.160:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022501 7200 3600 
604800 86400

Nameserver 2001:67c:1bd4:8080::10:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400

Nameserver 195.49.191.162:
    jiscd.sk has SOA record ns1.gov.sk. gov.sk. 2024022800 7200 3600 
604800 86400



Kind Regards Peter

On 29/02/2024 15.20, Ludovit Koren wrote:


Hi,

occasionally I get the following SERVFAIL error:

dig www.jiscd.sk

; <<>> DiG 9.18.24 <<>> www.jiscd.sk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12207
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 35fe56eb9b5f3f22010065df34b4c313eedf839eac9d (good)
;; QUESTION SECTION:
;www.jiscd.sk.  IN  A

;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 14:27:16 CET 2024
;; MSG SIZE  rcvd: 69



I can get rid of it only after issuing:

rndc flush

Afterwards it works for uncertain time.

Could it be I have a configuration problem of my server (I have prefetch
0 set in options section of my server)? Is it a problem of the
authorized domain server?

Thank you very much.

Regards,

lk


--
Peter Davies

--
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: Stub zones, but secndary?

[Peter]

On Mon, Nov 20, 2023 at 03:30:13PM +1300, Nick Tait via bind-users wrote:
! On 20/11/2023 1:00 pm, Peter wrote:
! > It's tricky. One problem is these are slave zones, they are
! > authoritative and do not work well with DNSSEC.
! 
! I'm curious... What issues did you have with these zones and DNSSEC? I would
! have expected that the signed zones should just work?

Probably they do just work. But then, when I query a
nonexistent domain from a simple root-slave, the answer
carries an AA flag. When I query the same nonexistent
domain from 8.8.8.8, it carries an AD flag.

Also, somewhere in the depths of the ISC docs and tutorials
I found a paper that shows how to setup the root-slave for
DNSSEC so that it does recurse and validate (and that is
from where I started to adapt my config). So likely there is
an issue somewhere.

cheerio,
PMc
-- 
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: Stub zones, but secndary?

[Peter]

ggin'
! zone entryto every friggin' zone entry. I REALLY don't like this.
! 
! I'm wondering whether there's a more elegant way. Like "secondary-hint" zones.
! Have I overlooked something?

Maybe. As You can see, it can be done, but it's a bit weird -
I got the fancy that I want to have all six-way in one running image. ;)
(Originally I just got bored of the SSH known-host files, and to get
rid of these you need DANE/SSHFP and proper DNSSEC.)

cheerio,
Peter
-- 
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

DNS DevRoom at FOSDEM2024 - Call for Participation

[Peter van Dijk]

Hello DNS enthusiasts and other developers,

After four earlier successful and packed DNS devrooms, we are happy to
announce a half-day DNS devroom at FOSDEM 2024.

As with the previous events, we hope to host talks anywhere from
hardcore protocol stuff, to practical sessions for programmers that are
not directly involved with DNS but may have to deal with DNS in their
day to day coding or system administrators responsible for DNS
infrastructure.

We have been allotted a room on Saturday the 3rd of February 2024, the
second half of the day, starting around 13:00 (CET).

If you have something you’d like to share with your fellow developers,
please head to the submission page at https://fosdem.org/submit .

Examples of topics are measuring, monitoring, DNS libraries, anecdotes
on how you’ve (ab)used the DNS, and group discussions of upcoming
technologies.

For the upcoming technologies, we're looking for submissions on
Applications Doing DNS (ADD), SVCB/HTTPS records and applications
thereof, and stub-resolver configuration. Here’s the 2023 schedule, for
your inspiration: https://archive.fosdem.org/2023/schedule/track/dns/ .

We expect to schedule 30 minutes per talk, including questions, but if
you need more or less time, we can discuss this.

The deadline for submissions is December 8th 2023. Reach out to
dns-devroom-mana...@fosdem.org if you run into any trouble.

this CfP lives online at
https://blog.powerdns.com/2023/11/16/fosdem-2024-dns-developer-room-call-for-participation
- any important changes will be posted at least there

See you there!

Cheers,

The FOSDEM 2024 DNS Devroom organizers

-- 
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: Unable to upgrade BIND v9.19.11 on Ubuntu without error

[Peter Davies]

Hi Richard,
  FYI: The BIND 9.19.12 Release Notes contain the following:


Removed Features
...
Zone type delegation-only, and the delegation-only and root-delegation-only 
statements, 
have been removed. Using them is a configuration error.
...

Kind Regards Peter

-
-- 
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: How to make SRV records work with caching resolvers?

[Peter]

Hi,

  In July last year I asked about a problem with an IP telephone
mis-handling the DNS responses (and got the clear answer that the
telephone is to blame).

I quote my original message here:

On Wed, Jul 13, 2022 at 01:06:13PM +0200, Peter wrote:
! My Telco has removed the A record for their VoIP server, and now has
! only SRV data there - which seems not to work properly.
! 
! The SRV data contains various services (SIP via UDP, TCP, secure
! TCP, whatever), and these get individual expiry counters in the
! caching resolver.
! So when a telephone sends a query, the caching resolver will provide
! that data in the "Additional section" - but only those records that
! have not yet expired. 
! 
! If the configured service (the one the telephone should use) is no
! longer contained in the answer (but others are still present), the
! telephone goes offline until all the records have expired and a new
! authoritative query is made.
! 
! The Telco is of no help - they just want to sell their own equipment.
! 
! The telphones (Alcatel) are the usual linux plastic box, and I cannot
! easily hack these. It probably does not behave fully correct, but
! also not fully wrong.
! 
! In BIND/named I didn't find an easy approach to fix the issue - it
! doesn't look like it is supposed to be fixed there. And before I go
! for the more difficult approaches, I would like to ask how this
! is actually supposed to work, at all.

Accidentially reading the docs for 9.18 instead of my 9.16 (which
is differently structured), I found the solution: "minimal-responses".

This does away with the Additional section entirely, so there is no
longer a problem with incomplete data considered as complete by the
client.

The actual issue is slightly different than described above:

The client telephone is expected to query a NAPTR for the SIP server.
That NAPTR provides three records, which should be queried as SRV and
again provide three records each. So in total there are 13 records
(including the finally used A record), and that doesn't fit into
576 bytes.

So, apparently, named/BIND sends only some selection of Additional
records, based on it's own discretion. And that doesn't work with the
broken client. Either /all/ or /nothing/ would work, and
"minimal-responses" enforces the /nothing/ option. 

It seems the problem is now solved.
-- 
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 zone response delay time ?

[Peter van Dijk]

On Fri, 2023-04-07 at 17:27 +0100, Jason Vas Dias wrote:
> 
> *.google-analytics.com A 0.0.0.0
> *.clarity.ms A 0.0.0.0
> *.adtelligent.com A 0.0.0.0
> 
>   (there are over 15,000 entries in it).
> 
>   This serves to speed up my internet accesses about 10 times,
>   normally, and acts great as an ad+spyware site blocker,
>   like a do-it-yourself RBL list.
> 
>   I create a static route at boot-up :
> 
> blackhole 0.0.0.0/8

A /8 blackhole route will not win from the 0.0.0.0/32 "route" (it is
implicit, but you can see it with `ip route get` on Linux) that goes to
your local system.

0.0.0.0 is not the right DNS response here, or almost anywhere. NXDOMAIN
likely fits better.


Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

-- 
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 Process failed during logrotate

[White, Peter]

I had the named process fail this past weekend on two secondaries running BIND 
9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.13. It seems that logrotate.d is calling 
the following script at the time of the failure.

/var/named/data/named.run {
missingok
su named named
create 0644 named named
postrotate
/usr/bin/systemctl reload named.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-chroot.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb.service > /dev/null 2>&1 || true
/usr/bin/systemctl reload named-sdb-chroot.service > /dev/null 2>&1 || 
true
/usr/bin/systemctl reload named-pkcs11.service > /dev/null 2>&1 || true
endscript
}

First of all, is this script part of the normal BIND distribution, or is it 
part of the RHEL 7 distribution? From what I can tell, it is called weekly.

Poring through the BIND logs for the cause of the failure, I came across this. 
Note the server.c:2948 error message and subsequent failure.
19-Mar-2023 03:46:01.908 received control channel command 'reload'
19-Mar-2023 03:46:01.908 loading configuration from '/etc/named.conf'
19-Mar-2023 03:46:01.909 reading built-in trust anchors from file 
'/etc/named.root.key'
19-Mar-2023 03:46:01.909 GeoIP Country (IPv4) (type 1) DB not available
19-Mar-2023 03:46:01.909 GeoIP Country (IPv6) (type 12) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 2) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv4) (type 6) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 30) DB not available
19-Mar-2023 03:46:01.909 GeoIP City (IPv6) (type 31) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 3) DB not available
19-Mar-2023 03:46:01.909 GeoIP Region (type 7) DB not available
19-Mar-2023 03:46:01.909 GeoIP ISP (type 4) DB not available
19-Mar-2023 03:46:01.909 GeoIP Org (type 5) DB not available
19-Mar-2023 03:46:01.909 GeoIP AS (type 9) DB not available
19-Mar-2023 03:46:01.909 GeoIP Domain (type 11) DB not available
19-Mar-2023 03:46:01.909 GeoIP NetSpeed (type 10) DB not available
19-Mar-2023 03:46:01.909 using default UDP/IPv4 port range: [1024, 65535]
19-Mar-2023 03:46:01.909 using default UDP/IPv6 port range: [1024, 65535]
19-Mar-2023 03:46:01.910 sizing zone task pool based on 2 zones
19-Mar-2023 03:46:01.911 ../../../bin/named/server.c:2498: fatal error:
19-Mar-2023 03:46:01.911 RUNTIME_CHECK(tresult == 0) failed
19-Mar-2023 03:46:01.911 exiting (due to fatal error in library)
Looking back a week earlier when the script last run, that server.c error was 
not there.

Any thoughts on what could have caused this on two secondaries? The primary 
reloaded around the same time without incident.

Thanks for your assistance.
-- 
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: dnstab-read with detailed information

[Peter]

On Wed, Mar 15, 2023 at 09:34:40PM +, MAYER Hans wrote:
! 
! 
! Dear All,
! 
! dnstab is a great feature to analyse the details what’s going on. But I think 
there is room for improvement.
! 
! I write the data to a file and once a day I do a log rotate.
! With "dnstab-read FILE | grep IP“ I get basic information about an IP which I 
am looking for.
! Now getting full information required options -p and -y
! In this case „grep“ing isn’t so easy. Options -A can help.
! What I do is, I redirect output to a file and open it with „vi“.
! You can imagine, that this file can become large.
! 
! Are there any other (better) possibilities ?

Yes. Parse the YAML, feed it into a database. Or, use the dnstap
libaries and parse that stuff directly, should be faster, but needs
C coding.

Database finds query and answer and pairs them back together.

From there on everything is possible. You could do data mining
for intrusion detection, i.e. search for anomalies, or whatever.
-- 
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 With Primary Hidden - Clarifying Question from Documentation

[Peter]

On Tue, Jan 17, 2023 at 05:28:57PM -0600, E R wrote:
! I am planning on implementing the current version of BIND to replace the
! aging, undocumented authoritative servers I inherited.  I want to hide the
! primary server on our internal network and have two secondary servers be
! publicly available.  While reading the DNSSEC Guide
!  recipes
! it seems to imply that I cannot have a hidden primary that handles all the
! DNSSEC stuff.
! 
! Does the primary server that handles the DNSSEC duties not be hidden?  Or
! were they just illustrating that you do not need to touch your hidden
! primary server and just add one that does the DNSSEC duties?

In fact, none of them needs to.
I for my part have two publicly visible servers, plus a hidden
primary, and the DNSSEC stuff is entirely separated from all of them;
that happens in a vault, no network connection, signed e-mail in and
out only (I don't want to bother with a hw crypto device).

Obviousely, YMMV, it depends on the tools You use to maintain your
zones.

cheers,
PMc
-- 
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: RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[Peter]

On Thu, Dec 29, 2022 at 03:43:35PM -0500, Timothe Litt wrote:

! So much like DNSSEC itself, the technology is there, but the will to use it
! everywhere it's needed is not.

Timothy, thank You for the update. I agree to Your viewpoints, and we
have seen mostly the same with IPv6. Apparently it needs serious pain to
move something in technology that is mostly invisible to the common
user. (OTOH we can see new collaboration tools or javascript
frameworks every day.)

PMc
-- 
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

RFC7344 (was: Funky Key Tag in AWS Route53 (2))

[Peter]

On Thu, Dec 29, 2022 at 09:17:26AM -0500, Timothe Litt wrote:

! (Manual processes
! are error-prone.  That getting registrars to adopt CDS/CDNSKEY - RFC7344 -
! has been so slow is unfortunate.)

Seconded. Do You have information about this moving at all? Because to
me it looks very much like dead-in-the-water, and my registrar didn't
even know what that is.

Otherwise I would have perfect automation for continuous rollover -
but still I have to either hack the data into their webinterface, or
figure out what kind of crappy api they might have - and in my view the
first option is boring and the second is superfluous work.

cheerio,
PMc
-- 
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

Containerizing BIND with Kubernetes

[White, Peter]

Is there any good source of documentation on containerizing an authoritative 
BIND instance in a Kubernetes cluster?

The main part I’m trying to grasp is how to dynamically horizontally scale the 
cluster and keep the BIND notify process working between the containers.

Thanks,
Peter
-- 
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

New BIND Releases are available: 9.16.35, 9.18.9, and 9.19.7

[Peter Davies]

 Our November maintenance releases of BIND are available and can be
downloaded from the ISC software download page, https://www.isc.org/download

A summary of significant changes in the new releases can be found in
their release notes:

current supported stable branches:

   9.16.35 -
https://downloads.isc.org/isc/bind9/9.16.35/doc/arm/html/notes.html

   9.18.9 -
https://downloads.isc.org/isc/bind9/9.18.9/doc/arm/html/notes.html

experimental development branch:

   9.19.7 -
https://downloads.isc.org/isc/bind9/9.19.7/doc/arm/html/notes.html

---

We recommend users contemplating moving from the EOL BIND 9.11
branch to the BIND 9.16 branch read the following document:

https://kb.isc.org/docs/changes-to-be-aware-of-when-moving-from-911-to-916

--
Peter Davies
ISC Support

--
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: Question about dnstap

[Peter]

On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote:
! On 12. 09. 22 15:49, Peter wrote:
! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! > ! My testing did not uncover anything problematic.
! > !
! > ! Versions:
! > ! fstrm 0.6.1-1
! > ! protobuf 21.5-1
! > ! protobuf-c 1.4.1-1
! > !
! > !
! > ! A procedure which works:
! > ! - start BIND configured with
! > ! options {
! > !   dnstap { all; };
! > !   dnstap-output unix "/tmp/unix";
! > ! };
! > !
! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u 
/tmp/unix
! > ! -w /tmp/capture
! > !
! > ! - fire couple queries: sleep 6 && dig bla example
! > !
! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y 
/tmp/cature
! > 
! > Negative. Does not work here:
! > 
! > /tmp # ls -la capture
! > -rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
! > /tmp # dnstap-read -y /tmp/capture
! > /tmp # named -V
! > BIND 9.16.30 (Extended Support Version) 
! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
! 
! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are
! able to reproduce the problem you describe.

Okay, thank You for checking. I didn't look into the matter since I
got my things working nevertheless.
It looks a bit different now as not only me is experiencing the
behaviour.

! There is a caveat, though: Without the --split interval option one has to
! terminate fstrm_capture to get data for dnstap-read to consume. That's
! probably by design and outside of our control (in libfstrm).

This would then happen no matter if fstrm_capture is started before or
after named.


Let's have a short look.
truss tells me that named is trying to open the socket, and receives
ECONNREFUSED.
Then, after every 5 seconds (just as the docs say) it tries again, but
now it receives EPERM !

Apparently, the first connect() happens (after chroot but) before
droppings priviledges.
(The FreeBSD integration script does set -u to UID "bind", by default.)

So, apparently, fstrm_capture should also run as UID "bind" (and would
then need a proper filespace where it is allowed to create that
socket). Or something else along that line.

The OP should check if their problem suddenly resolves when doing a
"chmod 777" on that socket (and then devise a suitable design
according to their security policy).

It's a joy to work with you folks, as always. :)

-- PMc
-- 
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: Question about dnstap

[Peter]

On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
! 
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
! 
! 
! A procedure which works:
! - start BIND configured with
! options {
!   dnstap { all; };
!   dnstap-output unix "/tmp/unix";
! };
! 
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
! 
! - fire couple queries: sleep 6 && dig bla example
! 
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature

Negative. Does not work here:

/tmp # ls -la capture
-rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version) 
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
built by make with '--disable-linux-caps' '--localstatedir=/var' 
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--without-python' 
'--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib 
-ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' 
'--disable-geoip' '--without-maxminddb' '--with-gssapi=/usr' 
'CFLAGS=-I/usr/include -O2 -pipe -march=haswell -DLIBICONV_PLUG 
-fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 
'LDFLAGS= -fstack-protector-strong ' 'LIBS=-lkrb5 -lgssapi -lgssapi_krb5 
-L/usr/local/lib' 'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local' 
'--without-json-c' '--disable-largefile' '--without-lmdb' 
'--disable-native-pkcs11' '--enable-querytrace' '--enable-tcp-fastopen' 
'--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.1' 
'build_alias=amd64-portbld-freebsd13.1' 'CC=cc' 'CPPFLAGS=-DLIBICONV_PLUG 
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 
'PKG_CONFIG_LIBDIR=/var/local/ports/usr/ports/dns/bind916/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig'
 'PYTHON=/usr/local/bin/python3.8'
compiled by CLANG FreeBSD Clang 13.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-13.0.0-0-gd7b669b3a303)
compiled with OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
linked to OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads support is enabled


-- 
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: Question about dnstap

[Peter]

On Mon, Sep 12, 2022 at 12:27:25PM +0200, Borja Marcos wrote:

! I am not sure this is intended behavior, or maybe I should file a bug.
! 
! I am doing some tests with dnstap and bind (9.18.6 now but I see the same 
behavior with older 9.18 versions). I am using
! dnstap-go.
! 
! I have configured bind to use dnstap with no other options and using a Unix 
domain socket. (On named.conf, dnstap {all;};).
! 
! If I start named but the dnstap collector is not running it will never try to 
connect. I need to start the dnstap program 
! _before_ starting named. 
! 
! From the named.conf documentation I assumed that bind would retry the dnstap 
connection periodically. (fstrm-reopen-interval).

I don't know if intended or not, but when configuring dnstap I
noticed the same behaviour.

I tried at first to write to a file, but not by any means could I get
the file rotation to work. Then I considered writing to a file that is
a named pipe - but that would require the reading program to reopen
whenever named might be restarted. Finally I resorted to the socket,
and noticed that the reader program now must not be restarted while
named is running.
I can live with that.

bind916-9.16.30
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
(Probably slightly lower versions at the time of testing.)

FreeBSD 13.1-RELEASE-p2, w/ some patches, all ports locally built,
build logs available on request.
(Maybe FreeBSD 12.3 at the time of testing.)
-- 
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: isc python module

[White, Peter]

I don’t mean to hijack the thread, but I think this is related. I also use the 
BIND python modules. In particular, I'm using it to update my catalog zones as 
described here: https://kb.isc.org/docs/aa-01401

This document has several references to BIND 9.18 without any mention of the 
BIND python module being deprecated. What am I missing? I hope this helps...

On 8/16/22, 8:12 AM, "bind-users on behalf of Petr Špaček" 
 wrote:

On 16. 08. 22 12:46, BÖSCH Christian wrote:
>  >> So my question is whether the isc python module no longer exists, 
and
>  >> whether there is an alternative?
>  >
>  > Please see release notes for 9.18.0, section Removed Features:
>  >
>  >https://bind9.readthedocs.io/en/v9_18_5/notes.html#removed-features
>  >
>  > Besides other things it links to copy of the library, (which is 
formally
>  > not supported outside of BIND 9.16, to be clear).
> 
>  Correcting myself:
>  The isc Python module is formally supported only as part of BIND 9.16
>  codebase.
> 
> Thanks Petr for your response.
> And if the module is no longer supported is there no replacement or any 
other possibility
> to deal with ansible or scripting the rndc commands?

I'm not sure what "deal with Ansible" exactly mean :-) ISC does not and 
did not provide an Ansible module, I believe, so in that respect nothing 
has changed - use whatever third party software you were using before.

The rndc protocol is not evolving at the moment, so it should be 
unlikely we break the compatibility in near future.

Does it answer your question?

-- 
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

-- 
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

[Peter]

I see a two-fold issue with DNSSEC:

1. The wide-spread tutorials seem to explain a key rollover as an
   exceptional activity, a *change* that is infrequently done. And
   changes, specifically the infrequent ones, bring along the
   possibility of failure, mostly due to human error.

   I don't see reason why this is so. DNSSEC can be fully
   automated (mine is), and then it can be done frequently, and the
   human factor is out of the loop. It is then no longer a change,
   but a regular operation that happens every 
   without anybody even need noticing it.
   (Let'sEncrypt did the same for certificates, and that also works
   well.)

2. TCP seems still to be considered a second-class-citizen in the
   DNS world. (If I got the details right, TCP is only "optional",
   and must only be tried as a second choice after receiving TC.)
   So people may be induced to try and squeeze replies into whatever
   512 or 1280 or 1500 bytes. Which means, they probably cannot use
   more than one key, and so take possible redundancy out of the game.

   I do not currently know about how or where this issue could be
   tackled appropriately; I for my part have decided to happily ignore
   it, and am using *four* KSK, thereby supporting RFC 5011 and RFC
   7344, all with one simple script - and anyway now I have the longest;
   here you can see it in action: https://dnsviz.net/d/daemon.contact/dnssec/
   Let's see where this leads into problems; for now it appears not to.

-- PMc
-- 
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 signing of an internal zone gains nothing (unless??)

[Peter]

On Wed, Aug 03, 2022 at 04:49:35PM +1000, Mark Andrews wrote:
! Additionally authoritative servers for a zone are supposed to answer queries 
with RD=1 set with RA=0 if the client is not being offered recursion.  REFUSED 
is the wrong answer of the query name involves zones you serve. Only if you are 
a recursive only server should you be considering REFUSED. 

I am seeing queries for example.com (literally). I didn't talk about
people querying my own domains. Those seem to get their answer, plus
"recursion desired but ..."

-- PMc
-- 
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 signing of an internal zone gains nothing (unless??)

[Peter]

On Tue, Aug 02, 2022 at 02:04:22PM -0400, Timothe Litt wrote:   
! On 02-Aug-22 13:18, Peter wrote:  
! > On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:   
! > !   
! > ! On 02-Aug-22 11:09,bind-users-requ...@lists.isc.org  wrote:   
! > !   
! > ! > | Before your authoritative view, define a recursive view with the 
internal   
! > ! > ! zones defined as static-stub, match-recursive-only "yes",  and a  
! > ! > ! server-address of localhost.  
! > ! > 
! > ! > Uh? Why before? 
! > !   
! > ! Because each request attempts to match the views in order.  You want the  
! > ! stub view to match recursive requests.  The non-RD requests will fall thru
! > ! to the internal zone and get the authoritative data.  
! > 
! > Ahh, I see. But this does not work so well for me, because I have the   
! > public authoritative server also in the same process. And from the  
! > Internet will come requests with RD flag set, and these must get a  
! > REFUSED ("recursion desired but not available").
! > 
! > So I considered it too dangerous to select views depending on the RD
! > flag being present or not, and resolve this with a slightly different   
! > ordering of the views.  
! > 
! > -- PMc  
!   
! Order matters, and changing it will change behaviors. 

That is obvious.

! The server doesn't select ONLY on the RD flag.  It also selects on IP address 
!and/or TSIG keys.  The RD flag is only used to select between the recursive and
!authoritative view pairs for MATCHING CLIENTS. 

Fine.   

! So you should order the views as I showed.

That's not going to work with me. I posted the description of   
my approach, so either you provide evidence of why my logic is  
flawed, or You stop telling me that I should obey You.  

I devised my logic, and it is well possible that it is flawed,  
but if so, then I want to understand the exact flaw, and learn  
and improve.

! The public clients will fail the "match-clients" clause of the internal views 
!regardless of the RD because of their IP addresses.  They will fall thru to the
!r-external view.  That will also fail unless they are listed clients.  So  
!again, they fall thru to the external view.  That has recursion no - which 
!means that RD will return REFUSED. 

Fine. Same here.

! The only danger comes from failing to properly setup the client matching ACLs,
!or from making changes to the logic without understanding how it works.

Mistakes can happen, e.g. when in a hurry.  
   

Re: Stopping ddos

[Peter]

On Tue, Aug 02, 2022 at 11:16:15PM +0200, Michael De Roover wrote:
! For my servers I'm using iptables rules to achieve ratelimiting. They
! look as follows:
! -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --
! update --seconds 600 --hitcount 4 --name DEFAULT --mask 255.255.255.255
! --rsource -j DROP
! -A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent --set
! --name DEFAULT --mask 255.255.255.255 --rsource
! 
! It should be fairly trivial to convert these to use UDP 53, and tweak
! the timings you want. These rules are intended to allow 4 connections
! (which normally should be entire SMTP transactions) every 10 minutes.
! Since I have 2 edge nodes with these rules, that is doubled to 8
! connections total. If you're an authoritative name server only,
! realistically mostly recursors / caching servers would query your
! servers and not too often. You can easily restrict traffic here. If
! you're a recursor too, this becomes a bit more complicated.

Just to give a Heads Up:

I have a very similar config in IPFW protecting port 53 with a rate
limit. I had put that in because the option was there and I thought
it a good idea, and then entirely forgotten about it.

I was then very surprized when I couldn't renew my certificates due
to creepy and non-reproducible failures. A CA cen send quite an amount
of queries when validating a site, and may have tough timeouts.
I recommend testing such a rate-limit against DNSviz.net which also
sends a high amount of queries.

(My actual fault was to forget about the limit, otherwise one could
just remove it temporarily during such actions.)

-- PMc
-- 
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: bind-users Digest, Vol 4031, Issue 3

[Peter]

On Tue, Aug 02, 2022 at 11:54:02AM -0400, Timothe Litt wrote:
! 
! On 02-Aug-22 11:09, bind-users-requ...@lists.isc.org wrote:
! 
! > | Before your authoritative view, define a recursive view with the internal
! > ! zones defined as static-stub, match-recursive-only "yes",  and a
! > ! server-address of localhost.
! > 
! > Uh? Why before?
! 
! Because each request attempts to match the views in order.  You want the
! stub view to match recursive requests.  The non-RD requests will fall thru
! to the internal zone and get the authoritative data. 

Ahh, I see. But this does not work so well for me, because I have the
public authoritative server also in the same process. And from the
Internet will come requests with RD flag set, and these must get a
REFUSED ("recursion desired but not available").

So I considered it too dangerous to select views depending on the RD
flag being present or not, and resolve this with a slightly different
ordering of the views.

-- PMc
-- 
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 signing of an internal zone gains nothing (unless??)

[Peter]

On Tue, Aug 02, 2022 at 05:51:28AM -0400, Timothe Litt wrote:

! You can get the AD flag set, with a bit of extra work.  I've done this for
! years.

Thanks for Your message, Timothe.
After investigating the matter, I had figured out a similar approach -
but didn't know if this is a recommended or commonly used way. There
is only a paper somewhere in the depths of ISC describing how to do
that for a root-slave. Anyway, it appears to work.
I finally created 6-way servers by using some extra addresses on lo0
(auth+recursing for root+intranet+public) and then found the result
suitable structured and maintainable.

! Before your authoritative view, define a recursive view with the internal
! zones defined as static-stub, match-recursive-only "yes",  and a
! server-address of localhost. 

Uh? Why before?

My approach so far:

view "rootslave" {
match-clients { fdff::1; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "intraslave" {
match-clients { fdff::2; key "slave1"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "extraslave" {
match-clients { key "slave1extra"; };
allow-query-cache { none; };
allow-recursion { none; };
recursion no;

};
view "guest" {// public WLAN etc.
match-clients { ... };

// not yet deployed, needs clarification
};
view "desktop" {// user devices
match-clients { ... };



};
view "intra" {
match-clients {  };


};
view "public" {   // external sites allowed to use recursing
match-clients { ... } ;
// not yet deployed, needs evaluation
};
view "external" { // fall-through
match-clients { any; } ;
allow-query-cache { none; };
allow-recursion { none; };
recursion no;
zone "." {   // is this necessary? (something didn't work without)
type hint;
file "/usr/local/etc/namedb/named.root";
};

};


Sure this could also be done by running 2 or 3 instances, and probably
more safe - but where would be the fun then?


-- PMc
-- 
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: Bind 9.11/RHEL7 Server Freezes FUTEX_WAKE_PRIVATE

[White, Peter]

Greg, What other awesome stuff do you have on the top of your head? This makes 
sense as it’s running on EC2 @AWS (I.e. poor source of randomness on VM’s).

And thanks to Grant for the haveged suggestion.  Initial tests with haveged 
running seem to be positive.

I’ll report back here if the problem continues.

Thanks so much for your help!


From: Greg Choules 
Date: Monday, August 1, 2022 at 6:21 PM
To: White, Peter 
Cc: bind-users@lists.isc.org 
Subject: Re: Bind 9.11/RHEL7 Server Freezes FUTEX_WAKE_PRIVATE
CAUTION: This email originated from outside of Penguin Random House. Please be 
extra cautious when opening file attachments or clicking on links.

Hi Peter.
Off the top of my head, could it be this?

random-device

The source of entropy to be used by the server. Entropy is primarily needed for 
DNSSEC operations, such as TKEY transactions and dynamic update of signed 
zones. This options specifies the device (or file) from which to read entropy. 
If this is a file, operations re- quiring entropy will fail when the file has 
been exhausted. If not specified, the default value is /dev/random (or 
equivalent) when present, and none otherwise. The random- device option takes 
effect during the initial configuration load at server startup time and is 
ignored on subsequent reloads.

BIND will need a good source of randomness for crypto operations.

Cheers, Greg

On Mon, 1 Aug 2022 at 23:08, White, Peter 
mailto:pwh...@penguinrandomhouse.com>> wrote:

I’m running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 (Extended Support 
Version) on RHEL 7 in a chroot jail.

As of late, at times running some rndc commands are causing my server to lock 
up. It’s usually an “rndc addzone” that triggers the issue. I’ll also mention 
that I have recently started signing some domains with DNSSEC, so I suspect it 
may be somehow related.

Here is an example of a command that frequently triggers my issue, although it 
doesn’t trigger it every time.

rndc addzone '"example.com<http://example.com>" in external {type master; file 
"dnssec/example.com<http://example.com>";key-directory "keys"; auto-dnssec 
maintain; inline-signing yes;};'

During these times, named will not respond to any rndc commands, nothing is 
logged to the bind logs (I’m running trace level 3 ), and will not answer 
queries. Everything seems just frozen in time. Waiting for a period of time, 
varying from a few seconds to many minutes, the server picks back up again and 
operates normally. The following are my observations to this point.

CPU and memory show as being fine.


top - 17:57:37 up 33 min,  3 users,  load average: 0.00, 0.01, 0.05

Tasks: 125 total,   2 running, 123 sleeping,   0 stopped,   0 zombie

%Cpu(s):  0.2 us,  0.3 sy,  0.0 ni, 98.5 id,  0.0 wa,  0.0 hi,  0.0 si,  1.0 s

KiB Mem :  1842956 total,   439452 free,   665760 used,   737744 buff/cache

KiB Swap:  8384508 total,  8384508 free,0 used.  1013652 avail Mem

Strace shows the following over and over again.


strace -p 1156 -f



[pid  1159] futex(0x7fc1c15a307c, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 16657, {tv_sec=1659390139, 
tv_nsec=25586}, 0x) = -1 ETIMEDOUT (Connection timed out)


Any pointers here would be greatly appreciated. I’m about at my wits end with 
this one, and rebuilding this server on a newer build of RHEL or recompiling 
BIND is not a journey that I would like to take at the moment.
--
Visit 
https://lists.isc.org/mailman/listinfo/bind-users<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/<https://www.isc.org/contact/> for 
more information.


bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users<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

Bind 9.11/RHEL7 Server Freezes FUTEX_WAKE_PRIVATE

[White, Peter]

I’m running BIND 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 (Extended Support 
Version) on RHEL 7 in a chroot jail.

As of late, at times running some rndc commands are causing my server to lock 
up. It’s usually an “rndc addzone” that triggers the issue. I’ll also mention 
that I have recently started signing some domains with DNSSEC, so I suspect it 
may be somehow related.

Here is an example of a command that frequently triggers my issue, although it 
doesn’t trigger it every time.

rndc addzone '"example.com" in external {type master; file 
"dnssec/example.com";key-directory "keys"; auto-dnssec maintain; inline-signing 
yes;};'

During these times, named will not respond to any rndc commands, nothing is 
logged to the bind logs (I’m running trace level 3 ), and will not answer 
queries. Everything seems just frozen in time. Waiting for a period of time, 
varying from a few seconds to many minutes, the server picks back up again and 
operates normally. The following are my observations to this point.

CPU and memory show as being fine.


top - 17:57:37 up 33 min,  3 users,  load average: 0.00, 0.01, 0.05

Tasks: 125 total,   2 running, 123 sleeping,   0 stopped,   0 zombie

%Cpu(s):  0.2 us,  0.3 sy,  0.0 ni, 98.5 id,  0.0 wa,  0.0 hi,  0.0 si,  1.0 s

KiB Mem :  1842956 total,   439452 free,   665760 used,   737744 buff/cache

KiB Swap:  8384508 total,  8384508 free,0 used.  1013652 avail Mem

Strace shows the following over and over again.


strace -p 1156 -f



[pid  1159] futex(0x7fc1c15a307c, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 16657, {tv_sec=1659390139, 
tv_nsec=25586}, 0x) = -1 ETIMEDOUT (Connection timed out)


Any pointers here would be greatly appreciated. I’m about at my wits end with 
this one, and rebuilding this server on a newer build of RHEL or recompiling 
BIND is not a journey that I would like to take at the moment.
-- 
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: How to make SRV records work with caching resolvers?

[Peter]

On Thu, Jul 14, 2022 at 06:22:47PM +0200, Ondřej Surý wrote:
! Could you for the purpose of the debugging share the DNS traffic between the 
phone device and the resolver?
! 
! I think stepping back a little might help debug the issue. Perhaps people on 
the list might notice something that might help.
! 
! Ondrej

Hi Ondrej,

thanks for Your reply. I tried to obtain something reproducible, but
with no luck. These failures are a bit difficult to catch, they happen
mostly deep at night, for whatever reason. (And in any case a reset of
the phone does fix the issue.) Once I tried to analyze the failure and
noticed the partial information in the additional section, as
described - so I thought I had identified the issue (and should
occasionally learn how this should actually work - as I did now).

Now when I log the entire DNS traffic, I don't see the same pattern
appearing again. (Obviousely there can be many other reasons for a
temporary outage.)
The plan is now to put this on hold until it appears at annoying daytimes
again, and ideally obtain a kind of VoIP-proxy or PBX to put in between.

-- PMc


! > On 13. 7. 2022, at 13:18, Peter  wrote:
! > 
! > 
! > My Telco has removed the A record for their VoIP server, and now has
! > only SRV data there - which seems not to work properly.
! > 
! > The SRV data contains various services (SIP via UDP, TCP, secure
! > TCP, whatever), and these get individual expiry counters in the
! > caching resolver.
! > So when a telephone sends a query, the caching resolver will provide
! > that data in the "Additional section" - but only those records that
! > have not yet expired. 
! > 
! > If the configured service (the one the telephone should use) is no
! > longer contained in the answer (but others are still present), the
! > telephone goes offline until all the records have expired and a new
! > authoritative query is made.
! > 
! > The Telco is of no help - they just want to sell their own equipment.
! > 
! > The telphones (Alcatel) are the usual linux plastic box, and I cannot
! > easily hack these. It probably does not behave fully correct, but
! > also not fully wrong.
! > 
! > In BIND/named I didn't find an easy approach to fix the issue - it
! > doesn't look like it is supposed to be fixed there. And before I go
! > for the more difficult approaches, I would like to ask how this
! > is actually supposed to work, at all.
! > 
! > 
! > -- PMc
! > -- 
! > 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: How to make SRV records work with caching resolvers?

[Peter]

On Wed, Jul 13, 2022 at 09:22:17PM +1000, Mark Andrews wrote:
! The client is supposed to lookup missing address records.

Now that's clear and short. Thank You very much, Mark!

! Complain to the supplier of the phone that they have a defective product.

I still have to see a linux plastic box without such flaws... And yes,
You're right, that would be the way to go when running a 3+ digit
unit-count of these phones. But now as I know who is to blame, I can
think about an interim workaround.


-- PMc
-- 
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

How to make SRV records work with caching resolvers?

[Peter]

My Telco has removed the A record for their VoIP server, and now has
only SRV data there - which seems not to work properly.

The SRV data contains various services (SIP via UDP, TCP, secure
TCP, whatever), and these get individual expiry counters in the
caching resolver.
So when a telephone sends a query, the caching resolver will provide
that data in the "Additional section" - but only those records that
have not yet expired. 

If the configured service (the one the telephone should use) is no
longer contained in the answer (but others are still present), the
telephone goes offline until all the records have expired and a new
authoritative query is made.

The Telco is of no help - they just want to sell their own equipment.

The telphones (Alcatel) are the usual linux plastic box, and I cannot
easily hack these. It probably does not behave fully correct, but
also not fully wrong.

In BIND/named I didn't find an easy approach to fix the issue - it
doesn't look like it is supposed to be fixed there. And before I go
for the more difficult approaches, I would like to ask how this
is actually supposed to work, at all.


-- PMc
-- 
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

IPv6 scoped address disambiguation

[Peter]

Hi @all,

 the reference manual says something about scoped ipv6 addresses,
so I might assume they are understood and useable. But maybe either
I did misunderstand something, or something is wrong here:

My configuration:

listen-on-v6 port 53{ fe80::2%lo0;
  fe80::3%lo0; };

This is what I have:

# ifconfig | grep fe80
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 fe80::2%lo0 prefixlen 128 scopeid 0x3
inet6 fe80::3%lo0 prefixlen 128 scopeid 0x3
inet6 fe80::2%tun0 prefixlen 124 scopeid 0x5
inet6 fe80::2%tun1 prefixlen 124 scopeid 0x6

And this is what I get when starting named:

# netstat -an6 | grep "fe80.*53.*LISTEN"

tcp6   0  0 fe80::2%tun1.53*.*LISTEN 
tcp6   0  0 fe80::2%tun0.53*.*LISTEN 
tcp6   0  0 fe80::3%lo0.53 *.*LISTEN 
tcp6   0  0 fe80::2%lo0.53 *.*LISTEN 

I didn't expect the %tun0 and %tun1 to appear here.
Am I missing some necessary quoting in the address string?

My version:

BIND 9.16.29 (Extended Support Version) 
running on FreeBSD amd64 12.3-RELEASE-p5


-- 
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: Bugfix: missing line in message.c

[Peter]

On Thu, Jun 02, 2022 at 08:23:27AM +1000, Mark Andrews wrote:
! Thanks.
! 
! INDENT is being addressed.
! 
! Can you add an issue on https://gitlab.isc.org/ for the view name in dnstap?

Bad luck for me, my login does actually work there - so I probably
have to... ;)

Done, it says #3391.


-- PMc
-- 
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

Bugfix: missing line in message.c

[Peter]

Hi,

  this is broken in 916 (and apparently 918 also).
Consequentially, output from dnstap gets unreadable (invalid YAML)
when using dynamic zone updates. 

 PATCH 
--- lib/dns/message.c.orig  2022-05-10 11:02:21.0 +0200
+++ lib/dns/message.c   2022-05-30 04:02:40.568222000 +0200
@@ -4296,6 +4296,7 @@
INDENT(style);
ADD_STRING(target, "QUESTION: ");
} else {
+   INDENT(style);
ADD_STRING(target, "ZONE: ");
}
snprintf(buf, sizeof(buf), "%1u",
 PATCH 

And when You'ra at it:
I would very much appreciate when we could get the *view name* into the
dnstap output.

I am running my nameservers as
 * authoritative to the public,
 * authoritative for the LAN,
 * recursing for the LAN (for DNSSEC to work some useful DANE things),
 * authoritative as root slave,
 * recursing as root slave (for DNSSEC to get 'AD' instead of 'AA'),
 * plus a couple of in-between cases,
all in a single process. :)

Obviousely that needs lots of views. I found dnstap to be the perfect
and long desired solution for debugging and understanding what
actually happens, to become even able to create more fancy setups.

But then the view name is needed in the messages. There is an option 
'dnstap-identity (  | none | hostname );'
and putting that into the views would be the natural solution - but
that doesn't work, it gets rejected as a syntax error (for no reason
obvious to me). I tried 918, it gets rejected there also.

So for now I hacked it with a simple approach (because I know my
version anyway, I need only the identity of an instance and the view)
and that works for now:
-   dm->d.version.data = env->version.base;
-   dm->d.version.len = env->version.length;
+   dm->d.version.data = (uint8_t *)(view->name);
+   dm->d.version.len = strlen(view->name);

But this is ugly as it computes strlen() on every call. I could do it
nicer, but then I think the beforementioned option should be made
working instead.


-- PMc
-- 
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 traffic tracking

[Peter Coghlan]

Alex K wrote:
>On Mon, May 9, 2022 at 2:46 PM Bjørn Mork  wrote:
>>
>> FWIW I agree with the rate-limit recommendation.  It solves both this
>> and your original problem without any complicated and messy tracking.
>> Just make DNS "free" up to some reasonable query rate.  If there are
>> clients with higher legitimate needs, then you could consider creating
>> separate rate-limit classes for those clients.  And even charge extra
>> for that, if it's important.
>>
> Does such DNS traffic has different characteristics from the normal one?
> Perhaps, apart from limiting, I could block such traffic with the packet
> size or similar.
>

In a different message you said "I see sometime 700MB of DNS traffic for
2GB of Internet browsing within one month."  This seems like a huge figure
and it suggests that something very undesirable is happening somewhere.

If you are counting traffic between your client's resolvers and their
nearest caching nameserver, perhaps adding caching nameservers closer to
or at your client's sites would be helpful?

Maybe someone is attacking your clients with lots of bogus DNS queries?

Maybe some of your clients have been infected with malware and are
attacking the rest of the world with lots of bogus DNS queries?

Someone else suggested your clients could be doing IP over DNS.

Maybe something else we haven't thought of is happening?

Rather than speculating as to what is the cause of this huge figure
for DNS traffic, or trying to generate and analyse logs which may or
may not cover the traffic in question, I would suggest doing some
packet sniffing with tcpdump or wireshark or whatever works in your
environment and figuring out exactly what the traffic is and getting
a better idea of who is responsible for generating it and why.

In my opinion, in the absence of knowing what the problem is,
experimenting with stuff like rate limiting or blocking is unlikely
to solve the problem.

Regards,
Peter Coghlan.
-- 
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: getting answers from DNS queries

[Peter Coghlan]

>
> I asked this last week, but I didn't an answer. Who can I tell if a DNS
> query is refused or answered? Is it in the log files? Can a compile-time
> option help me access it? Sorry to repeat but I really need to know this.
>
> Thank in advance.
>

Hi Hal,

I saw at least one reply to your query on the mailing list.  However, I
don't think it really answered your question.

I also sent you a private email reply which you don't appear to have seen.
Maybe check if anything has been stopped by an antispam system?

My experience is there is little interest here in dealing with the subject
of malicious, bogus queries etc.

Regards,
Peter Coghlan.

>
> --
> 
> Hal King  - h...@utk.edu
> Systems Administrator
> Office of Information Technology
> Shared Services
> 
> The University of Tennessee
> 103c5 Kingston Pike Building
> 2309 Kingston Pk. Knoxville, TN 37996
> Phone: 974-1599
> [cid:00350bec-9764-4740-8d61-e8bec49334bc]
-- 
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

9.18.0 now available

[Peter Davies]

For those of you that may not be on the -announce list, I
would like to make you aware of the following:

https://lists.isc.org/pipermail/bind-announce/2022-January/001205.html

--
Peter Davies
Support Engineer
Internet Systems Corporation
pet...@isc.org
001 650-423-1460

___
Please 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: Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

[Peter]

On Sun, Nov 21, 2021 at 06:51:13PM +0100, Sten Carlsen wrote:
! As far as I am aware - and what I have always done - the normal
| thing to do is to use a hints file. Lately the hints are built-in,
| so nothing is really needed.

Ah. Well, I have here a named.conf.sample file that comes with the
distribution, and that shows both ways. And it doesn't seem to say
that one of them would be "normal".

! One question that comes to mind:
! What happens if the slaved root zones are not up to date /not
! correct?

Hm. It depends. When they are not up to date, the question is WHERE
are they not up to date, and why?
When they are not correct - since these are digitally signed
zonefiles, they must be identical everywhere. So if they are not
correct, then I think the Internet has a problem.

Anyway, as long as the roots let me xfer, I do xfer. For me it has a
few advantages: 1. a baseline of proven functionality: xfers do work.
2. I always have a syntactically correct example zonefile on file. 3.
I have them in the backup and can easily see when something was changed.

! might that be the cause?

No. These files are checked/updated about every 15 minutes, and I have
not had any problem with them in more than a decade.
And this error message appears only and exactly once at server start,
no matter if or when these zonefiles have been fetched before.

So, I've just updated OS, so let's have a look at the logs:

Nov 21 17:07:58  pole named[1771]: general: info: shutting down: 
flushing changes
Nov 21 17:07:58  pole named[1771]: general: notice: stopping 
command channel on 127.0.0.1#953
Nov 21 17:07:58  pole named[1771]: general: notice: exiting
Nov 21 18:04:40  pole named[3722]: zoneload: info: 
managed-keys-zone: loaded serial 346
Nov 21 18:04:40  pole named[3722]: dnssec: warning: 
managed-keys-zone: Failed to create fetch for DNSKEY update
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone ./IN: 
loaded serial 2021112100 (DNSSEC signed)
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone 
10.in-addr.arpa/IN: loaded serial 2021080800
Nov 21 18:04:40  pole named[3722]: zoneload: info: zone arpa/IN: 
loaded serial 2021112101 (DNSSEC signed)

So, we can see, at first it opens that "managed-keys-zone"
pseudozone. There it detects that it might query the DNSKEY,
and *fails*. Only *after that* it loads the ./IN & friends.

Now if one looks a bit into the running code, the error number is
65586 ( that's what the error message would show if it would show the
error number. :/ ), and in the source this error is defined as
DNS_R_NOTLOADED.

Now let's look further on. Exactly an hour later this appears:

Nov 21 19:04:40  pole named[3722]: dnssec: info: 
managed-keys-zone: Key 20326 for zone . is now trusted (acceptance timer 
complete)

The question would now be: what does it do in the meantime? Does
it distrust the trust-anchor? That's interesting, because without
trust anchor it would likely need to distrust everything.

Lets try that out: shutdown, restart, see the error - and I still
get the AD bit in TLDs. So it seems to have no troublesome effect.


Now lets make something else clear: I am running these machines
since way back into the last century - when it was common to know
*every file* on your machine, and to read the sourcecode within thse
files - and occasionally to even understand it.
And I hold on to that line, because what we have today is worse.


cheerio, PMc
___
Please 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

Found the bug (was: ERROR: Failed to create fetch for DNSKEY update)

[Peter]

Hija,

  I finally found the cause of the error! As soon as I stop slaving
the root-zones and instead use the (configured or compiled-in)
hint-file, the error stops.

The actual error-condition (zone is not loaded) then becomes
obvious, because this RFC-5011 action happens very early, before
any zones are loaded. And with slaved root-zones instead of a
hint-file, the root zone has to be loaded like the others.

So the flaw is in the initialization sequence.

I don't really see why we would need to do this RFC-5011 so early.
As matters are, it now is failed, postponed, and run an hour later
successfully, and things should work just as well.

So You may now fix the issue, or just continue to spamblock the
bugreports (which is a great scheme to get error-free software, btw).

cheerio,
PMc
___
Please 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: ERROR: Failed to create fetch for DNSKEY update

[Peter]

On Mon, Nov 15, 2021 at 09:14:19AM +0100, Ondřej Surý wrote:
! > On 15. 11. 2021, at 3:41, Peter  wrote:   
 
! > 
! > Wondering   
! > * WHAT is broken?   
! > * Why does it happen only to me?
!   
! We can’t really help you if you don’t share any details of your installation  
! and configuration (hint: You can use `named-checkconf -px` to scrub the   
! configuration).   
!
! So far, you shared a **single line** from the log and nothing else.   


Yes, certainly, since You do not allow more to be sent.


When I try to send log or config data, I only get this in reply:


   - The following addresses had permanent fatal errors -   

(reason: 550 5.7.1 Blocked by SpamAssassin) 
  
(reason: 550 5.7.1 Blocked by SpamAssassin) 

   - Transcript of session follows -
... while talking to mx.pao1.isc.org.:  
>>> DATA
<<< 550 5.7.1 Blocked by SpamAssassin   
554 5.0.0 Service unavailable   


cheerio,
PMc
___
Please 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

ERROR: Failed to create fetch for DNSKEY update

[Peter]

Hi all,

 I continuousely happen to see this message:

> local0.warn named[2291]:
> dnssec: warning: managed-keys-zone: Failed to create fetch for DNSKEY update

I see it on different nameservers, at different sites, with and
without views, with and without IPv6, and I see it every time when
named is restarted.

I couldn't find the message mentioned on google etc.

The docs say DNSSEC for a mere recursive server should work out of the
box with the defaults. Apparently it doesn't, but where could I find a
clue about what my config is missing? (I have nothing at all
configured concerning DNSSEC.)



Other clues failing, I took a look at the source, and I suppose things to
bo like that:

lib/dns/zone.c:zone_refreshkeys()
if (result == ISC_R_SUCCESS) {
fetching = true;
} else {
...skipping...
dnssec_log(zone, ISC_LOG_WARNING,
   "Failed to create fetch for DNSKEY update 
%d", result);

lib/dns/resolver.c:dns_resolver_createfetch()
lib/dns/resolver.c:fctx_create()
lib/dns/view.c:dns_view_findzonecut()

} else if (result != ISC_R_SUCCESS) {
/*
 * Something is broken.
 */

(could have almost imagined that ...)

lib/dns/zone.c:dns_zone_getdb()

if (zone->db == NULL) {
result = DNS_R_NOTLOADED;
-

So this doesn't give a clue either :(


Wondering
 * WHAT is broken?
 * Why does it happen only to me?


Cheerio,
PMc
___
Please 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: BIND caching of nxdomain responses

[Peter van Dijk]

On Fri, 2021-10-22 at 13:22 -0400, Dan Hanks wrote:
> On Fri, Oct 22, 2021 at 9:57 AM Dan Hanks  wrote:
> > Greetings,
> > 
> > As I understand RFC 2308, when receiving an NXDOMAIN response, and when 
> > deciding how long to cache that NXDOMAIN response, a resolver should use 
> > whichever value is lower of the SOA TTL, and the SOA.minimum value as the 
> > length of time to cache the NXDOMAIN.
> 
> I interpret this to mean that an authoritative resolver should set the
> TTL on the SOA record included in the AUTHORITY section of an NXDOMAIN
> response to be the minimum of the zone SOA TTL, and the SOA.minimum
> field. It does not look like Route53 is doing this.

Indeed, Route53 is not doing this, but they should. I spoke to them
about this some time ago, and they do intend to fix it, as far as I
understand.

See also 
https://lists.dns-oarc.net/pipermail/dns-operations/2021-September/021362.html

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
Please 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: Preventing a particular type of nameserver abuse

[Peter Coghlan]

I started this thread back in April in response to high levels of abuse of
my nameserver.  A short summary of the discussion which resulted is that
bind does not provide any way of preventing abuse I was experiencing. (The
abuse was clearly designed to get past any use of rate-limiting to mitigate
it.)

In the last month or so, the level of abuse has declined significantly.
I don't know  whether this is because I have been keeping a very close eye
on traffic incoming to my nameserver and I have been aggressively packet
filtering queries which seem to be probing for the existance of nameservers
to exploit or whether the abuse would have declined anyway without any
intervention by me.  I still see these probes hitting my filters regularly
from some netblocks I have filtered and occasionally they arrive from
addresses I was previously unaware of.  Provided I filter these quickly
when I come across them, the level of abuse seems to stay relatively low,
most of the time.

Today I noticed the traffic below arriving from a netblock I had filtered
many years ago for reasons other than nameserver abuse.  I have never
seen anything like this before arrive at my nameserver.  I would be
interested to know what the experts think bind might have made of this
traffic had it not been filtered out.  I have included some of the more
usual probes before and after the more interesting traffic for context.

Regards,
Peter Coghlan.

09:50:12.36 207.244.251.243.41020 > 192.168.80.24.53:  64379+ A? 
www.hitnslab.cn. (33) (DF) [tos 0x8]
 4508 003d c124 4000 3211 aada cff4 fbf3 E..=.$@.2...
 c0a8 5018 a03c 0035 0029  fb7b 0100 ..P..<.5.)...{..
 0001    0377  0868 6974 .www.hit
 6e73 6c61 6202 636e  0100 01nslab.cn.
09:50:12.36 207.244.251.243.54076 > 192.168.80.24.53:  3073+ A? www.paypal.com. 
(32) (DF) [tos 0x8]
 4508 003c c123 4000 3111 abdc cff4 fbf3 E..<.#@.1...
 c0a8 5018 d33c 0035 0028  0c01 0100 ..P..<.5.(..
 0001    0377  0670 6179 .www.pay
 7061 6c03 636f 6d00 0001 0001   pal.com.

09:57:34.71 104.237.154.253.58759 > 192.168.80.24.53:  18245 updateD 
[b2&3=0x5420] [18516a] [12064q] [21584n] [12081au] (29)
 4500 0039 d431  ef11 e2d6 68ed 9afd E..9.1..h...
 c0a8 5018 e587 0035 0025  4745 5420 ..P5.%..GET
 2f20 4854 5450 2f31 2e31 0d0a 486f 7374 / HTTP/1.1..Host
 3a20  770d 0a0d 0a  : www
09:57:34.72 192.168.80.24.53 > 104.237.154.253.58759:  18245 updateD FormErr- 
[0q] 0/0/0 (12)
 4500 0028 8d61  4011 d8b8 c0a8 5018 E..(.a..@.P.
 68ed 9afd 0035 e587 0014 ee16 4745 d001 h5..GE..
     
09:57:46.16 68.183.137.43.55859 > 192.168.80.24.53:  6+ TXT CHAOS)? 
version.bind. (30) (DF)
 4500 003a 758a 4000 3211 f485 44b7 892b E..:u.@.2...D..+
 c0a8 5018 da33 0035 0026 23eb 0006 0100 ..P..3.5.&#

Failure from rate-limit

[Peter]

Hi,

 my servers fail to query the upstream servers with these errors:
 
rate-limit: debug 99: rrl=0x0, HAVECOOKIE=0, result=DNS_R_SERVFAIL,
fname=0x8027a5450(0), is_zone=0, RECURSIONOK=1, query.rpz_st=0x0(0),
RRL_CHECKED=0

The operator of the upstream servers says it is due to a configuration
mistake. How can this be fixed? I do not have any rate-limit option
configured...

rgds,
PMc
___
Please 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: Without IPv6 half of the queries yield SERVFAIL

[Peter]

On Fri, Aug 06, 2021 at 07:22:32AM +0200, sth...@nethelp.no wrote:
! > ! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
! > ! marking all IPv6 addrs as bogus, but it does not make a difference in
! > ! behaviour.
! > 
! > Update: Actually there is a difference if this recommended
! > configuration is present or not - only the NXDOMAIN outcome is the
! > same in both cases.
! 
! Have you tried:
! 
! listen-on-v6{ none; };

No, I have

listen-on-v6{ ::1; };

And as I understand, this is something different: this is where named
will respond to queries from clients, while my issue is with the
servers named asks when doing recursive resolve.
If anything, then "query-source-v6" would be the appropriate one, but
that doesn't seem to allow "none;".

rgds,
PMc
___
Please 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: Without IPv6 half of the queries yield SERVFAIL

[Peter]

On Thu, Aug 05, 2021 at 11:53:35PM +0200, Peter wrote:

! I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
! marking all IPv6 addrs as bogus, but it does not make a difference in
! behaviour.

Update: Actually there is a difference if this recommended
configuration is present or not - only the NXDOMAIN outcome is the
same in both cases.

WITH this configuration ("server ::/0 { bogus yes; };") I get the
behaviour as described in the previous msg: Resolving will
occasionally fail, depending on the sequence in which the recursive
queries get answered.

WITHOUT this configuration lots of INET6 queries are generated (and
cannot be sent anywhere as there is no IPv6). And then frequently
this error appears:

Aug  6 00:05:51  conr named[5623]: resolver: debug 3:
exceeded max queries resolving 'curitiba.porkbun.com/'
(querycount=101, maxqueries=100)

Now that is something I can understand. :) So, when I put this
into the configuration: "max-recursion-queries 400;", then things
appear to work!
But this is probably not "The Good Way" to solve this (and it fills
the log with all these "lame-servers" errors from the unreachable
IPv6 addresses).

So then, maybe the recommended configuration with
"server ::/0 { bogus yes; };"
is not so really recommendable and rather dangerous? Or mabye it is
somehow misbehaving in this case?

rgds,
PMc
___
Please 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

Without IPv6 half of the queries yield SERVFAIL

[Peter]

Hi all,

  first off: I do not have IPv6 physical connectivity yet, but I would
like to run a nameserver nevertheless.

Sadly, it seems that without IPv6 connectivity, half of the queries
fail, in a random fashion.

There is no clue in the logfile about any reason for this behaviour,
only so much as:

client: error: query client=0x80db45160
   thread=0x80125ba00(pole.daemon.contact/A): query_gotanswer:
   unexpected error: SERVFAIL
query-errors: info: client @0x80db45160 192.168.98.10#17919
   (pole.daemon.contact): view intra: query failed (SERVFAIL)
   for pole.daemon.contact/IN/A at query.c:7376

Increasing the debug level does not give me more insight.

The failure happens randomly, half of the time. (Only after 'rndc flush',
obviousely, so it went undetected at first, taken for a network
hiccup.)

I finally resorted to full dnstap logging, and walked myself thru
the whole orgy of recursive resolving. The outcome:

This name in question, pole.daemon.contact, has four nameservers,
each of them has two IPv4 and one IPv6 addresses.

In the cases when the query is successful, the recursion happens just
as we would expect it: at some point an IP address for one of the four
nameservers is obtained, then from that IP address the desired A
record is queried and obtained, and after a bit more of validation
stuff (probably DNSSEC) the client gets the proper answer.

In the cases when the query yields SERVFAIL, the difference is that
the first arriving answer for one of the nameserver's addresses is an
answer to an  query, not an A query (as mentioned, ther are four
possible nameservers, and each has A and  records). At that point
the client is sent NXDOMAIN, disregarding that the other (A and )
records are just at that moment being received. So the query is fail,
and the service is outage, and it is bad.

The problem appears on different machines, all running FreeBSD 12.2
and BIND 9.16.18.

I tried to use this recommendation, https://kb.isc.org/docs/aa-00206,
marking all IPv6 addrs as bogus, but it does not make a difference in
behaviour.

Is there any means to tell named that we just don't have IPv6
connections yet (which actually should be obvious because there is
not IPv6 address on the interfaces, except for lo0)?

I know I can use -4 cmdline option, but that disables everything,
while I would rather like to slowly and tentatively enter IPv6 (but
on my pace, and not forced by a named insisting in all-or-nothing).
I would rather like named to continue and try the other seven address
options, and not just NXDOMAIN rightaway.


rgds,
PMc
___
Please 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: ITS THE NUMBER OF CORES/THREADS

[Peter via bind-users]

update on how to get bind to run with parameters for windows

make folder in C:\ named

make file called named.bat

in the bat file add:

sc start named -n 7

in services > ISC BIND recovery tab

first failure select run a program

check enable actions for stops with errors

in run program browse for named.bat

apply and now start the services.

___
Please 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: ITS THE NUMBER OF CORES/THREADS

[Peter via bind-users]

Yes I went in services and put in start parameters -n 7 and 9.16.19 
started however a bug in windows means it does not save the parameter at 
least I think it a bug so you have to manually put in -n 7 to start bind.



On 23/07/2021 7:53 pm, Ondřej Surý wrote:

Thanks, having such a simple reproducer is helpful.

Can you try if adding `-n 8` vs `-n 7` have the same effect?

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do 
not feel obligated to reply outside your normal working hours.


On 23. 7. 2021, at 20:31, Peter via bind-users 
 wrote:


 Well I reported it and we see what happens my main bind is not in a 
virtual machine I guess I cound disbale Hyper-Threading as a 
workaround...

___
Please 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



___
Please 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: ITS THE NUMBER OF CORES/THREADS

[Peter via bind-users]

Well I reported it and we see what happens my main bind is not in a 
virtual machine I guess I cound disbale Hyper-Threading as a workaround...
___
Please 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

ITS THE NUMBER OF CORES/THREADS

[Peter via bind-users]

So after ALL that it was down to the number of cores/threads, anything 
more then 7 cores/threads and 9.16.19 WILL NOT RUN tested in avirtual PC.


Man what A BUG

___
Please 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

Sorry

[Peter via bind-users]

I have come to the conclusion that I am being punished!

I have moved heaven and earth to get 9.16.19 to work and only seem to 
work on another old system Core™2 Duo that I installed win 7 activated 
it then upgrade to win10 only that system work with 9.16.19 on another 
system I remove NICs uninstalled/reinstalled MS visual C++ and then to 
top it off my new system for DNS got fully reinstalled! With 
MediaCreationTool21H1 win 10 did 9.16.19 work on that with a simple 
config that worked on my old Core™2 Duo? No I have wasted hours trying 
to work out why this problem is happening to me...and I can only think 
of one reason I am being punished and the dark side of me is saying that 
the dev have coded bind not to work on my system they know about...yes 
that is crazy but I'm out of ideals short from building another system 
and buy another win10 key.


___
Please 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

New BIND 9.16.19 I think don't run with Intel VLANs

[Peter via bind-users]

I have three PC's tested that all work fine on 9.16.15 or 9.17.12 with 
my Intel VLANs but 9.16.19 simply will not start.


Is this a new limitation for BIND on windows now? or a change that 
causes it not to run if it detects VLANs with the intel APP?


___
Please 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: cmdns.dev.dns-oarc.net oddness with windows 10 and bind

[Peter via bind-users]

Seems fine now they must of fixed the testing.
___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

Well for the time being I give up I think something like this happen 
before many years ago, I'm sure someone will post having this iusse.


___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

I getnothing which means good? installed back to the default path.

C:\Program Files\ISC BIND 9\bin>named-checkconf

C:\Program Files\ISC BIND 9\bin>



On 19/06/2021 5:53 pm, Richard T.A. Neal wrote:


And what do you get when you run c:\BIND\named-checkconf ?

Richard.

___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

My config runs fine on BIND 9.17.12 so its not the config I even install 
bind in C:\BIND with a VERY simple config that 9.17.12 runs that 9.16.18 
does not and I installed 9.16.18 on a vary new system it simply does not 
run.


named.conf

options {
    forward only;
    forwarders { 192.168.255.62;192.168.53.2; };
};

On 18/06/2021 11:33 pm, Richard T.A. Neal wrote:


The next Event Log entry on my system immediately after "using 1 UDP 
listener per interface" is:


loading configuration from 'C:\BIND\etc\named.conf'

(because that's my BIND installation folder obviously).

If I intentionally make a typo in any of my config files (eg 
named.conf, named.conf.options etc) and try and start the ISC BIND 
service I get:


Windows could not start the ISC BIND service on local computer.

Error 1067: The process terminated unexpectedly.

And that’s exactly the same error message that you’re getting.

Have you tried dropping to a command prompt and then running 
"named-checkconf" from within the "bin" subfolder of your BIND 
installation folder? That will tell you if it detects an error in any 
of your configuration files. I know you may not have changed them 
between upgrading from 9.16.12 to 9.16.18, but maybe there's something 
in there that BIND 9.16.12 was OK with but which 9.16.18 is not happy.


For example if I intentionally add a simple 'x' at the very end of my 
named.conf and then run C:\BIND\bin\named-checkconf I get:


C:\BIND\bin>named-checkconf

C:\BIND\etc\named.conf:8: unknown option 'x'

C:\BIND\etc\named.conf:8: unexpected token near end of file

Richard.

*From:*bind-users  *On Behalf Of 
*Peter via bind-users

*Sent:* 18 June 2021 5:49 pm
*To:* bind-users@lists.isc.org
*Subject:* Re: Windows support has been discontinued in BIND 9.17+ 
(Was: Important: A significant flaw is present in June BIND releases 
9.16.17 and 9.17.14)


It shows 17 information with the last showing "using 1 UDP listener 
per interface" maybe it don't like my intel VLAN's?



___
Please 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



___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

It shows 17 information with the last showing "using 1 UDP listener per 
interface" maybe it don't like my intel VLAN's?


On 18/06/2021 5:21 pm, Richard T.A. Neal wrote:


When you say “in Application logs show fine” – how far does named 
actually get (if at all)? For example whenever I (re)start the “ISC 
BIND” service on my Windows server I get **loads** of entries in the 
Application log, starting with these three:


starting BIND 9.16.18 (Stable Release) 

running on Windows 10 0 build 17763 1879 for x64

[it’s actually Windows Server being misdetected as Windows 10, but the 
build numbers are correct]


built with 'with-tools-version=15.0 with-platform-toolset=v141 
with-platform-version=10.0.17763.0 with-vcredist=C:/Program\ Files\ 
(x86)/Microsoft\ Visual\ 
Studio/2017/BuildTools/VC/Redist/MSVC/14.16.27012/vcredist_x64.exe 
with-openssl=C:/OpenSSL with-libxml2=C:/libxml2 with-libuv=C:/libuv 
without-python with-system-tests x64'


Richard.



___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

I go back to BIND 9.17.12 and is starts fine install BIND 9.16.18 
changed log on to “local system account” like I have done for years go 
to start BIND get error 1067 in:


system logs

The ISC BIND service terminated unexpectedly. It has done this 1 
time(s). The following corrective action will be taken in 6 
milliseconds: Restart the service.


And in Application logs show fine

Maybe its just windows 10 pro? Or is it possible to have bind coded to 
no longer run in win 10?


On 18/06/2021 3:08 pm, Richard T.A. Neal wrote:

On 18/06/2021 2:48 pm, Peter wrote:


Even BIND9.16.18 will not run on windows 10 same error

I can't reproduce this error - I've just successfully upgraded from BIND 
9.16.15 to BIND 9.16.18 on my Windows (2019) server.

Do you see a more detailed error in Computer Management > Windows Logs > 
Application?

If your Application log is too busy you can also filter by event source "named" 
to remove some of the noise.

Richard.
___
Please 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



___
Please 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: Windows support has been discontinued in BIND 9.17+ (Was: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14)

[Peter via bind-users]

Even BIND9.16.18 will not run on windows 10 same error

On 18/06/2021 2:21 pm, Ondřej Surý wrote:

Hi Peter,

the Windows support in 9.17 has been discontinued (as discussed on this very 
mailing list).
So, while technically the BIND 9.17.14/9.17.15 still includes the Windows 
binaries, the
code has been removed in the git repository, and the issue you are experiencing 
will not
get a fix. If you want to keep running BIND 9 on Windows, you will have to 
downgrade
to the lastest stable 9.16 release.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org


On 18. 6. 2021, at 14:46, Peter via bind-users  wrote:

Well I don't know about anyone else but BIND 9.17.14 did not want to start in 
win 10 “windows could not start the ISC BIND service on local computer Error 
1067: the process terminated unexpectedly.”
___
Please 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



___
Please 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: Important: A significant flaw is present in June BIND releases 9.16.17 and 9.17.14

[Peter via bind-users]

Well I don't know about anyone else but BIND 9.17.14 did not want to 
start in win 10 “windows could not start the ISC BIND service on local 
computer Error 1067: the process terminated unexpectedly.”

___
Please 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

cmdns.dev.dns-oarc.net oddness with windows 10 and bind

[Peter via bind-users]

So I redone my windows bind setup on a new system and this bug may never 
get fixed but I wanted to post the oddness of this bug.


Bind on New PC as servers 127.0.0.1 for dns on that system 
cmdns.dev.dns-oarc.net reports fine except for IPv6 test OK


I then have two PC's as clients to this DNS bind server 192.168.255.62 
and 192.168.53.2 the internet works fine DNS seems to work fine but 
testing at cmdns.dev.dns-oarc.net shows some failed tests for IPv4.


And it gets odder if on that PC I remove 192.168.255.62 and 192.168.53.2 
and put in 127.0.0.1 setup bind with forwarder only 192.168.255.62 and 
192.168.53.2 then run cmdns.dev.dns-oarc.net it shows as fine!


I just don't get it?

___
Please 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: No more support for windows

[Peter Coghlan]

> Peter,
>
>
> do you seriously think that this word play is going to help the BIND 9
> support for Windows? So, I am asking you, what’s your serious
> proposal what should we do?
>

You may regard it as a word play but I am being very serious indeed.

I have looked high up and low down for a definition of what BIND is
and what it does and the most specific and succinct one I could find is
the one which I quoted.  If it was a true definintion of BIND, I would
be very pleased because I would have found exactly what I was looking
for.

My serious proposal on what you should do now is that you should come
up with a proper description/definition of BIND which considers carefully
whether it should be described as "highly portable" or whether it it
would be more accurately described as closely wedded to the Unix world
and likely to become increasingly difficult to use anywhere outside this
world as time goes forward.

How can people know whether they want to contribute to something if
there is no clear and accurate definition of what it the something is
or if at best the definition means different things to different people?
Is it not in everybody's interest that we all know exactly what we
are talking about?

(For the record, I personally have no interest in BIND 9 support
specifically for Windows.)

>
> I’ve had asked if people are willing to invest time, effort or money
> into keeping the Windows support alive. I would rather accept an
> external contributor with a commitment rather than just a fat cheque,
> because Windows support isn’t really something we are putting our
> heart in.
>

My point is that if BIND is "highly portable", a contributor's heart
would be in making it making it work on a wide variety of platforms,
not on making it work a specific platform that they have a particular
interest in.

>
> The ISC is working on improving BIND 9 day and night (in fact, it’s
> almost 11pm here), and we are spread thin, and we have to prioritise.
> And if I had to answer the question whether I and my team should
> spend time improving BIND 9 just for everybody or invest the precious
> time into fixing yet another incompatibility between POSIX/SUSv2 and
> Windows world, I think the answer would be always: Let’s improve
> things for majority of our users. It’s just simple as that.
>

If this is the way you want to go, why not declare that that BIND is
for Unix-like systems and systems that can emulate this environment only
and have people who want this get behind it?  Why the pretence that it is
"highly portable" and that it could be used satisfactorily in a very
different environment such as Windows without generating difficulty and
conflict?  Then I can be on my way as there is nothing further to interest
me here.

I'm sorry that this probably does not seem helpful to the people who would
rather the BIND 9 for Windows situation to continue as it has been but at
least it may be clearer to them as to why they are in the situation they
are in.

Regards,
Peter Coghlan

> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
>> On 4. 6. 2021, at 20:37, Peter Coghlan  wrote:
>> 
>> What I find ironic is that here:
>> 
>> https://gitlab.isc.org/isc-projects/bind9/-/blob/main/README.md
>> 
>> the very first line says:
>> 
>> "BIND (Berkeley Internet Name Domain) is a complete, highly portable
>> implementation of the Domain Name System (DNS) protocol."
>> 
>> If this were truly the case, BIND would work on Windows (or any other
>> platform that doesn't have a "u" in it's name) with minimal effort
>> and would not require specific funding to adapt it to any particular
>> platform.
>> 
>> Can we please have a realistic definition of what BIND is and what
>> it's objectives are?
>> 
>> I for one would be more likely to contribute to the development of
>> a non-platform-specific, portable BIND than a single-platform-specific
>> one.
>> 
>> On the other hand, if it has already been decided that BIND can only
>> realistically be implemented in the *u* arena and will rely on
>> facilities only available in this arena, then shouldn't this be stated
>> clearly instead of also declaring that it is highly portable?
>> 
>> Regards,
>> Peter Coghlan.
>> 
>>> 
>>> Do you understand how ironic is for you to complain about “subscription is
>>> not going to happen” while **every** email on the mailing list has this
>>> note in the footer:
>>> 
>>> ISC funds the development of this software with paid support subscriptions.
>>> Contact us at https://www.isc.org/contact/ for more information.
>>> 
>>> --
>>> Ondřej Surý — IS

Re: No more support for windows

[Peter Coghlan]

What I find ironic is that here:

https://gitlab.isc.org/isc-projects/bind9/-/blob/main/README.md

the very first line says:

"BIND (Berkeley Internet Name Domain) is a complete, highly portable
implementation of the Domain Name System (DNS) protocol."

If this were truly the case, BIND would work on Windows (or any other
platform that doesn't have a "u" in it's name) with minimal effort
and would not require specific funding to adapt it to any particular
platform.

Can we please have a realistic definition of what BIND is and what
it's objectives are?

I for one would be more likely to contribute to the development of
a non-platform-specific, portable BIND than a single-platform-specific
one.

On the other hand, if it has already been decided that BIND can only
realistically be implemented in the *u* arena and will rely on
facilities only available in this arena, then shouldn't this be stated
clearly instead of also declaring that it is highly portable?

Regards,
Peter Coghlan.

> 
> Do you understand how ironic is for you to complain about “subscription is
> not going to happen” while **every** email on the mailing list has this
> note in the footer:
> 
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
> 
> --
> Ondřej Surý — ISC (He/Him)
> 
> My working hours and your working hours may be different. Please do not feel 
> obligated to reply outside your normal working hours.
> 
>> On 4. 6. 2021, at 19:47, Peter via bind-users  
>> wrote:
>> 
>> 
>> On 04/06/2021 6:05 pm, John Thurston wrote:
>>> 
>>>> On 6/4/2021 8:48 AM, Peter via bind-users wrote: 
>>>> When people find out2024 is the year bind is no longer supported for 
>>>> windows people aregoing to be upset this all seems to be done quietly 
>>>> nothing posted on the the isc.org site about this just how many people 
>>>> depend on bind for windows will be shocking. 
>>> 
>>> And griping about the decision on the mailing list is annoying. 
>>> 
>>> If you want to alter the decision, bring something new to the discussion. 
>>> Funding to pay for the windows development team? Logistical support for the 
>>> project? 
>>> 
>>> Anything constructive will be better received than repeating "I don't like 
>>> your decision". 
>>> 
>> Yes John Thurston I said about a subscription here which I guess will not 
>> happen if they made up thier mind its likly no going to happen.  
>> 
>> Deprecating BIND 9.18+ on Windows (or making it community improved and 
>> supported (isc.org)
>> 
>> 
>> 
>> ___
>> Please 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
___
Please 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: No more support for windows

[Peter via bind-users]

Well its clearly not working so it needs to change just like DDNS is 
free but you can paid for a subscription thats easy to do or SSL is free 
for 90days but you have the option to pay easily for a year but that 
might not work for bind for windows so it needs to be a subscription to 
run it at least for windows so it can be supported. This would mean some 
type of activation that can't work on another system how thats done I 
don't know like what if the system its running on goes down and you have 
to put bind on another system how do you deal with that and so 
onmaybe if you do a year subscription of some amount you get 12 one 
time keys in a file that bind uses each month to valid your use and 
removes a key this list can be updated to add more keys as you extend 
the subscription so in the event the system dies you have some keys for 
a new system.


But I don't really see this happening would like to be proven wrong...

___
Please 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

No more support for windows

[Peter via bind-users]

On 04/06/2021 6:05 pm, John Thurston wrote:


On 6/4/2021 8:48 AM, Peter via bind-users wrote:

When people find out2024 is the year bind is no longer supported for
windows people aregoing to be upset this all seems to be done quietly
nothing posted on the the isc.org site about this just how many people
depend on bind for windows will be shocking.


And griping about the decision on the mailing list is annoying.

If you want to alter the decision, bring something new to the 
discussion. Funding to pay for the windows development team? 
Logistical support for the project?


Anything constructive will be better received than repeating "I don't 
like your decision".


Yes John Thurston I said about a subscription here which I guess will 
not happen if they made up thier mind its likly no going to happen.


Deprecating BIND 9.18+ on Windows (or making it community improved and 
supported (isc.org) 
<https://lists.isc.org/pipermail/bind-users/2021-June/104719.html>



___
Please 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

No more support for windows

[Peter via bind-users]

When people find out2024 is the year bind is no longer supported for 
windows people aregoing to be upset this all seems to be done quietly 
nothing posted on the the isc.org site about this just how many people 
depend on bind for windows will be shocking.

___
Please 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

Deprecating BIND 9.18+ on Windows (or making it community improved and supported

[Peter via bind-users]

Guess not even a subscription will not happen too.

I'm having to try and do Bind on ubuntu and it just will not let me edit 
files like named.conf unless you do some vodoo that I don't understand 
and even updating the bind like how? Windows no problem you want to edit 
a file no problem can't edit a file/folder because of permissions your a 
admin you can do that too. Bind is easy on windows.


On another note when you stop the bind service you get “windows could 
not stop ISC BIND service on local computer. Error 1067 the process 
terminated unexpectedly.” wonder if that be the last fix for 9.17.14.


___
Please 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

Deprecating BIND 9.18+ on Windows (or making it community improved and supported

[Peter via bind-users]

Maybe they could release a bind for windows ever year with limited 
support? But I guess bind will still work long after its not supported 
which is the only good thing.

___
Please 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

Deprecating BIND 9.18+ on Windows (or making it community improved and supported

[Peter via bind-users]

Well that sucks no more bind for windows...:(

___
Please 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

Update DNSSEC Zone

[Peter Fraser]

HI All,
I really would appreciate a pointer in the right direction. I took over a bind 
server recently. I am not new to bind. I have used it many times and honestly 
prefer it to windows dns but I have never worked with DNSSEC.  I have been 
reading all day and I still can’t figure out how to update the DNSSEC zone. Can 
anyone assist me please? I did see one site that said I could just put in 
regular A record entries and run rndc reload and that would resign the zone. I 
tried that but it didn’t work.
 
I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
 
auto-dnssec maintain;
update-policy local;
key-directory “zones/domain-keys”;
 
Best Regards,
SI
 ___
Please 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: How to return REFUSED

[Peter Coghlan]

> With 2 views ddos trace looks much better:
>
> 17:40:21.483188 186.149.116.55.80 > 91.216.35.171.53: [no udp cksum] 1+ > 
> RRSIG? pizzaseo.com.(30) (ttl 242, id 21165, len 58)
> 17:40:21.483470 91.216.35.171.53 > 186.149.116.55.80: [udp sum ok] 1 > 
> Refused- q: RRSIG? pizzaseo.com. 0/0/0(30) (DF) (ttl 64, id 0, len 58)
>
> Hopefully, they give up in some days, if there is no amplification any > more.

They don't ever give up.  I see one or two of these RRSIG? pizzaseo.com.
queries every few days and even when I agressively packet filter the ones
that appear likely to be real probes from malicious actors as opposed to
bogus queries from forged ip addresses targetting innocents, return
"refused" for the others and minimise the number of "refused" packets I
send out by using "errors-per-second 1", they still keep on trying.

The most recent one I've seen was three days ago but there could have been
more since then that hit the packet filters when I wasn't paying attention.

Regards,
Peter Coghlan.
___
Please 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: Preventing a particular type of nameserver abuse

[Peter Coghlan]

Tony Finch wrote:
>Peter Coghlan  wrote:
>> Instead, isn't it the case that bind knows what domains it is authoritative
>> for (or which ones it is supposed to be authoritative for) and bind is
>> therefore in the ideal position to know which queries are abusive and which
>> are not rather than wrapping kludgy filtering mechanisms around it?
>
> Not always, sadly, because of misconfigured (lame) delegations. See the
> earlier messages from me and Ondřej -
>
> https://lists.isc.org/pipermail/bind-users/2021-April/104408.html
> 
> https://lists.isc.org/pipermail/bind-users/2021-April/104423.html
>

But I don't have any misconfigured (lame) delegations and even if I had,
I think I would rather put up with the consequences of the lame delegations
on rare occasions than having my nameserver foisting abuse on others all
the time.

Those that are more worried about having lame delegations don't have to
use any option that would cause error responses to be dropped.

(I've been there and done that with the lame delegations years ago.  When
I fouled up the master, the slaves toiled on regardless, presumably because
the master returned "non-authoritative" or "refused" and nobody noticed there
was any problem.  Meanwhile, the slaves were unable to get zone transfers
from the fouled up master and much much later, they hit whatever the relevant
timeout was and the zone failed completely.  There then followed lots of head
scratching as to why the domain had failed when nothing had changed recently.
I think I would have preferred if it had failed immediately I made the
incorrect change (and I probably failed to notice bind trying to tell me about
it too) because I would have known exactly where to look for the problem.)

>> If there is a resistance to having bind ignore the abusive queries
>> altogether, could we at least have something like "errors-per-minute 1"
>> which would reduce the problem by a factor of 60 compared with
>> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)
>
> There is probably something that might improve things, but I'm not sure
> what it is. I think the minimum RRL rate of 1 per second might be intended
> to work with resolver retry times. I'm wary of suppressing error responses
> without thinking through the possible consequences.
>

But isn't this what the filtering that has been suggested is going to do?
Except isn't the filtering marginally more likely to get fouled up because
of the danger of not keeping the filtering configuration and the bind
configuration in sync with each other?

Regards,
Peter Coghlan.

> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Viking, North Utsire, South Utsire, Forties: Northerly or
> northwesterly 3 to 5, becoming variable 3 or less later. Moderate
> becoming slight. Showers. Good.
___
Please 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: Preventing a particular type of nameserver abuse

[Peter Coghlan]

Tony Finch wrote:
> Peter Coghlan  wrote:
> >
> > I have a nameserver which is authoritative for three or four domain names.
> > It receives around 1000 queries per day that could be regarded as plausably
> > legitimate.  It receives around ten times that number of absive queries per
> > day from presumably spoofed ip addresses, the vast majority of them IN ANY
> > queries for the "sl" domain or for the root nameservers all of which my
> > nameserver responds to with return code 5 ie refused.
> 
> There have been several helpful replies, but to be honest I wouldn't spend
> too much effort on low levels of abuse unless you want to use it as a
> learning exercise. (I would care if it was multiple abusive queries per
> second...)
>

I think a learning exercise would be very useful as there seems to be very
little awareness of this issue and I found it very difficult to find any
discussion or analysis of it anywhere.  From the replies to my posting here,
it seems apparant that my nameserver is definately not the only one which is
experiencing this abuse.

I am seeing abusive query rates of 5 per second for sustained periods of the
day.  As far as I can see this is specially designed to get in under the
widely suggested "errors-per-second 5" rate limiting.

>
>> I have tried "errors-per-second 1" and this seems to reduce the abuse
>> by about four fifths but one fifth of it still manages to get through
>> and I don't find this acceptable.
>
> RRL is designed to avoid interfering with legitimate traffic, but that
> does mean that some abuse traffic leaks through. Its aim is to stop
> amplification, so that the attackers don't get any benefit from abusing
> your server.
>

Sure but something is clearly benefitting from the abuse because it is
going on day in, day out for months now and it it is apparantly happening
on servers other than mine too.

Also, my nameserver doesn't receive any legitimate traffic at all which my
nameserver replies to with "refused" responses.

>
> But it sounds to me like your problem traffic is more like background
> radiation (e.g. probes) than active abuse; if so it's likely that RRL will
> not deter them.
>

I wouldn't describe it as background radiation or probes.  It doesn't seem
to be caused by misconfigured or faulty resolvers or anything of that nature.
Exactly the same queries (including the same source port and query id) are
repeated over and over again whether a "refused" reply is provided or not.
It seems pretty clearly abusive to me even if the exact purpose of the abuse
is not so obvious yet.

>
>> Instead, when I notice particularly heavy abuse of my nameserver,
>> I apply packet filtering to prevent the abusive queries from reaching
>> my nameserver and therefore to prevent it responding to them.
>
> If all the problem traffic is sl. IN ANY, then I suggest permanently
> leaving in place a filter to drop those queries. Use a string match rule,
> like Grant Taylor suggested, but match the queries instead of the
> responses, so they don't clutter your query logs.
>

>From what I can see, roughly half of the problem traffic is sl/IN/ANY and the
other half is ./IN/ANY.  Some of the problem traffic has source ports less
than 1024 and some doesn't. ([tos 0x8] is often thrown in for good measure
too. I wonder what that's about?)

It is possible for me to apply filtering that catches most or maybe all of
this but this only fixes the problem on my server and does nothing to prevent
the abuse of lots of other servers out there.

Besides, I'm not really that concerned about the effect on my nameserver, I am
more concerned about the effect of the abusive traffic being reflected by
my nameserver and various other nameservers onto innocent third parties
with little or no awareness that this is happening.

Also, I don't believe a sufficiently portable filtering mechanism exists
which can be deployed across all the platforms that bind can be deployed
on.

Even if everybody could start filtering queries for "sl" and the root
nameservers, what's to stop the abusers moving on to using a different
domain name when they discover this filtering being applied?

Instead, isn't it the case that bind knows what domains it is authoritative
for (or which ones it is supposed to be authoritative for) and bind is
therefore in the ideal position to know which queries are abusive and which
are not rather than wrapping kludgy filtering mechanisms around it?

If there is a resistance to having bind ignore the abusive queries
altogether, could we at least have something like "errors-per-minute 1"
which would reduce the problem by a factor of 60 compared with
"errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

Regards,
Peter Coghla

Preventing a particular type of nameserver abuse

[Peter Coghlan]

Hello,

I have a nameserver which is authoritative for three or four domain names.
It receives around 1000 queries per day that could be regarded as plausably
legitimate.  It receives around ten times that number of absive queries per
day from presumably spoofed ip addresses, the vast majority of them IN ANY
queries for the "sl" domain or for the root nameservers all of which my
nameserver responds to with return code 5 ie refused.

In many cases, the source port is a low number such as 53, 80, 96 or 443
for example which might make some sense if these were TCP queries but they
are all UDP queries and apart from attempting to target port 53, attempting
to target the other low UDP port numbers make no sense to me.

I have searched high up and low down for any discussion about this kind
of abuse and found very little regarding abusive queries for the root
nameservers, none at all regarding the sl domain (although it is a difficult
term to search for) and nothing at all regarding the oddball source ports
either.

Even though the "refused" responses from my nameserver are "small", the
general persistence of the abusers over a long period of time suggests to
me that they are finding these queries effective for some kind of abuse,
perhaps by way of having a very large number of nameservers return them
(unless they are too stupid to care whether the queries are answered or
refused which I suppose is also possible).

As far as I can see providing no response at all in any instance when a
code 5 refused response would normally be returned would be the appropriate
thing for my nameserver to do here and doing this would cause no difficulties
at all with any legitimate queries or anyone who is not an abuser.  Am I
correct here?

I have searched for a way to prevent my nameserver from responding
to these queries at all in order to reduce the impact on the targets
of this abuse.  All results of my research point to the use of
rate limiting as the only approach available for dealing with this
sort of issue.

The abusive queries are clearly designed to circumvent the widely
suggested "errors-per-second 5" as they arrive in groups of five
per second and applying this limitation has little or no effect
on them.

I have tried "errors-per-second 1" and this seems to reduce the abuse
by about four fifths but one fifth of it still manages to get through
and I don't find this acceptable.

Instead, when I notice particularly heavy abuse of my nameserver,
I apply packet filtering to prevent the abusive queries from reaching
my nameserver and therefore to prevent it responding to them.  I
also routinely packet filter all UDP dns queries with source port
numbers less than 1024 which I hope is the appropriate cutoff point.

Is there anything else I can do to reduce the impact of this abuse
of my nameserver on others?

My feeling is that mine can't be the only nameserver experiencing this
kind of abuse and that many nameserver admins probably would not even
notice it unless they had query logging or query-error logging turned
on and checked the logs.

Regards,
Peter Coghlan.

--Boundary_(ID_/cANmbMgveXk/KlZF+xdIQ)--
___
Please 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

broken trust chain with my DNS setup

[Peter via bind-users]

https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt

%ProgramFiles%\ISC BIND 9\bin run CMD rndc-confgen -a
folder managed-keys in ect

file rndc.conf in etc

include "C:\Program Files\ISC BIND 9\etc\rndc.key";

options {
default-key "rndc-key";
  default-server 127.0.0.1;
  default-port 953;
};

file named.root in etc
ftp.internic.net
file localhost in etc

$TTL 86400
@  IN  SOA   @  root (
 0   ; Serial
 8H  ; Refresh
 15M ; Retry
 1W  ; Expire
 1D) ; Minimum TTL
   IN   NS   @
   IN   A127.0.0.1
   IN      ::1

file 127.0.0.zone in etc

$TTL3D
@   IN  SOA localhost. root.localhost. (
1   ; serial
8H  ; refresh
2H  ; retry
4W  ; expiry
1D ); minimum
 IN   NS  localhost.
1IN   PTR localhost.

Main PC file named.conf in ect

acl private { 192.168.255.54; };
acl loopbackPC { 127.0.0.1; };
acl PClooplookup { 192.168.255.53;  };
acl bogusnets { 0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12;! 192.168.255.56;! 
192.168.255.55;! 192.168.255.54;! 192.168.255.53; 192.168.0.0/16; 
169.254.0.0/16; };
acl Rebinding { :::127.0.0.1/128; :::192.168.0.0/120; 
:::172.16.0.0/116; :::10.0.0.0/120; ::1/128; 127.0.0.0/24;0.0.0.0/8; 
10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 169.254.0.0/16; };
options {
  version none;
  hostname none;
  server-id none;
  deny-answer-addresses { "Rebinding";} except-from { 
"private";"loopbackPC";"PClooplookup"; };
  directory "C:\Program Files\ISC BIND 9\etc";
  listen-on-v6 { ::1; };
  listen-on port 53 { 127.0.0.1; 192.168.255.56;192.168.255.55; };
  avoid-v4-udp-ports { 
53;67;68;69;533;445;500;135;137;138;139;546;547;1900;3702;4500;5000;5004;5005; 
};
  use-v4-udp-ports { range 1 65535; };
  avoid-v6-udp-ports { 
53;67;68;69;533;445;500;135;137;138;139;546;547;1900;3702;4500;5000;5004;5005; 
};
  use-v6-udp-ports { range 1 65535; };
  blackhole { bogusnets; };
//  dnssec-enable yes;
  managed-keys-directory "managed-keys";
  lame-ttl 0;
  max-recursion-depth 1000;
  max-recursion-queries 1000;
  resolver-query-timeout 3;
  querylog yes;
};
view private {
match-clients { private; };
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};
view loopbackPC {
match-clients { loopbackPC; };
forward only;
forwarders { 192.168.255.53; };
query-source address 192.168.255.56 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};
view PClooplookup {
match-clients { PClooplookup; };
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone
zone"localhost"   { type master; file "localhost";
};
// local reverse zone
zone"0.0.127.in-addr.arpa"{ type master; file "127.0.0.zone";
};
};

HTPC file named.conf in ect

acl lookup2backtoPC { 192.168.255.55; };
acl lookupbacktoPC { 192.168.255.56; };
acl bogusnets { 0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12;!  192.168.255.56;! 
192.168.255.55;! 192.168.255.54;! 192.168.255.53; 192.168.0.0/16; 
169.254.0.0/16; };
acl Rebinding { ! 192.168.255.253; :::127.0.0.1/128; 
:::192.168.0.0/120; :::172.16.0.0/116; :::10.0.0.0/120; ::1/128; 
127.0.0.0/24;0.0.0.0/8; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; 
169.254.0.0/16; };
options {
  version none;
  hostname none;
  server-id none;
  deny-answer-addresses { "Rebinding";} except-from { lookupbacktoPC; 
lookup2backtoPC; };
  directory "C:\Program Files\ISC BIND 9\etc";
  listen-on-v6 { ::1; };
  listen-on port 53 { 127.0.0.1; 192.168.255.54;192.168.255.53; };
  avoid-v4-udp-ports { 
53;67;68;69;53;533;445;500;135;137;138;546;547;1900;3702;4500;5000;5004;5005; };
  use-v4-udp-ports { range 1 65535; };
  avoid-v6-udp-ports { 
53;67;68;69;53;533;445;500;135;137;138;546;547;1900;3702;4500;5000;5004;5005; };
  use-v6-udp-ports { range 1 65535; };
  blackhole { bogusnets; };
//  dnssec-enable yes;
  lame-ttl 0;
  max-recursion-depth 1000;
  max-recursion-queries 1000;
  resolver-query-timeout 3;
  managed-keys-directory "managed-keys";
  querylog yes;
};
view "lookupbacktoPC" {
match-clients { lookupbacktoPC;};
forward only;
forwarders  { 192.168.255.55; };
query-source address 192.168.255.53 port *;
// root zone
zone "." in { type hint; file "named.root";
};
// local direct zone

broken trust chain with my DNS setup

[Peter via bind-users]

Hi hope someone can help here is my setup on Bind 9.17.10.

https://bridgemode.bounceme.net/DNS%20BIND%20setup.html 



https://bridgemode.bounceme.net/DNS%20BIND%20setup2.txt

When working what happens is:

first lookup

Lookup by 127.0.0.1 on main PC then bind forwards to 192.168.255.53 from 
192.168.255.56 then HTPC by bind forwards to 192.168.255.55 from 
192.168.255.53 Main PC then does the recursion lookup in the given view/ACL


second lookup

Lookup by 192.168.255.53 on main PC from 192.168.255.55 then HTPC by 
bind forwards to 192.168.255.56 from 192.168.255.54 Main PC then does 
the recursion lookup in the given view/ACL


*issue*

What happens is this after many days of working fine:

querylog yes;

client @0227150F1FE8 127.0.0.1#55768 (community.zyxel.com): view 
loopbackPC: query failed (broken trust chain) for 
community.zyxel.com/IN/A at c:\builds\isc-private\bind9\lib\ns\query.c:7581


^This is from windows event viewer

Only way to fix is to restart bind on the main PC.

Thanks if you can help

___
Please 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: named 9.14.6 memory leak, cannot start

[Peter]

On Wed, Oct 16, 2019 at 12:27:39PM +0200, Ondřej Surý wrote:
! Hi Peter,
! 
! we had a similar report in the past,

Ah, that's a good message!

! so maybe you can chime in and add
! the information to the issue here 
https://gitlab.isc.org/isc-projects/bind9/issues/1179 ?

Okay, done.

Further investigation shows the basic memory usage increased by about
factor 10, and the per-zone memory usage increased by factor 100.

So it's not a leak, it just doesn't fit into the available ~1.2GB
user heap space anymore.

cheerio,
P.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

named 9.14.6 memory leak, cannot start

[Peter]

When starting named 9.14.6, before doing any activity it immediately
grows infinitely, hits the system limits and crashes with:

> mem.c:710: fatal error:
> malloc failed: Cannot allocate memory
> exiting (due to fatal error in library)

Version 9.14.3 does not have this memory leak and runs flawlessly
(with 100MB VSZ).


Here are the detailled messages:

starting BIND 9.14.6 (Stable Release) 
running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0
r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019
built with '--localstatedir=/var' '--disable-linux-caps'
   '--with-libxml2=/usr/local'
   '--with-readline=-L/usr/local/lib -ledit'
   '--with-dlopen=yes' '--with-openssl=/usr'
   '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes'
   '--disable-dnstap' '--disable-fixed-rrset' '--without-geoip2'
   '--with-gssapi=/usr' 'KRB5CONFIG=/usr/bin/krb5-config'
   '--with-libidn2=/usr/local' '--without-libjson'
   '--disable-largefile' '--without-lmdb' '--disable-native-pkcs11'
   '--without-python' '--disable-querytrace'
   'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen'
   '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local'
   '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/'
   '--build=i386-portbld-freebsd11.3'
   'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe
   -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem
   /usr/local/include -fno-strict-aliasing ' 'LDFLAGS=
   -fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
   'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
   'PKG_CONFIG=pkgconf' 
running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 
356365)
compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
linked to OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11

BIND 9 is maintained by Internet Systems Consortium,
Inc. (ISC), a non-profit 501(c)(3) public-benefit 
corporation.  Support and training for BIND 9 are 
available at https://www.isc.org/support

mem.c:710: fatal error:
malloc failed: Cannot allocate memory
exiting (due to fatal error in library)


This is 9.14.3:

starting BIND 9.14.3 (Stable Release) 
running on FreeBSD i386 11.3-RELEASE-p3 FreeBSD 11.3-RELEASE-p3 #0
   r351611M#N348:361: Fri Aug 30 04:59:55 UTC 2019
built with '--localstatedir=/var' '--disable-linux-caps'
   '--with-libxml2=/usr/local' '--with-readline=-L/usr/local/lib -ledit'
   '--with-dlopen=yes' '--with-openssl=/usr'
   '--sysconfdir=/usr/local/etc/namedb' '--with-dlz-filesystem=yes'
   '--disable-dnstap' '--disable-fixed-rrset' '--with-ssapi=/usr'
   'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local'
   '--without-libjson' '--disable-largefile' '--without-lmdb'
   '--disable-native-pkcs11' '--without-python' '--disable-querytrace'
   'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-tcp-fastopen'
   '--with-tuning=default' '--disable-symtable' '--prefix=/usr/local'
   '--mandir=/usr/local/man' '--infodir=/usr/local/share/info/'
   '--build=i386-portbld-freebsd11.3'
   'build_alias=i386-portbld-freebsd11.3' 'CC=cc' 'CFLAGS=-O2 -pipe
   -march=pentium3 -DLIBICONV_PLUG -fstack-protector-strong -isystem
   /usr/local/include -fno-strict-aliasing ' 'LDFLAGS=
   -fstack-protector-strong ' 'LIBS=-L/usr/local/lib'
   'CPPFLAGS=-DLIBICONV_PLUG -isystem /usr/local/include' 'CPP=cpp'
   'PKG_CONFIG=pkgconf'
running as: named -t /var/named -u bind -c /usr/local/etc/namedb/named.conf
compiled by CLANG 4.2.1 Compatible FreeBSD Clang 8.0.0 (tags/RELEASE_800/final 
356365)
compiled with OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
linked to OpenSSL version: OpenSSL 1.0.2s-freebsd  28 May 2019
compiled with libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11

BIND 9 is maintained by Internet Systems Consortium,
Inc. (ISC), a non-profit 501(c)(3) public-benefit 
corporation.  Support and training for BIND 9 are 
available at https://www.isc.org/support

command channel listening on 127.0.0.1#953
general: notice: all zones loaded
general: notice: running
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

High load on BIND DNS and query timeouts after RPZ XFR retrieve

[Peter V]

Hi all,

I would like to get opinion on issue I was involved over weekend.
Customer utilizes RPZ feed from spamhaus and worked pretty OK for some
months after initial deployment.
They reported issue with wrong performance of BIND DNS; 
BIND version: 9.10.8-P1 

I observed BIND CPU usage went from 5% to ~200% CPU non stop; noticing
slow processing of UDP with timeout for dig output;
netstat confirmed that udp4 queue is not processed on time.

ZERES STATE   C   TIMEWCPU COMMAND
1050 named8  200  4058M  3261M sigwai  0 114.7H 182.67%
named

After different looks and restart of BIND which temporary resolve issue
for few minutes, I notice journal error on BIND

_May 17 22:11:46 DNS named[60244]: zone dbl.rpz.spamhaus.org/IN: journal
file is out of date: removing journal file_

So I started to suspect some weird state with this RPZ

Look on last 3 transfer; 2 looks OK, last one is weird with 5 record and
slow processing - I see also change for (re)loading policy name which
was new for me.

_May 17 20:47:10 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN: Transfer
started._
_ May 17 20:47:11 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: connected using 10.192.176.53#28493_
_ May 17 20:47:11 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN:
transferred serial 1558140361_
_ May 17 20:47:11 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer status: success_
_ May 17 20:47:11 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer completed: 1 messages, 154 records, 3234
bytes, 0.017 secs (190235 bytes/sec)_

_ May 17 20:51:38 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN:
Transfer started._
_ May 17 20:51:38 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: connected using 10.192.176.53#56279_
_ May 17 20:51:38 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN:
transferred serial 1558140601_
_ May 17 20:51:38 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer status: success_
_ May 17 20:51:38 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer completed: 3 messages, 1244 records,
25623 bytes, 0.037 secs (692513 bytes/sec)_

_ May 17 20:55:51 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN:
Transfer started._
_ May 17 20:55:51 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: connected using 10.192.176.53#25939_
_ May 17 20:55:52 DNS named[1050]: (re)loading policy zone
'dbl.rpz.spamhaus.org' changed from 5940230 to 5 qname, 0 to 0 nsdname,
886 to 874 IP, 0 to 0 NSIP, 0 to 0 CLIENTIP entries_
_ May 17 20:55:53 DNS named[1050]: zone dbl.rpz.spamhaus.org/IN:
transferred serial 1558140721_
_ May 17 20:55:53 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer status: success_
_ May 17 20:55:53 DNS named[1050]: transfer of 'dbl.rpz.spamhaus.org/IN'
from 199.168.90.51#53: Transfer completed: 1 messages, 5 records, 310
bytes, 2.251 secs (137 bytes/sec)_

 

Above would be just interesting event on one DNS server, but I got
another DNS report issue from completely different customer same day
later. 
Common: 

* same RPZ feed configured
* issue happened after transferring same serial - _1558140721_

__On other side, it was just one server from 2 for each customer, so I
cannot say it impacted directly each server used by this feed. 

=== 

In both cases, we deconfigure RPZ feed which resolved issue immediately
without any restart, we did just rndc reload after removing RPZ
statements for this feed. 

Due production state, was not easy to take more valuable data and that's
first part I would like to ask audience for guideline. 

Best Regards,
Peter___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Named Service

[Peter DeVries]

You should want the -chroot portion so you are running named in a chroot
environment but you don't need it.  There are two files named.service and
named-chroot.service.  There is also rndc-startup.service (maybe the wrong
filename) that helps configure rndc if it isn't already.  I typically
remove that and opt for my own manual rndc config.

Peter

On Tue, Jan 22, 2019 at 12:35 PM Jordan Tinsley 
wrote:

> Thank you for the information!  Also, do I need to use the {-chroot}
> portion?
>
>
>
> Thanks,
>
> Jordan
>
>
>
> *From:* Peter DeVries 
> *Sent:* Tuesday, January 22, 2019 11:32 AM
> *To:* Jordan Tinsley 
> *Cc:* bind-users 
> *Subject:* Re: Named Service
>
>
>
> You didn't mention your OS.  I'm assuming Redhat Linux.   The files you
> are looking for are /usr/lib/systemd/system/named{-chroot}.service.  The
> files are not included in the BIND source.  The easiest thing is to pull
> them out of one of the existing redhat BIND packages and edit for your
> needs.  There is nothing in the script that is version specific.
>
>
>
>
>
> On Tue, Jan 22, 2019 at 10:13 AM Jordan Tinsley 
> wrote:
>
> Hello,
>
>
>
> Just wondering how to get the named service setup when compiling from
> source?
>
>
>
> When I tried on a test machine to enable named for startup using systemctl
> enable named or systemctl start named
>
>
>
> I get an error that named.service doesn’t exist.  I may be overlooking
> documentation somewhere, but I don’t see anything about this.
>
>
>
> Thanks,
>
> Jordan
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Named Service

[Peter DeVries]

You didn't mention your OS.  I'm assuming Redhat Linux.   The files you are
looking for are /usr/lib/systemd/system/named{-chroot}.service.  The files
are not included in the BIND source.  The easiest thing is to pull them out
of one of the existing redhat BIND packages and edit for your needs.  There
is nothing in the script that is version specific.


On Tue, Jan 22, 2019 at 10:13 AM Jordan Tinsley 
wrote:

> Hello,
>
>
>
> Just wondering how to get the named service setup when compiling from
> source?
>
>
>
> When I tried on a test machine to enable named for startup using systemctl
> enable named or systemctl start named
>
>
>
> I get an error that named.service doesn’t exist.  I may be overlooking
> documentation somewhere, but I don’t see anything about this.
>
>
>
> Thanks,
>
> Jordan
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question regarding different responses that I am getting for a lookup.

[Peter DeVries]

They are probably using a load balancer of some sort that is choosing
between multiple systems and directing you to the one closest or no under
load at the moment.   The low TTL is usually a sign of this as well.



On Mon, Aug 6, 2018 at 2:12 PM, Bhangui, Sandeep - BLS CTR <
bhangui.sand...@bls.gov> wrote:

> Hello
>
>
>
> Not sure why I am getting different responses when I perform a dig on
> sso.dol.gov.
>
>
>
> Dig is performed from a server which is capable of querying the root
> servers….what could be the issue.   Both dig commands below are run from
> the same server which acts as DNS server capable of performing DNS queries
> on the internet.
>
>
>
> The dig +trace +all output is the same when I query my local server as
> well as when I query the VZ NS.
>
>
>
> Any guidance/pointers would be appreciated.
>
>
>
> Running Bind 9.11.3 on RHEL 6.x is that is of any relevance.
>
>
>
> I have a feeling that the external DNS entry presented  for sso.dol.gov
> is messed up…
>
>
>
> Thanks
>
> Sandeep
>
>
>
>
>
>
>
> sh-4.1# dig *sso.dol.gov *
>
>
>
> ; <<>> DiG 9.11.3 <<>> sso.dol.gov
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12647
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4096
>
> ; COOKIE: 191369419bc6df077b8f30ce5b688c9e77211f348bb29b35 (good)
>
> ;; QUESTION SECTION:
>
> ;sso.dol.gov.   IN  A
>
>
>
> ;; ANSWER SECTION:
>
> sso.dol.gov.77266   IN  CNAME   sso.gslb.dol.gov.
>
> sso.gslb.dol.gov.   15  IN  A   *10.49.1.80*
>
>
>
> ;; AUTHORITY SECTION:
>
> gslb.dol.gov.   77266   IN  NS  silprodgslb.dol.gov.
>
> gslb.dol.gov.   77266   IN  NS  stldrpgslb.dol.gov.
>
>
>
> ;; Query time: 27 msec
>
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>
> ;; WHEN: Mon Aug 06 13:59:58 EDT 2018
>
> ;; MSG SIZE  rcvd: 158
>
>
>
>
>
> sh-4.1# dig *@198.6.1.1 * *sso.dol.gov
> *
>
>
>
> ; <<>> DiG 9.11.3 <<>> @198.6.1.1 sso.dol.gov
>
> ; (1 server found)
>
> ;; global options: +cmd
>
> ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25189
>
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4000
>
> ;; QUESTION SECTION:
>
> ;sso.dol.gov.   IN  A
>
>
>
> ;; ANSWER SECTION:
>
> sso.dol.gov.86378   IN  CNAME   sso.gslb.dol.gov.
>
> sso.gslb.dol.gov.   15  IN  A   *152.180.20.21*
>
>
>
> ;; Query time: 93 msec
>
> ;; SERVER: 198.6.1.1#53(198.6.1.1)
>
> ;; WHEN: Mon Aug 06 14:01:42 EDT 2018
>
> ;; MSG SIZE  rcvd: 79
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: cyberia.net.sa

[Peter DeVries]

You're going to have to provide more information than that.   What isn't
working from your internet perspective?

Looks fine from where I'm sitting.

; <<>> DiG 9.11.2-P1 <<>> cyberia.net.sa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4586
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;cyberia.net.sa.IN  A

;; ANSWER SECTION:
cyberia.net.sa. 600 IN  A   212.119.92.15

;; AUTHORITY SECTION:
cyberia.net.sa. 600 IN  NS  ns2.cyberia.net.sa.
cyberia.net.sa. 600 IN  NS  ns1.cyberia.net.sa.

;; ADDITIONAL SECTION:
ns1.cyberia.net.sa. 372 IN  A   212.119.92.5
ns2.cyberia.net.sa. 372 IN  A   212.119.93.5


On Tue, Jun 26, 2018 at 7:08 AM, Mohammed Ejaz  wrote:

> I  am using bind I have problem in resolving my domain cyberia.net.sa
> over the internet. Whereas it is working fine internally. Any clue would
> be  highly appeicated.
>
>
>
> Thanks,
>
> Mohammed Ejaz
>
> Asst. Operation Director of Systems.
>
> Cyberia SAUDI ARABIA
>
> P.O.Box: 301079, Riyadh 11372
>
> Phone:  (+966) 11 464 7114 Ext. 140
>
> Mobile:  (+966) 562311787
>
> Fax:  (+966) 11 465 4735
>
> Website: http://www.cyberia.net.sa
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: extranet.aro.army.mil - not resolving

[Peter DeVries]

+cd disables DNSSEC validation.  You are running some very old versions of
dig in some cases which don't have dnssec support.   The 9.9 version of dig
you have on at least one server should work.

What version of BIND server are you running on the problematic system?

On Thu, May 31, 2018 at 8:18 PM, cwiel...@uci.edu  wrote:

> Hi
>
> Can you elaborate on +cd? a dig option, I am not finding it as an option.
>
> thanks
> con
>
> > On May 31, 2018, at 2:51 PM, Warren Kumari  wrote:
> >
> > Try it with +cd and see if that fixes it.
> >
> > The DNSSEC stuff for this domain is all borked up -- sufficiently that
> > I felt like I was playing snakes and ladders while looking at:
> > http://dnsviz.net/d/extranet.aro.army.mil/dnssec/
> > On Thu, May 31, 2018 at 5:45 PM John Miller 
> wrote:
> >>
> >> Hi Con,
> >>
> >> May I suggest running dig +trace extranet.aro.army.mil from your
> >> nameserver?  That'll make the delegation process explicit and help you
> >> troubleshoot a little better.  It could be that one of the three main
> >> army.mil nameservers is unreachable by your ns for some reason
> >> (routing being a likely culprit).
> >>
> >> John
> >>
> >> On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> >>> and here they are but I don’t see anything indicating what the problem
> might be
> >>>
> >>> 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:01.151 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:06.153 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> >>> 31-May-2018 13:56:11.158 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> >>> 31-May-2018 13:56:11.158 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> >>> 31-May-2018 13:56:21.168 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> >>>
>  On May 31, 2018, at 12:51 PM, Reindl Harald 
> wrote:
> 
> 
> 
>  Am 31.05.2018 um 21:42 schrieb Con Wieland:
> > agreed but why would my server not resolve it while others do?
> 
>  ask the logs of 128.200.1.201
> 
>  ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
>  ;; global options: +cmd
>  ;; Got answer:
>  ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
>  ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>  ;; SERVER: 128.200.1.201#53(128.200.1.201)
> 
> >> On May 31, 2018, at 12:16 PM, Reindl Harald 
> wrote:
> >>
> >>
> >>
> >> Am 31.05.2018 um 21:09 schrieb Con Wieland:
> >>> I have a nameserver that can not resolve extranet.aro.army.mil.
> >>
> >> terrible slow and insane config - fix it
> >>
> >> https://intodns.com/aro.army.mil
> >>
> >> ;; Query time: 1175 msec
> >> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >> ;; WHEN: Do Mai 31 21:12:26 CEST 2018
> >> ;; MSG SIZE  rcvd: 247
> >>
> >> ;; Query time: 1109 msec
> >> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> >> ;; WHEN: Do Mai 31 21:12:52 CEST 2018
> >> ;; MSG SIZE  rcvd: 191
> >>
> >> ;; ANSWER SECTION:
> >> aro.army.mil.   2022IN  NS  ns03.army.mil.
> >> aro.army.mil.   2022IN  NS  ns02.army.mil.
> >> aro.army.mil.   2022IN  NS  ns01.army.mil.
> >>
> >> ;; Query time: 163 msec
> >> ;; SERVER: 192.82.113.7#53(192.82.113.7)
> >> ;; WHEN: Do Mai 31 21:15:37 CEST 2018
> >> ;; MSG SIZE  rcvd: 98
> >> WarnSOA REFRESH WARNING: Your SOA REFRESH interval is:
> 900. That is
> >> not so ok
> >> WarnSOA RETRY   Your SOA RETRY value is: 90. That is
> NOT OK
> 
> >>>
> >>> ___
> >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >>>
> >>> bind-users mailing list
> >>> bind-users@lists.isc.org
> >>> https://lists.isc.org/mailman/listinfo/bind-users
> >>
> >>
> >>
> >> --
> >> John Miller
> >> Senior Systems Engineer
> >> Brandeis University ITS
> >> johnm...@brandeis.edu
> >> (781) 736-4619
> >> ___
> >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 

Re: extranet.aro.army.mil - not resolving

[Peter DeVries]

It's messy to be sure but it's not failing validation on any of the systems
I'm testing on (no AD bit because the CNAMEs aren't signed but no SERVFAIL
either)(.   I see a bunch of dig versions in your posting (9.3?).  What
version BIND is the server running?

On Thu, May 31, 2018 at 5:51 PM, Warren Kumari  wrote:

> Try it with +cd and see if that fixes it.
>
> The DNSSEC stuff for this domain is all borked up -- sufficiently that
> I felt like I was playing snakes and ladders while looking at:
> http://dnsviz.net/d/extranet.aro.army.mil/dnssec/
> On Thu, May 31, 2018 at 5:45 PM John Miller  wrote:
> >
> > Hi Con,
> >
> > May I suggest running dig +trace extranet.aro.army.mil from your
> > nameserver?  That'll make the delegation process explicit and help you
> > troubleshoot a little better.  It could be that one of the three main
> > army.mil nameservers is unreachable by your ns for some reason
> > (routing being a likely culprit).
> >
> > John
> >
> > On Thu, May 31, 2018 at 5:29 PM, Con Wieland  wrote:
> > > and here they are but I don’t see anything indicating what the problem
> might be
> > >
> > > 31-May-2018 13:56:01.150 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:01.151 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:06.153 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:06.153 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:11.158 queries: info: client 128.200.1.20#37203 (
> extranet.aro.army.mil): view internal: query: extranet.aro.army.mil IN A
> +E (128.200.1.201)
> > > 31-May-2018 13:56:11.158 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> > > 31-May-2018 13:56:11.158 resolver: debug 1: createfetch:
> aro.army.mil.edgekey.dmz.akamai.csd.disa.mil A
> > > 31-May-2018 13:56:21.168 query-errors: debug 1: client
> 128.200.1.20#37203 (extranet.aro.army.mil): view internal: query failed
> (SERVFAIL) for extranet.aro.army.mil/IN/A at query.c:7215
> > >
> > >> On May 31, 2018, at 12:51 PM, Reindl Harald 
> wrote:
> > >>
> > >>
> > >>
> > >> Am 31.05.2018 um 21:42 schrieb Con Wieland:
> > >>> agreed but why would my server not resolve it while others do?
> > >>
> > >> ask the logs of 128.200.1.201
> > >>
> > >> ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> extranet.aro.army.mil
> > >> ;; global options: +cmd
> > >> ;; Got answer:
> > >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56491
> > >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> > >> ;; SERVER: 128.200.1.201#53(128.200.1.201)
> > >>
> >  On May 31, 2018, at 12:16 PM, Reindl Harald 
> wrote:
> > 
> > 
> > 
> >  Am 31.05.2018 um 21:09 schrieb Con Wieland:
> > > I have a nameserver that can not resolve extranet.aro.army.mil.
> > 
> >  terrible slow and insane config - fix it
> > 
> >  https://intodns.com/aro.army.mil
> > 
> >  ;; Query time: 1175 msec
> >  ;; SERVER: 127.0.0.1#53(127.0.0.1)
> >  ;; WHEN: Do Mai 31 21:12:26 CEST 2018
> >  ;; MSG SIZE  rcvd: 247
> > 
> >  ;; Query time: 1109 msec
> >  ;; SERVER: 8.8.8.8#53(8.8.8.8)
> >  ;; WHEN: Do Mai 31 21:12:52 CEST 2018
> >  ;; MSG SIZE  rcvd: 191
> > 
> >  ;; ANSWER SECTION:
> >  aro.army.mil.   2022IN  NS  ns03.army.mil.
> >  aro.army.mil.   2022IN  NS  ns02.army.mil.
> >  aro.army.mil.   2022IN  NS  ns01.army.mil.
> > 
> >  ;; Query time: 163 msec
> >  ;; SERVER: 192.82.113.7#53(192.82.113.7)
> >  ;; WHEN: Do Mai 31 21:15:37 CEST 2018
> >  ;; MSG SIZE  rcvd: 98
> >  WarnSOA REFRESH WARNING: Your SOA REFRESH interval is:
> 900. That is
> >  not so ok
> >  WarnSOA RETRY   Your SOA RETRY value is: 90. That is
> NOT OK
> > >>
> > >
> > > ___
> > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> > >
> > > bind-users mailing list
> > > bind-users@lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
> >
> >
> >
> > --
> > John Miller
> > Senior Systems Engineer
> > Brandeis University ITS
> > johnm...@brandeis.edu
> > (781) 736-4619
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the 

Re: dyndb regression: bind fails to build --without-dlopen

[Peter Volkov]

Thank you Tony. Works for me.


--
Peter.

On Tue, May 30, 2017 at 7:36 PM, Tony Finch <d...@dotat.at> wrote:

> Peter Volkov <peter.vol...@gmail.com> wrote:
>
> > Hi, what this correct place to report issue? Is there any better way to
> > contact developers?
>
> A fix has been committed - see
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=summary
>
> Tony.
> --
> f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h
> punycode
> Fair Isle: Variable 4 becoming west 6 to gale 8, decreasing 4 or 5 later.
> Slight or moderate becoming moderate or rough. Occasional rain, fog
> patches.
> Moderate or good, occasionally very poor.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dyndb regression: bind fails to build --without-dlopen

[Peter Volkov]

Hi, what this correct place to report issue? Is there any better way to
contact developers?


--
Peter.

On Mon, May 8, 2017 at 11:01 AM, Peter Volkov <peter.vol...@gmail.com>
wrote:

> Hello.
>
> bind 9.10.x and 9.11.x fails to build if ./configure'ed
> --without-dlopen[1]:
>
> libtool: compile:  x86_64-pc-linux-gnu-gcc -I/var/tmp/portage/net-dns/bin
> d-9.11.0_p1/work/bind-9.11.0-P1 -I../.. -I./include -I../dns/include
> -I/var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/dns/include
> -I../../lib/dns/include -I/var/tmp/portage/net-dns/bin
> d-9.11.0_p1/work/bind-9.11.0-P1/lib/isc/include -I../../lib/isc
> -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include
> -I../../lib/irs/include -I../../lib/irs/include -DVERSION=\"9.11.0-P1\"
> -DSYSCONFDIR=\"/etc/bind\" -D_GNU_SOURCE -march=core2
> -freorder-blocks-and-partition -O2 -pipe -W -Wall -Wmissing-prototypes
> -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing
> -fno-delete-null-pointer-checks -c nsprobe.c -o nsprobe.o >/dev/null 2>&1
> libtool: link: x86_64-pc-linux-gnu-gcc -march=core2
> -freorder-blocks-and-partition -O2 -pipe -Wl,-O1 -o .libs/sample-gai
> .libs/sample-gai.o  -Wl,--as-needed ../irs/.libs/libirs.so
> ../dns/.libs/libdns.so ../isccfg/.libs/libisccfg.so
> /var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/dns/.libs/libdns.so
> /var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/isccc/.libs/libisccc.so
> /var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/isc/.libs/libisc.so
> ../isc/.libs/libisc.so -lcap -lz
> ../dns/.libs/libdns.so: undefined reference to `dlopen'
> ../dns/.libs/libdns.so: undefined reference to `dlclose'
> ../dns/.libs/libdns.so: undefined reference to `dlerror'
> ../dns/.libs/libdns.so: undefined reference to `dlsym'
> collect2: error: ld returned 1 exit status
> make[2]: *** [Makefile:463: sample-gai] Error 1
>
> This fails under lib/samples/, but the problem is with libdns.so/la
> itself. Failure was introduced by "merge dyndb" commit:
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=comm
> it;h=a00f9e2f50675bd43cc6a9fe2669709162a2ccb4
> lib/dns/dyndb.c has dlopen() reference, but configure still allows to
> disable -ldl (--without-dlopen) and thus libdns.la will be linked without
> -ldl. Probably correct fix will be to remove --with/without-dlopen option
> from ./configure.
>
>
> Ref:
> [1] https://bugs.gentoo.org/show_bug.cgi?id=600212
>
> --
> Peter.
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

dyndb regression: bind fails to build --without-dlopen

[Peter Volkov]

Hello.

bind 9.10.x and 9.11.x fails to build if ./configure'ed --without-dlopen[1]:

libtool: compile:  x86_64-pc-linux-gnu-gcc -I/var/tmp/portage/net-dns/
bind-9.11.0_p1/work/bind-9.11.0-P1 -I../.. -I./include -I../dns/include
-I/var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/dns/include
-I../../lib/dns/include -I/var/tmp/portage/net-dns/
bind-9.11.0_p1/work/bind-9.11.0-P1/lib/isc/include -I../../lib/isc
-I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include
-I../../lib/irs/include -I../../lib/irs/include -DVERSION=\"9.11.0-P1\"
-DSYSCONFDIR=\"/etc/bind\" -D_GNU_SOURCE -march=core2
-freorder-blocks-and-partition -O2 -pipe -W -Wall -Wmissing-prototypes
-Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing
-fno-delete-null-pointer-checks -c nsprobe.c -o nsprobe.o >/dev/null 2>&1
libtool: link: x86_64-pc-linux-gnu-gcc -march=core2
-freorder-blocks-and-partition -O2 -pipe -Wl,-O1 -o .libs/sample-gai
.libs/sample-gai.o  -Wl,--as-needed ../irs/.libs/libirs.so
../dns/.libs/libdns.so ../isccfg/.libs/libisccfg.so
/var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/dns/.libs/libdns.so
/var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/isccc/.libs/libisccc.so
/var/tmp/portage/net-dns/bind-9.11.0_p1/work/bind-9.11.0-P1/lib/isc/.libs/libisc.so
../isc/.libs/libisc.so -lcap -lz
../dns/.libs/libdns.so: undefined reference to `dlopen'
../dns/.libs/libdns.so: undefined reference to `dlclose'
../dns/.libs/libdns.so: undefined reference to `dlerror'
../dns/.libs/libdns.so: undefined reference to `dlsym'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:463: sample-gai] Error 1

This fails under lib/samples/, but the problem is with libdns.so/la itself.
Failure was introduced by "merge dyndb" commit:
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commit;h=
a00f9e2f50675bd43cc6a9fe2669709162a2ccb4
lib/dns/dyndb.c has dlopen() reference, but configure still allows to
disable -ldl (--without-dlopen) and thus libdns.la will be linked without
-ldl. Probably correct fix will be to remove --with/without-dlopen option
from ./configure.


Ref:
[1] https://bugs.gentoo.org/show_bug.cgi?id=600212

--
Peter.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Logging to syslog

[Peter Rathlev]

On Tue, 2016-12-06 at 13:23 +0100, Ivan Fabris wrote:
> I set up some dns logging to syslog ( rsyslog actually ), which
> forwards local1.* and local2.* to a remote rsyslog
[...]
> Both syslog, and journalctl, have all the rate limits set to infinite
> ( all that I could find )

Urgh... journalctl. Remember to also set "RateLimitInterval=0" in the 
"[Journal]" section of journald.conf. And since journald picks up and
stores _everything_, including debug messages from "execute", you might
want "Storage=volatile" there as well. You probably already have
rsyslog write things to disk, no need for it to be written two places.

> Did anyone find some slow down under heavy load with such a config,
> due to syslog ? e.g, no slow downs with file logging
> Or when the local o remote syslog are not available ( I configured
> the local rsyslog with a disk cache )

What exactly does "slow down" mean here? Are you missing messages in
the log files? Or are requests not answered in a timely fashion?

What is heavy load for you? I have a set of 2 vCPU / 4G RAM virtual
machines that service a hotspot network and logs around 3 million lines
per day each. Without RateLimitInterval=0 it routinely drops messages.

-- 
Peter
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.10.4 may have a fatal crash defect.

[Peter van Dijk]

Hello,

On 12 May 2016, at 15:44, Peter van Dijk wrote:

I’ve heard two proposals:
(1) brew fakes up a version number X that sorts 9.10.4 < X < Y, where 
Y is whatever ISC is going to release next
(2) ISC ‘clones’ 9.10.3-P4 into 9.10.5 (or 9.10.4-P1 but that 
seems wrong) so the highest version in the BIND version tree is in 
fact a stable version


There’s also
(3) do nothing, wait for ISC to figure the issue out and fix it (which 
will obviously be in a version higher than 9.10.4); doing nothing 
increases the odds of somebody running into the crash but one might 
argue that this is helpful!


I think all three options are a bit ugly, to be fair. I don’t have 
any preference.


A fourth proposal, just posted at 
https://github.com/Homebrew/homebrew-core/pull/796#issuecomment-218763988 
- homebrew just rolls back, and users who get in trouble will complain 
and get instructions to downgrade. This is my favourite option.


Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.10.4 may have a fatal crash defect.

[Peter van Dijk]

Hello Michael,

On 11 May 2016, at 10:49, Michael McNally wrote:


To our users:

Recently, on Thursday 28 April, ISC released two maintenance releases
of BIND 9:

-  BIND 9.9.9
-  BIND 9.10.4

Beginning after the release of BIND 9.10.4 we started receiving a
small number of reports from recursive server operators who have
encountered an INSIST assertion in code which checks the consistency
of the Red-Black Tree structure in which BIND stores cache 
information.


OSX Homebrew had already upgraded to 9.10.4. They are now interested in 
rolling back, but they cannot simply undo the update - ‘brew 
upgrade’ will not ‘go back’ automatically then. As there is no 
‘epoch’ support like RPM and dpkg have, something else needs to 
happen.


I’ve heard two proposals:
(1) brew fakes up a version number X that sorts 9.10.4 < X < Y, where Y 
is whatever ISC is going to release next
(2) ISC ‘clones’ 9.10.3-P4 into 9.10.5 (or 9.10.4-P1 but that seems 
wrong) so the highest version in the BIND version tree is in fact a 
stable version


There’s also
(3) do nothing, wait for ISC to figure the issue out and fix it (which 
will obviously be in a version higher than 9.10.4); doing nothing 
increases the odds of somebody running into the crash but one might 
argue that this is helpful!


I think all three options are a bit ugly, to be fair. I don’t have any 
preference.


Thoughts?

Kind regards,
--
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Moving dynamic zones to new master+slave pair without interruptions

[Peter Rathlev]

We currently have two internal DNS servers that are both authoritative
for a range of internal zones and caching resolvers for our clients. We
would like to split this so authorizative and caching roles exist on
different servers. And we would like to do this with as little down
time as possible, also for dynamic zones.

Moving static zones is of course trivial. Moving dynamic zones is what
I cannot quite wrap my head around.

I think I want to set up a new slave and AXFR from the existing master.
Then I can point delegations and "forwarders" at this new slave only,.
Together with having the configured "masters" pointing at a not yet
running master server this would make it "stand alone".

Next step in my head would be to re-create the master from this slave.
I thought that I could just copy the zone files from the slave, since
that slave would not have made any changes, seeing as it is only the
master that can do that. (I am fine with rejecting changes to the
dynamic zones during the move exercise.)

However, I see that the current slave also has ".jnl" files for the
dynamic zones and "rndc freeze " is invalid except on the zone
master. With journal files present I guess that I cannot trust the zone
files to actually be valid/complete.

So... What do I do then? Is there another way of committing the journal
to disk on a slave? Is there a "best practice" for re-creating a lost
master when dealing dynamic zones?

I may of course have started out completely wrong. If there are better
ways to acheive what I want then I am all ears! :-)

This is all a thought exercise right now, I have not actually tried to
move anything yet.

If BIND versions are relevant then we plan on using the CentOS 6
default which is BIND 9.8.2 (with some patches, so it's bind-9.8.2-
0.37.rc1.el6_7.5.x86_64) on the new servers. Building from sources is a
hassle we would rather avoid, but since we are already doing this with
ISC DHCP we could also do it with BIND if necessary.

Current master is _quite_ old, BIND 9.3.6 (bind-9.3.6-25.P1.el5_11.5).
So the setup is really in need of a refresh. :-)

Thank you in advance!

-- 
Peter Rathlev

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Moving dynamic zones to new master+slave pair without interruptions

[Peter Rathlev]

On Wed, 2016-01-06 at 18:04 +, Darcy Kevin (FCA) wrote:
> I'd just like to note in passing that the "separate authoritative and
> recursive" herd mentality reaches the ultimate point of absurdity
> when you only have 2 servers and you're going to create single points
> of failure (apparently, unless I'm misinterpreting "stand alone") to
> conform to this so-called "best practice".
[...]

I'm not religious about either model, but in this case the load on the
recursive caching servers merits them being their own instances. We are
not splitting the functions based on security concerns.

> Needless to say, I don't subscribe to the (apparently popular) notion
> that the roles need to exist on separate *hardware*. [...]

One of two authoritative servers and two of three recursing will be
virtual servers. So it's not as much a waste of hardware as it could
be. :-)

>  View-level separation is, in my opinion, sufficient to meet the
> security requirements. [...]

Certainly. We use views on the resolvers for our public "guest" network
and have had not concerns about this.

[...]
> Speaking of availability, as your network evolves, you might want to
> consider running recursive service on Anycast addresses [...]

We already use anycasting on the recursive servers and would prefer a
simple configuration that can easily be replicated to new instances. As
part of this pending transition we will introduce an extra recursing
server.

Keeping things simple, even if that means running more servers, helps
me sleep at night. It helps my colleagues handling things without
having to call me. :-)

-- 
Peter Rathlev
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users