Re: Unable to start Bind on a fresh RHEL 8.6 system with enforcing SELinux

[Reindl Harald]

Am 10.06.22 um 17:07 schrieb Sandro:


On 10-06-2022 16:02, Reindl Harald wrote:

come on!

the OP clearly stated the only problem is the "PIDFile" line in the
systemd-unit and so what named writes or not is completly irrelevant

"PIDFile" for systemd has nothing to do with "pid-file" of named


:facepalm:

Indeed. I was led down the garden path. The PIDFile setting in the unit 
file can be totally different from the pid-file option in bind. 
Although, they should probably point to the same file.


Yet, the man page for systemd.service (5) states:

Usage of this option [PIDFile] is recommended for services where Type= 
is set to forking.


So, it was probably just a simple misconfiguration and systemd applying 
some of its "magic" to a non-existent file...


seriously - about what magic are you talking?
do you even know what a pidfile is?

it's a simple textfile where the process writes it's PID
and PIDFile forces systemd to read that file and use the content as 
"Main PID"


Anyway, in my case the PIDFile option is set, be it useful or not, and 
SELinux is running in enforcing mode all without any issues


the whole point of my responses was the upstream should reconsider to 
use the option becasue it's proven to be useless no matter what some 
outdated manpage says


there is only one situation where it's needed: a service written that 
terrible that systemd is unable to guess the "Main PID"


can't apply to services with only one process by definition - what 
exactly can be wrong guessed below when there is only a single process?


even in case of a forking service after the fork ther is still only one 
process and one PID in the cgroup


[root@srv-rhsoft:~]$ systemctl status named
● named.service - DNS Server
 Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor 
preset: disabled)
 Active: active (running) since Thu 2022-06-09 01:06:51 CEST; 1 day 
16h ago

   Main PID: 1428 (named)
  Tasks: 18 (limit: 512)
 Memory: 50.5M
CPU: 4min 30.989s
 CGroup: /system.slice/named.service
 └─ 1428 /usr/sbin/named -4 -f -u named -t /var/named/chroot
--
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 start Bind on a fresh RHEL 8.6 system with enforcing SELinux

[Reindl Harald]

Am 10.06.22 um 15:56 schrieb Sandro:

On 10-06-2022 15:27, Reindl Harald wrote:


Am 10.06.22 um 15:22 schrieb Sandro:

On 10-06-2022 12:53, Reindl Harald wrote:

if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID"
won't work for nearly 10 years without "PIDFile" (no i won't use and
configure rndc - keep it simple)

That's a personal choice, but probably not the answer to the OPs
question. The shipped unit file for named on Fedora (and by extension
RHEL) makes use of PID files. I presume to cater for cases where rndc is
not being used.
you missed my point - this "ExecReload" proves that the PIDFile is 
useless


  > The shipped unit file for named on
  > Fedora (and by extension RHEL) makes
  > use of PID files

but why in the world for a service with only a single process?


I'm not saying you are wrong. But since 'pid-file' option has a default 
setting if not defined otherwise in options {}, named will try to write it


come on!

the OP clearly stated the only problem is the "PIDFile" line in the 
systemd-unit and so what named writes or not is completly irrelevant


"PIDFile" for systemd has nothing to do with "pid-file" of named

below the entry post:

---

If I remove PIDFile in the systemd unit it just works fine..


[Service]
Type=forking
EnvironmentFile=-/etc/opt/isc/scls/isc-bind/sysconfig/named
#PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
ExecStart=/opt/isc/isc-bind/root/usr/sbin/named -u named $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID
PrivateTmp=true
--
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 start Bind on a fresh RHEL 8.6 system with enforcing SELinux

[Reindl Harald]

Am 10.06.22 um 15:22 schrieb Sandro:

On 10-06-2022 12:53, Reindl Harald wrote:

if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID"
won't work for nearly 10 years without "PIDFile" (no i won't use and
configure rndc - keep it simple)
That's a personal choice, but probably not the answer to the OPs 
question. The shipped unit file for named on Fedora (and by extension 
RHEL) makes use of PID files. I presume to cater for cases where rndc is 
not being used.

you missed my point - this "ExecReload" proves that the PIDFile is useless

> The shipped unit file for named on
> Fedora (and by extension RHEL) makes
> use of PID files

but why in the world for a service with only a single process?
--
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 start Bind on a fresh RHEL 8.6 system with enforcing SELinux

[Reindl Harald]

Am 10.06.22 um 12:59 schrieb Søren Andersen:
I think the source of the systemd unit file is from: 
https://gitlab.isc.org/isc-packages/rpms/bind/-/blob/main/named.service.in 
<https://gitlab.isc.org/isc-packages/rpms/bind/-/blob/main/named.service.in> 


(And I'm using ISC's repo)

Perhaps Michał Kępień have any idea? 


please don't convert plain-text mails in a reply to HTML, it looks like 
after a war when coinverted back to plaintext


as said the line should be removed

[root@srv-rhsoft:~]$ cat /etc/systemd/system/named.service
[Unit]
Description=DNS Server
After=network-up.service
Requires=network-online.target network-up.service

[Service]
Type=simple
ExecStartPre=/usr/libexec/setup-named-chroot.sh /var/named/chroot on 
/etc/named-chroot.files
ExecStartPre=/usr/sbin/named-checkconf -t /var/named/chroot -z 
/etc/named.conf

ExecStart=/usr/sbin/named -4 -f -u named -t /var/named/chroot
ExecReload=/usr/bin/kill -HUP $MAINPID
ExecStop=/usr/bin/kill -TERM $MAINPID
ExecStopPost=/usr/libexec/setup-named-chroot.sh /var/named/chroot off 
/etc/named-chroot.files

PermissionsStartOnly=true
TimeoutSec=25
Restart=always
RestartSec=1

PrivateTmp=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK
RestrictRealtime=yes
SystemCallArchitectures=native
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_NET_BIND_SERVICE CAP_SETGID 
CAP_SETUID CAP_SYS_CHROOT


SystemCallFilter=@system-service @network-io @mount
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @module 
@obsolete @raw-io @reboot @resources @swap


LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
ProtectHome=yes
ProtectHostname=yes
RestrictNamespaces=yes
RestrictSUIDSGID=yes



*From:* bind-users  on behalf of 
Reindl Harald 

*Sent:* Friday, 10 June 2022 12.53
*To:* bind-users@lists.isc.org 
*Subject:* Re: Unable to start Bind on a fresh RHEL 8.6 system with 
enforcing SELinux

[EKSTERN MAIL]


Am 10.06.22 um 10:52 schrieb Søren Andersen:

I've installed a fresh BIND on a RHEL 8.6 system with enforcing SElinux,
and when I try to start BIND with the provided systemd unit file it just
waits and timeout, and also logs these errors in /var/log/message

Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID
files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file
descriptor to proper file descriptor: Permission denied
Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID
files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file
descriptor to proper file descriptor: Permission denied

If I remove PIDFile in the systemd unit it just works fine..


[Service]
Type=forking
EnvironmentFile=-/etc/opt/isc/scls/isc-bind/sysconfig/named
#PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
ExecStart=/opt/isc/isc-bind/root/usr/sbin/named -u named $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID
PrivateTmp=true

Anyone else experiences this?


PIDFile shouldn't be needed at all - esepcially for threaded services
it's useless, systemd knows the PID anyways

if that option is used in the provided systemd-unit one should ask the
guy who have written it: why?

if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID" won't
work for nearly 10 years without "PIDFile" (no i won't use and configure
rndc - keep it simple)

--
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 start Bind on a fresh RHEL 8.6 system with enforcing SELinux

[Reindl Harald]

Am 10.06.22 um 10:52 schrieb Søren Andersen:
I've installed a fresh BIND on a RHEL 8.6 system with enforcing SElinux, 
and when I try to start BIND with the provided systemd unit file it just 
waits and timeout, and also logs these errors in /var/log/message


Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID 
files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file 
descriptor to proper file descriptor: Permission denied
Jun 10 10:09:25 systemd[1]: isc-bind-named.service: Can't convert PID 
files /var/opt/isc/scls/isc-bind/run/named/named.pid O_PATH file 
descriptor to proper file descriptor: Permission denied


If I remove PIDFile in the systemd unit it just works fine..


[Service]
Type=forking
EnvironmentFile=-/etc/opt/isc/scls/isc-bind/sysconfig/named
#PIDFile=/var/opt/isc/scls/isc-bind/run/named/named.pid
ExecStart=/opt/isc/isc-bind/root/usr/sbin/named -u named $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -TERM $MAINPID
PrivateTmp=true

Anyone else experiences this?


PIDFile shouldn't be needed at all - esepcially for threaded services 
it's useless, systemd knows the PID anyways


if that option is used in the provided systemd-unit one should ask the 
guy who have written it: why?


if it would be useful my "ExecReload=/usr/bin/kill -HUP $MAINPID" won't 
work for nearly 10 years without "PIDFile" (no i won't use and configure 
rndc - keep it simple)

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Problem resolving a domain

[Reindl Harald]

Am 13.05.22 um 15:16 schrieb Rainer Duffner:

Thanks for the hints!

It does indeed work with these settings.

The problem is also that google and quad9 and most of the rest of the internet 
seem to be able to resolve it


the real problem is that they are working around it - if not the stupid 
upstream dns providers would have pressure to do their jobs and fix it 
at the root cause

--
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: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral

[Reindl Harald]

Am 06.05.22 um 12:24 schrieb Ted Mittelstaedt:

On 5/6/2022 12:45 AM, Reindl Harald wrote:



in the past our CISCO ISP router with "DNS ALG" even rewrote zone 
transfers and invented a zero TTL for each and every CNAME it saw




Probably doing that to retaliate for dynamic DNS providers abusing DNS 
and people abusing dynamic DNS providers for being cheapskates and 
saving a nickle on a real static IP.


You got caught in the crossfire of that particular war


nonsense - it's the cisco default behavior

no ip nat service alg udp dns
no ip nat service alg tcp dns

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral

[Reindl Harald]

Am 06.05.22 um 08:19 schrieb Bjørn Mork:

Mark Andrews  writes:


It’s a long known issue with so called “Transparent” DNS
proxies/accelerators/firewalls.  Iterative resolvers expect to talk to
authoritative servers.  They ask questions differently to the way they
do when they talk to a recursive server.  Answers from different
levels of the DNS hierarchy for the same question are different.  If
you just cache and return the previous answer you break iterative
lookups.  The answers from recursive servers are different to those
from authoritative servers.

You get the same sort of problem in many hotels if you have an
iterative resolver on your portable devices.  Switching named to use a
public recursive server that supports DNSSEC in forward only mode
helps sometimes.  It really depends on what the middleware is doing.


How about configuring forwarder(s) if you have to operate a resolver in
such an environment?  Hoping that the answer from the intercepting
server isn't too different from what you'd expect from a forwarder


the problem is that this middleware crap operates on the protocol level

in the past our CISCO ISP router with "DNS ALG" even rewrote zone 
transfers and invented a zero TTL for each and every CNAME it saw


means our secondary nameserver hat completly different zone files than 
the master


you don't expect that and watch a zone transfer on both ends with 
wireshark solved that riddle


so from the moment on some device thinking it's smart about DNS you are lost
--
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: Bind9 Server conflicts with docker0 interface

[Reindl Harald]

Am 05.05.22 um 16:05 schrieb Maurà cio Penteado via bind-users:



  What is the current behavior?

Nslookup from a DNS Client workstation  should not get docker0 ip 
addrees of the Bind9 Server PC.
|nslookup ns1.example.lan Server: UnKnown Address: 
fe80::f21f:afff:fe5d:be90 Name: ns1.example.lan Addresses: 
2a02:8084:601b:b80:f21f:afff:fe5d:be90 192.168.0.10 172.17.0.1|

Relevant configuration files

Interfaces from the ns1 server:


the relevant config file would have been the zone-file


||

Please, can you help?
How can I stop Bind to resolve docker0 ip address?


by not add multiple A-records for the same name to the zone-file
BIND don't know about docker on it's own

and please avoid HTML formatted mails, it makes responding with inline 
quotes more difficult as it should be



-- 
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 and systemd-resolved

[Reindl Harald]

Am 01.05.22 um 23:54 schrieb Nick Tait via bind-users:

On 1/05/2022 9:13 pm, Reindl Harald wrote:

Am 01.05.22 um 06:38 schrieb Nick Tait via bind-users:
I'm not 100% sure, but I wonder if disabling systemd-resolved may 
create issues if, for example, you are using netplan with 
systemd-networkd as the renderer? E.g. Will it still be possible to 
pick up DNS servers from IPv6 router advertisements?
pick up some nameservers from wherever is exactly what you *don't 
want* in case you have named running on your machine as resolver


you want 127.0.0.1 act as your resolver no matter what


Well, not always... If your local BIND service isn't a recursive 
resolver


irrelevant in context of this topic and worth exactly the same as saying 
"if you don't use bind at all" and honestly i don't get why you responed 
to that thread nearly a week later at all


below again the thread start and it's irrelevant what can be in some 
completly different context when the problem here is systemd-resolved


---

When I attempt “dig -t AXFR office.example.com -k 
Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to 
root I get:


;; Couldn't verify signature: expected a TSIG or SIG(0)
; Transfer failed.

This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has 
DNS=127.0.0.1 since the DNS server is running on it.  Systemd-resolved 
has been restarted afterward.  I've tried using an actual interface 
address but it doesn't help.  It seems dig tries to use 127.0.0.53 due 
to its being in /etc/resolv.conf and that fails even though dig for 
forward/reverse lookups works.


If I add @127.0.0.1 to the above it works.  Is there a way to get this 
to work without having to do that and not setting up the entire network 
configuration using systemd.  I realize it's not a big effort to add 
@127.0.0.1 but the reason for the issue is obscure, the error message is 
misleading and my distaste for systemd is sufficient enough that I would 
prefer avoiding it as much as possible.  Thanks for any input.

--
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 and systemd-resolved

[Reindl Harald]

Am 01.05.22 um 06:38 schrieb Nick Tait via bind-users:
I'm not 100% sure, but I wonder if disabling systemd-resolved may create 
issues if, for example, you are using netplan with systemd-networkd as 
the renderer? E.g. Will it still be possible to pick up DNS servers from 
IPv6 router advertisements?
pick up some nameservers from wherever is exactly what you *don't want* 
in case you have named running on your machine as resolver


you want 127.0.0.1 act as your resolver no matter what
--
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 and systemd-resolved

[Reindl Harald]

Am 18.04.22 um 07:26 schrieb Leroy Tennison via bind-users:
When I attempt “dig -t AXFR office.example.com -k 
Kexample_dns.+157+18424.key” on the DNS server (Bind 9.11) sudoed to 
root I get:


;; Couldn't verify signature: expected a TSIG or SIG(0)
; Transfer failed.

This is an Ubuntu 18.04 system and /etc/systemd/resolved.conf has 
DNS=127.0.0.1 since the DNS server is running on it.  Systemd-resolved 
has been restarted afterward.  I've tried using an actual interface 
address but it doesn't help.  It seems dig tries to use 127.0.0.53 due 
to its being in /etc/resolv.conf and that fails even though dig for 
forward/reverse lookups works.


If I add @127.0.0.1 to the above it works.  Is there a way to get this 
to work without having to do that and not setting up the entire network 
configuration using systemd.  I realize it's not a big effort to add 
@127.0.0.1 but the reason for the issue is obscure, the error message is 
misleading and my distaste for systemd is sufficient enough that I would 
prefer avoiding it as much as possible.  Thanks for any input


so why don't you just disable systemd-resolved?

i run Fedora everywhere in production and on workstations, have masked 
it and after "chattr +i /etc/resolv.conf" nothing messes up resolv.conf 
(even without resolvd existing it would have the immutable flag to 
prevent the dhcp client fpr the WAN interface assign the broken ISP 
resolvers)


[root@srv-rhsoft:~]$ systemctl status systemd-resolved.service
○ systemd-resolved.service
 Loaded: masked (Reason: Unit systemd-resolved.service is masked.)
 Active: inactive (dead)

--
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: Periodic SERVFAIL for TLD .BY

[Reindl Harald]

Am 02.04.22 um 20:30 schrieb Dzmitry Shykuts:
I have read every post and am very grateful to everyone who took part in 
the discussion.


It's good when the server is configured correctly, but here you have to 
use crutches for the whole .BY zone. This has never happened in my 20 
years of experience


20 years ago nobody cared about standards or security
things have changed in the past years
at some point not react to changes becomes visible
that's why you react *before* things break for everyone
if someone don't you get what you have now


--
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: Periodic SERVFAIL for TLD .BY

[Reindl Harald]

Am 02.04.22 um 19:47 schrieb Dzmitry Shykuts:

I have some questions about this situation.

What causes this "address fetching loop"?
Maybe it's a bug/future in the BIND software?
Misconfigured .BY zone and its servers?
Problem with root servers or TLD?
Why does my server have this problem, but other servers don't?


because your server cares about standards and others don't
--
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: Chroot Bind failed to start

[Reindl Harald]

Am 15.03.22 um 15:14 schrieb Paul Amaral:

Reindi, thanks for the explanation, I do manually edit the zones because we 
don’t make many DNS changes these days and I usually do named-checkzone but I 
missed that this time, although I did reload that problematic zone with rndc 
reload and saw no errors.  I do have bind restarting once a week via chron. It 
restarted early this morning and of course it failed to come up with no errors 
in the log, making it difficult to troubleshoot ☹


than do yourself a favor and include the named-checkzone in your cron 
script before restart it hard unattended in the middle of the night 
(besides a weekly restart without any reason is questionable as you see 
it's only asking for trouble)



-Original Message-
From: bind-users  On Behalf Of Reindl Harald
Sent: Tuesday, March 15, 2022 10:01 AM
To: bind-users@lists.isc.org
Subject: Re: Chroot Bind failed to start

Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users:

Neverminded, I was able to traceback my steps and realize a fat
fingered a DNS entry in one of the zones,  added two periods to an
authoritative zone’s DNS record, causing bind to fail to start. The
concerning issue was there was no error on the logs at all, making it
hard to figure out the issue.


that's the terrible packaging


Which leads me to the next question, let’s say I’m authoritative for
regular zone ABC.com and I fat fingered its DNS record,
ns1..something.com. Why would this affect the bind instance from
starting up?


because that's what ExecStartPre is for
if it fails the unit fails


Like I said there was nothing on the logs and I understand that might
be due to the Centos PKG itself. Just wondering why that mistake down
bind down and how I can get more meaningful logs on the logs even
those a prepackaged bind version.


the ExecStartPre happens long before named it even tried to start, so it can't 
log anything - in my opinion the ExecStartPre stuff should go in it's own 
script and just log but not fail the unit with a non-zero exit code

BTW: don't write directly in zone files and if you do so verify it at your own 
- good chances named would refuse to start at it's own with such errors

that's why you *don't hard restart named* just because you changed a zone - a 
reload most likely would have logged the error and just refused to reload the 
zone itself

you need tools for altering zones which would refuse such wrong input before 
they make it into the zone-file

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Chroot Bind failed to start

[Reindl Harald]

Am 15.03.22 um 14:37 schrieb Paul Amaral via bind-users:
Neverminded, I was able to traceback my steps and realize a fat fingered 
a DNS entry in one of the zones,  added two periods to an authoritative 
zone’s DNS record, causing bind to fail to start. The concerning issue 
was there was no error on the logs at all, making it hard to figure out 
the issue.


that's the terrible packaging

Which leads me to the next question, let’s say I’m authoritative for 
regular zone ABC.com and I fat fingered its DNS record, 
ns1..something.com. Why would this affect the bind instance from 
starting up? 


because that's what ExecStartPre is for
if it fails the unit fails

Like I said there was nothing on the logs and I understand 
that might be due to the Centos PKG itself. Just wondering why that 
mistake down bind down and how I can get more meaningful logs on the 
logs even those a prepackaged bind version.


the ExecStartPre happens long before named it even tried to start, so it 
can't log anything - in my opinion the ExecStartPre stuff should go in 
it's own script and just log but not fail the unit with a non-zero exit code


BTW: don't write directly in zone files and if you do so verify it at 
your own - good chances named would refuse to start at it's own with 
such errors


that's why you *don't hard restart named* just because you changed a 
zone - a reload most likely would have logged the error and just refused 
to reload the zone itself


you need tools for altering zones which would refuse such wrong input 
before they make it into the zone-file



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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Chroot Bind failed to start

[Reindl Harald]

Am 15.03.22 um 14:08 schrieb Paul Amaral via bind-users:
Hi, I realize this is related to Centos, but all the sudden chroot bind 
failed to start up with any meaningful errors.


you need to debug this terrible "ExecStartPre" where the package 
maintainer was too lazy to include a script file in the package and 
wrapped everything in "/bin/bash -c"


that's a good example how a systemd-unit should *not* look like - 
especially combined with env-vars and what not


try to disable the check and look if at least named would work as 
expected - good chances only the check is borked


Job for named-chroot.service failed because the control process exited 
with error code. See "systemctl status named-chroot.service" and 
"journalctl -xe" for details.


[r...@ns1.frv.ma:/var/named/meganet]#systemctl status 
named-chroot.service -l


● named-chroot.service - Berkeley Internet Name Domain (DNS)

    Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; 
enabled; vendor preset: disabled)


    Active: failed (Result: exit-code) since Tue 2022-03-15 08:46:11 
EDT; 6min ago


   Process: 3045 ExecStartPre=/bin/bash -c if [ ! 
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t 
/var/name d/chroot -z "$NAMEDCONF"; else echo "Checking of zone 
files is disabled"; fi (code=exited, status=1/FAILURE)


Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service: control 
process exited, code=exited status=1


Mar 15 08:46:11 ns1.frv.ma systemd[1]: Failed to start Berkeley Internet 
Name Domain (DNS).


Mar 15 08:46:11 ns1.frv.ma systemd[1]: Unit named-chroot.service entered 
failed state.


Mar 15 08:46:11 ns1.frv.ma systemd[1]: named-chroot.service failed

--
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: Access denied Bind9

[Reindl Harald]

Am 08.03.22 um 02:44 schrieb Ritah Mulinde:

Hi Guys
Just got my primary and secondary name servers  running.

However, when i reload rdnc and tail the syslogs all i get is 
"(.xx.com ): query (cache) '.xx.com/A/IN 
' denied"


because on a authoritative server it#s the right thing to do deny any 
queries for zones your are not responsible for


but hat has *nothing to do* with "when i reload rdnc and tail the syslog"
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Issue Using Wildcards for Subdimain Redirecing

[Reindl Harald]

Am 17.02.22 um 18:51 schrieb muha...@plciq.com:

I understood that, now, I have another issue. The main domain the is used in the zone ( 
zone "example.com" ) don't resolve to anything and I want it to be resolved 
from 8.8.8.8, while the sub-domains still resolve from my DNS as specified in the zone 
record file.


than you need the subdomains in own zone-files and don't delegate them 
in the public view


BTW: stop talking about "be resolved from 8.8.8.8" when the terminology 
is private and public views



-Original Message-
From: tale 
Sent: Thursday, February 17, 2022 8:47 PM
To: muhanad 
Cc: bind-users 
Subject: Re: Issue Using Wildcards for Subdimain Redirecing

On Thu, Feb 17, 2022 at 3:34 AM muhanad  wrote:

I have a main domain ( aa.example.com) with hunderds of subdomains ( bb.aa.example.com). 
I made a wildcard record to forward all subdomains (bb.) to a list of addresses in  
round-robin fashion. The problem I am fscing is the wildcard is forwarding anything 
towards the the IP ( example , "cc.bb." which is not a vaild subdomain). How 
can I limit that so it will only forwards ( bb.aa.example.com) and drops any invalid 
subdomains ( cc.bb.aa.example.com ).

Note: aa, bb, and cc being any arbitary value.


With a standard BIND zone, you can't.  Wildcards match multiple labels.  That 
goes to the earliest days of the DNS, 
https://www.rfc-editor.org/rfc/rfc1034#section-4.3.3.

You'd need a specialized handler to do this.

--
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 9.16.25 fails to start (1067 Terminated unexpectedly)

[Reindl Harald]

Am 17.02.22 um 18:47 schrieb Paul Kosinski via bind-users:

On Thu, 17 Feb 2022 15:26:35 +0100
Ondřej Surý  wrote:

...
  

This is part of the problem - debugging on Windows is extremely painful and 
requires expertise with extremely high learning curve.



I wonder if difficult debugging is deliberate -- it would certainly make harder 
the reverse engineering of software from Microsoft and others who build on top 
of Windows


for sure not

that way you only stop script kiddies but not people with knowledge 
needed anyways to do reverse engineering

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: Is there a community product maintaining Windows support?

[Reindl Harald]

Am 17.02.22 um 17:36 schrieb Jakob Bohm via bind-users:

This is truly tragic, and quite counterproductive action by ISC.


no, it's just stop wasting time for things not really used in the real 
production world



Messing about with docker virtualization inside an already virtual
machine seems like a recipe for disaster


nobody said that

when you already have a virtualization infracstructure the far better 
question is why you did install named on a windows guest to begin with


BTW: docker is *not* virtualization and i would *always* install any 
containers inside virtual machines because on production hardware the 
only thing which belongs to bare-metal is the hypversior (yes, there are 
*very few* expections, contgainers are non of them)


why? because there is redundancy, hot migration, backup-infrastructure 
and so on - the only usecase for containers is lightweight isolation for 
the few cases a systemd-unit with proper namespaces and cgroups isn't enough

--
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: ipv6 adoption

[Reindl Harald]

Am 16.02.22 um 14:25 schrieb Mark Tinka:

On 2/16/22 14:38, Andrew Baker via bind-users wrote:


Firstly, we are running bind 9.11 on Debian 10 hosts.

  * Is it worth use upgrading to Debian 11 to get the newer version of
bind?



I don't run Linux, but shouldn't it be possible to just upgrade only 
BIND on your current Linux release, without having to change major OS 
versions?


not when you don't use 3rd party repos or build it at your own - the 
whole point of a stable distibution is to not have random major-upgrades 
of software


and unless you have no very good reason you should either stay at the 
packages from your distribution or make a dist-upgrade


otherwise you end in the chaos MacOS and Windows are when it comes to 
keep everything up-to-date and get security bugs fixed - linux 
distributions are backporting security fixes

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

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: "make test" not working?

[Reindl Harald]

Am 02.02.22 um 08:23 schrieb Josef Moellers:

On 01.02.22 17:54, Reindl Harald wrote:



Am 01.02.22 um 15:28 schrieb Josef Moellers:

Just for the record:
Thanks, Ondřej, for pushing my nose onto the fact that the test 
should be run as a non-privileged user.


really *nothing* should run as root, especially not building software 
- doing so and even rpmbuild no longer can assure that something don't 
break out of the buildroot


In my case I run it on a private VM


irrelevant - basics are basics


But you're right: if the source is unreliable, anything can happen.
I was assuming the bind sources are reliable.


you are violating the principle of least privilege and that has absolute 
*nothing* to do with reliable


stop that sort of argumentation instead admit that you learned some 
absolute basics - the only error on binds sources is that they donÄt 
refuse to build as root without a special flag like courier-mta does for 
decades


a simple typo on *your side* can make the diffren between terrible 
accidents and a "permission denied" error pointing you to your mistake


mistakes happen, errors happen, bugs happen
all the time, eveywhere

the "make install" in a rpmbuild simply fails when it tries touch 
touch /usr and that's one more reason never type "sudo make install" 
but package everything


Yes ... that's what I'm about to do ... packaging bind


https://www.reddit.com/r/linux/comments/1ekd5w/why_is_it_dangerous_to_compilebuild_packages_as/

!!

It's not just malicious individuals you have to worry about. There can 
also be bugs in the build system


!!

https://serverfault.com/questions/10027/why-is-it-bad-to-build-rpms-as-root
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


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

Re: "make test" not working?

[Reindl Harald]

Am 01.02.22 um 15:28 schrieb Josef Moellers:

Just for the record:
Thanks, Ondřej, for pushing my nose onto the fact that the test should 
be run as a non-privileged user.


really *nothing* should run as root, especially not building software - 
doing so and even rpmbuild no longer can assure that something don't 
break out of the buildroot


the "make install" in a rpmbuild simply fails when it tries touch touch 
/usr and that's one more reason never type "sudo make install" but 
package everything

--
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: your mail

[Reindl Harald]

Am 16.01.22 um 04:47 schrieb John W. Blue via bind-users:

Lol.  I am not going to do that either.  Lol.


can you do us all a favor and stop writing useless mails to lists at 
saturday night?


that footer is for morons which send messages with "unsubscribe" to 
mailing lists all the time



-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl 
Harald
Sent: Saturday, January 15, 2022 9:44 PM
To: bind-users@lists.isc.org
Subject: Re: your mail

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

___
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: your mail

[Reindl Harald]

Am 16.01.22 um 04:39 schrieb John W. Blue via bind-users:

/diverging tangent

I don't want to diminish any contribution to the good of the cause that anyone 
is willing to make but ... I am not going to stop top posting.

Personally, commentary about top posting is so 1997.  Perhaps it is also 
because I have reached an age where I just don't care anymore.


besides the subject "Re: your mail" annoys me from the beginning 
(because the OP even didn't care about a useful suject which leads into 
the trash can):


in communcation when you expect that someone reads what you have to say 
it's not about what *you* care

___
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: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?

[Reindl Harald]

Am 09.01.22 um 12:57 schrieb Jason Vas Dias:

Thanks Fred -

   Though really all I am trying to do is ensure I can access
   all public DNS names, which my experience shows me I
   cannot, using my ISP's name-servers.

   It seems there is a Hidden Google Internet that I cannot access
   unless I use Google's DNS servers, giving Google data
   about me to sell - this is what I am trying to avoid 


for the sake of god stop talking nonsense about "Hidden Google Internet" 
when your named does as you configured and forward to your broken ISP 
nameservers

___
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: what is wrong with DNS name 'covid19booster.healthservice.ie' ? : Google : what is Google's secret DNS service ?

[Reindl Harald]

Am 08.01.22 um 19:26 schrieb Jason Vas Dias:

Yes, of course I can just access the website, now I know the IP
address . That is not the point.

My point is that public service websites, which provide vital
public health services , on which people's lives and human
rights depend , should NOT be on some
"Google Server Accessable Only" Hidden Internet 


again: it's your own mistake that you configured your named to forward 
queries to your broken ISP nameservers instead doing recusrion at it's own


named is grown software and don't need other resolvers handholding nor 
does it do any forwarding out-of-the-box

___
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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

[Reindl Harald]

Am 30.12.21 um 09:07 schrieb Danilo Godec via bind-users:

On 29. 12. 21 19:24, tale wrote:

On Wed, Dec 29, 2021 at 5:31 AM Danilo Godec via bind-users
 wrote:

I have an authoritative DNS server for a domain, but I was also going to
use the same server as a recursive DNS for my internal network, limiting
recursion by the IP. Apparently, this is a bad idea that can lead to
cache poisoning...

In short, no, this configuration with a BIND 9 server does not
increase your risk of cache poisoning any more than running your local
server in pure recursive mode.  I'm curious to hear more from the
source that has given you this impression.  I suspect there were some
additional qualifications that don't align with what you've described.

The source is a security audit report, claiming that using a single 
server for both authoritative (for public use) and recursive (limited to 
internal clients by means of 'allow-recursion' directive) roles 
increases the risk of DoS attacks and DNS cache poisoning... They 
mentioned CVE-2021-20322 that supposedly makes cache poisoning feasible 
(again) - that made them increase the concern level to a 'medium'.



While I understand how and why DoS and cache poisoning are bad, I don't 
understand how separating these two roles would help mitigate the risk


it don't
___
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: Nice new logging feature

[Reindl Harald]

Am 20.12.21 um 17:53 schrieb Petr Menšík:

sure I confused that. I read it wrong way and thought they are present
on *BSD but not on Fedora. I know some messages are removed in Fedora
builds. I apologize for a confusion. Nobody complained on Fedora builds,
that is a good message to me.


OP was "I am trying 9.17 at home and I just noticed a very useful new 
lame-servers log message: 2021-12-16T08:08:20.505Z lame-servers: timed 
out resolving ’stupiddomain.com/ANY/IN': X.Y.Z.T#53. I haven’t seen this 
on 9.16"


i looked at my Fedora lame-log and answered with "exists in 9.16 here 
and i doubt Fedora has backports for this"



On 12/20/21 17:39, Reindl Harald wrote:



Am 20.12.21 um 17:32 schrieb Petr Menšík:

Hi Borja,

In fact there is ancient patch [1] still applied to Fedora builds, which
hides some lame servers warnings. It makes some lame servers category
logs as debug only, shown only when -d 1 option is used.

I was thinking about removing this change some time ago and replace it
with just configuration snippet dropping lame servers message if needed.
But no one complained for years. If you think those messages should be
available, please fill bug on Red Hat Bugzilla [2], bind component.

I have minimized changes to BIND done for Fedora, but this one remained
due lack of feedback. I think configuration example to hide lame servers
messages might be more appropriate, because it would allow changes
without recompilation, just with simple configuration change. Current
builds cannot enable without debug level 1 I am afraid.


you confused something!

Borja don't have that in older named versions and does not use Fedora,
i have them on Fedora as you see in my quote and it's not about the
messsages as such but about "45.79.19.196#53" at the end of lame-logs

maybe because of my logging configuration which is unchanged for years

logging
{
  channel default_log
  {
   file "data/named.log" versions 0 size 1m;
   severity dynamic;
   print-time   yes;
   print-category   yes;
  };
  channel transfer_log
  {
   file "data/transfer.log" versions 0 size 1m;
   severity dynamic;
   print-time   yes;
   print-category   yes;
  };
  channel rate_limit_log
  {
   file "data/rate_limit.log" versions 0 size 1m;
   severity dynamic;
   print-time   yes;
   print-category   yes;
  };
  channel lame_servers_log
  {
   file "data/lame_servers.log" versions 0 size 1m;
   severity dynamic;
   print-time   yes;
   print-category   yes;
  };
  channel query_errors_log
  {
   file "data/query_errors.log" versions 0 size 1m;
   severity dynamic;
   print-time   yes;
   print-category   yes;
  };
  category default  {default_log;};
  category resolver {default_log;};
  category security {default_log;};
  category xfer-in  {transfer_log;};
  category xfer-out {transfer_log;};
  category config   {default_log;};
  category queries  {default_log;};
  category notify   {default_log;};
  category database {default_log;};
  category rate-limit   {rate_limit_log;};
  category lame-servers {lame_servers_log;};
  category query-errors {query_errors_log;};
};


On 12/16/21 13:15, Reindl Harald wrote:



Am 16.12.21 um 10:02 schrieb Borja Marcos:


Hi,

I am trying 9.17 at home and I just noticed a very useful new
lame-servers log message:

2021-12-16T08:08:20.505Z lame-servers: timed out resolving
’stupiddomain.com/ANY/IN': X.Y.Z.T#53

I haven’t seen this on 9.16. Are there any plans to include it?


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:46.937 lame-servers: connection refused resolving
'mx4.itronic.at/A/IN': 85.124.85.125#53
16-Dec-2021 13:13:41.202 lame-servers: host unreachable resolving
'70.84.141.45.in-addr.arpa/PTR/IN': 72.14.185.43#53
16-Dec-2021 13:13:45.334 lame-servers: hos

Re: Nice new logging feature

[Reindl Harald]

Am 20.12.21 um 17:32 schrieb Petr Menšík:

Hi Borja,

In fact there is ancient patch [1] still applied to Fedora builds, which
hides some lame servers warnings. It makes some lame servers category
logs as debug only, shown only when -d 1 option is used.

I was thinking about removing this change some time ago and replace it
with just configuration snippet dropping lame servers message if needed.
But no one complained for years. If you think those messages should be
available, please fill bug on Red Hat Bugzilla [2], bind component.

I have minimized changes to BIND done for Fedora, but this one remained
due lack of feedback. I think configuration example to hide lame servers
messages might be more appropriate, because it would allow changes
without recompilation, just with simple configuration change. Current
builds cannot enable without debug level 1 I am afraid.


you confused something!

Borja don't have that in older named versions and does not use Fedora, i 
have them on Fedora as you see in my quote and it's not about the 
messsages as such but about "45.79.19.196#53" at the end of lame-logs


maybe because of my logging configuration which is unchanged for years

logging
{
 channel default_log
 {
  file "data/named.log" versions 0 size 1m;
  severity dynamic;
  print-time   yes;
  print-category   yes;
 };
 channel transfer_log
 {
  file "data/transfer.log" versions 0 size 1m;
  severity dynamic;
  print-time   yes;
  print-category   yes;
 };
 channel rate_limit_log
 {
  file "data/rate_limit.log" versions 0 size 1m;
  severity dynamic;
  print-time   yes;
  print-category   yes;
 };
 channel lame_servers_log
 {
  file "data/lame_servers.log" versions 0 size 1m;
  severity dynamic;
  print-time   yes;
  print-category   yes;
 };
 channel query_errors_log
 {
  file "data/query_errors.log" versions 0 size 1m;
  severity dynamic;
  print-time   yes;
  print-category   yes;
 };
 category default  {default_log;};
 category resolver {default_log;};
 category security {default_log;};
 category xfer-in  {transfer_log;};
 category xfer-out {transfer_log;};
 category config   {default_log;};
 category queries  {default_log;};
 category notify   {default_log;};
 category database {default_log;};
 category rate-limit   {rate_limit_log;};
 category lame-servers {lame_servers_log;};
 category query-errors {query_errors_log;};
};


On 12/16/21 13:15, Reindl Harald wrote:



Am 16.12.21 um 10:02 schrieb Borja Marcos:


Hi,

I am trying 9.17 at home and I just noticed a very useful new
lame-servers log message:

2021-12-16T08:08:20.505Z lame-servers: timed out resolving
’stupiddomain.com/ANY/IN': X.Y.Z.T#53

I haven’t seen this on 9.16. Are there any plans to include it?


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:46.937 lame-servers: connection refused resolving
'mx4.itronic.at/A/IN': 85.124.85.125#53
16-Dec-2021 13:13:41.202 lame-servers: host unreachable resolving
'70.84.141.45.in-addr.arpa/PTR/IN': 72.14.185.43#53
16-Dec-2021 13:13:45.334 lame-servers: host unreachable resolving
'70.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:13:46.953 lame-servers: REFUSED unexpected RCODE
resolving '_.93.226.171.in-addr.arpa/A/IN': 203.113.131.1#53
16-Dec-2021 13:13:47.315 lame-servers: FORMERR resolving
'_.93.226.171.in-addr.arpa/A/IN': 203.113.188.2#53
16-Dec-2021 13:13:47.601 lame-servers: REFUSED unexpected RCODE
resolving '110.93.226.171.in-addr.arpa/PTR/IN': 203.113.131.1#53

___
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

Re: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 16.12.21 um 15:29 schrieb Andrew P.:

Reindl Harald  writes:

Am 16.12.21 um 14:56 schrieb Andrew P.:

Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name
being asked for, so I don't answer for it. I'm not looking to blacklist forged 
IP addresses
of requestors (since we all know criminals don't use their own identities; they 
use the
identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


AGAIN: you don't gain anything by not responding on a UDP protocol
because the client can't distinct no response and packet loss


AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
looking for replies to themselves


but a legit client does while these attacks aren't successful at all


And you still haven't told me who would be a legitimate client making that 
request for the
root domain from my nameserver. Frankly, I can't think of _anyone_ who should 
be making
that request of my nameserver.


it's an example where you introduce more troubles than you solve 
problems when things go bad



they're looking to abuse some poor victim. And the victim can't make the 
attacker shut up


this attacker must be pretty dumb then because the ANY request makes
only sense if it get answered and the response is magnitudes larger then
the request


Not if the attacker has a huge bot-net to make the requests. He doesn't care 
how much of
the bots' network capacity is used up, since the attacker isn't paying for it. 


but it makes not sense playing that over your server instead blow the 
traffic directly out



And, based on the same
philosophy as spam, if they hit enough name servers, some of them will be 
insecure and provide the
full response

still pretty dumb not testing with a single ANY request if you would respond


I suspect they do know what they are doing, or they wouldn't be wasting their
time doing it


"know what they are doing" muste be also the reason why i have a ton of 
hardcoded spam-subjects with specific typos for over 10 years and even 
respond that i don't like the sobject on the MX


pretty sure the original idea was not hitting a specific real word but 
after all that years a famous typo is a 100% spam sign


they don't waste their time but blow out every sort of nonsense in the 
hope someone is hitted by it, your server is immune to what they try, no 
problem exists

___
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: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 16.12.21 um 14:56 schrieb Andrew P.:

Reindl Harald  writes:
Am 16.12.21 um 14:22 schrieb Andrew P.:

You don't understand what kind of blacklist I want; I want to blacklist the 
domain name
being asked for, so I don't answer for it. I'm not looking to blacklist forged 
IP addresses
of requestors (since we all know criminals don't use their own identities; they 
use the
identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.


AGAIN: you don't gain anything by not responding on a UDP protocol
because the client can't distinct no response and packet loss


AGAIN, the criminal DDoS attacker who's creating these forged requests isn't 
looking for replies to themselves


but a legit client does while these attacks aren't successful at all


they're looking to abuse some poor victim. And the victim can't make the 
attacker shut up


this attacker must be pretty dumb then because the ANY request makes 
only sense if it get answered and the response is magnitudes larger then 
the request


hence you need to send them to a server giving a full answer to the victim

with just a error response he could send it's attack traffic directly 
given that the attacker needs the full bandwidth anyways and not using a 
valid DNS request, just blow out traffic to UDP 53


one couldn't care less about attackers which don't know what they are doing
___
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: Nice new logging feature

[Reindl Harald]

Am 16.12.21 um 14:49 schrieb Borja Marcos:

On 16 Dec 2021, at 13:15, Reindl Harald  wrote:

Am 16.12.21 um 10:02 schrieb Borja Marcos:

Hi,
I am trying 9.17 at home and I just noticed a very useful new lame-servers log 
message:
2021-12-16T08:08:20.505Z lame-servers: timed out resolving 
’stupiddomain.com/ANY/IN': X.Y.Z.T#53
I haven’t seen this on 9.16. Are there any plans to include it?


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53


Not for me definitely, but I am not running Linux. This is a FreeBSD port of 
the ISC release.
Does that version include some back ported code from bind 9.17?


i doubt that Fedora does any functional patching, maybe some of the 
build flags while i'm not sure if the stuff shown at startup is really all


Dec 16 14:51:56 srv-rhsoft named[352730]: built with 
'--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' 
'--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' 
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' 
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' 
'--libdir=/usr/lib64' '--libexecdir=/usr/libexec' 
'--sharedstatedir=/var/lib' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--with-python=/usr/bin/python3' 
'--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' 
'--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' 
'--with-maxminddb' '--enable-native-pkcs11' 
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' 
'--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' 
'--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' 
'--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 
'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto 
-ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro 
-Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld 
' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 
'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
Dec 16 14:51:56 srv-rhsoft named[352730]: running as: named -4 -f -u 
named -t /var/named/chroot

___
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: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 16.12.21 um 14:35 schrieb Ondřej Surý:

FTR RRL will not help on this case. There’s no difference between response with 
TC and response with REFUSED.

It would make a difference only if there was NOERROR response with data.


that's true but in case it's a reflection attack it would help

in this case not responding won't help anyways because the request and 
the processing is done


violate the protocol won't gain much, the hammering requests still 
continue, the load continues and all you do is making DNS a gambling machine



On 16. 12. 2021, at 14:28, Reindl Harald  wrote:


Am 16.12.21 um 14:22 schrieb Andrew P.:
Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
Annoying inconsistent list servers


blame your mail-client for not support "reply-list" buttons and "reply-all" is 
breaking this for me  :-)


You don't understand what kind of blacklist I want; I want to blacklist the 
domain name being asked for, so I don't answer for it. I'm not looking to 
blacklist forged IP addresses of requestors (since we all know criminals don't 
use their own identities; they use the identities of innocent bystanders).
Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.



AGAIN: you don't gain anything by not responding on a UDP protocol because the 
client can't distinct no response and packet loss

so you *increase* the load by retries on the client

don't get me wrong but you need to understand the implications of what you are doing - 
for DOS attacks "Response Rate Limiting" was invented and for non-DOS requests 
there isn't any valid reason to take action


____
From: bind-users  on behalf of Reindl Harald 

Sent: Thursday, December 16, 2021 8:14 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied

Am 16.12.21 um 14:04 schrieb Andrew P.:
So you're claiming that legitimate resolvers would still be pointing at the 
wrong IP address for a public DNS server after over 16 years?

besides that i don't know why you are answering off-list nowhere did i
say anything about 16 years
but it can take time
just because some IP is asking for a domain you don't host is for sure
not a justification for automated blacklisting - that will happen
regulary after domain-transfers for some time

And asking repeatedly and rapidly for the same illegal root domain name in 
synchronized bursts of 10 queries supposedly from 10 different IP addresses?

that's what "Response Rate Limiting" is for

I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.

fine, that's *your* case - we host 800 domains and all the time some get
transferred to us and some get away

I agree with the concept of a blacklist

i don't because the IP is in most cases FORGED

how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.

"Response Rate Limiting"
again: the IP you mostly see is FORGED and the victim not the attacker
and all you do is blacklisting the innocent victim which never did
anything bad
with automated blacklisting you expose yourself to a simple DOS attack -
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
take your domain offline for anybody on the planet using the google
resolvers
and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
resolvers for endusers - game over, you blacklisted the world

________
From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

tha

Re: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 16.12.21 um 14:22 schrieb Andrew P.:

Sorry about forgetting to post the list. I hit Reply instead of Reply All. 
Annoying inconsistent list servers


blame your mail-client for not support "reply-list" buttons and 
"reply-all" is breaking this for me  :-)



You don't understand what kind of blacklist I want; I want to blacklist the 
domain name being asked for, so I don't answer for it. I'm not looking to 
blacklist forged IP addresses of requestors (since we all know criminals don't 
use their own identities; they use the identities of innocent bystanders).

Again, why should _my_ nameserver_ respond to a query for "./ANY/IN"? I am not 
a rootserver, and never will be.



AGAIN: you don't gain anything by not responding on a UDP protocol 
because the client can't distinct no response and packet loss


so you *increase* the load by retries on the client

don't get me wrong but you need to understand the implications of what 
you are doing - for DOS attacks "Response Rate Limiting" was invented 
and for non-DOS requests there isn't any valid reason to take action



____
From: bind-users  on behalf of Reindl Harald 

Sent: Thursday, December 16, 2021 8:14 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 16.12.21 um 14:04 schrieb Andrew P.:

So you're claiming that legitimate resolvers would still be pointing at the 
wrong IP address for a public DNS server after over 16 years?


besides that i don't know why you are answering off-list nowhere did i
say anything about 16 years

but it can take time

just because some IP is asking for a domain you don't host is for sure
not a justification for automated blacklisting - that will happen
regulary after domain-transfers for some time


And asking repeatedly and rapidly for the same illegal root domain name in 
synchronized bursts of 10 queries supposedly from 10 different IP addresses?


that's what "Response Rate Limiting" is for


I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.


fine, that's *your* case - we host 800 domains and all the time some get
transferred to us and some get away


I agree with the concept of a blacklist


i don't because the IP is in most cases FORGED


how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.


"Response Rate Limiting"

again: the IP you mostly see is FORGED and the victim not the attacker
and all you do is blacklisting the innocent victim which never did
anything bad

with automated blacklisting you expose yourself to a simple DOS attack -
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i
take your domain offline for anybody on the planet using the google
resolvers

and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP
resolvers for endusers - game over, you blacklisted the world


________
From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

that machine was sadly the primary NS for 800 domains and over the
months the old ip could have been ru-used for a new customer running a
nameserver for completly different domains

--

long story short: no sane service should supress replies completly
unless a explicit blacklist saying so is involved



From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a

Re: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 16.12.21 um 14:04 schrieb Andrew P.:
So you're claiming that legitimate resolvers would still be pointing at the wrong IP address for a public DNS server after over 16 years? 


besides that i don't know why you are answering off-list nowhere did i 
say anything about 16 years


but it can take time

just because some IP is asking for a domain you don't host is for sure 
not a justification for automated blacklisting - that will happen 
regulary after domain-transfers for some time


And asking repeatedly and rapidly for the same illegal root domain name in synchronized bursts of 10 queries supposedly from 10 different IP addresses? 


that's what "Response Rate Limiting" is for


I say that because I have held the particular static IPv4 address that my 
nameserver is running on for that long, and I have never run a root nameserver 
of any sort, or hosted domains for anyone but myself.


fine, that's *your* case - we host 800 domains and all the time some get 
transferred to us and some get away



I agree with the concept of a blacklist


i don't because the IP is in most cases FORGED


how do I set up one on my copy of bind so I can refuse to answer those obvious 
DNS DDoS attacks? While still answering legitimate requests for the domains I 
do hosts, that is.


"Response Rate Limiting"

again: the IP you mostly see is FORGED and the victim not the attacker 
and all you do is blacklisting the innocent victim which never did 
anything bad


with automated blacklisting you expose yourself to a simple DOS attack - 
when i forge 8.8.8.8 and 8.8.4.4 and you do automated blacklisting i 
take your domain offline for anybody on the planet using the google 
resolvers


and after 8.8.8.8 and 8.8.4.4 i feed you with a list of all known ISP 
resolvers for endusers - game over, you blacklisted the world




From: bind-users  on behalf of Reindl Harald 

Sent: Wednesday, December 15, 2021 8:44 AM
To: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied



Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct
it from packet loss leading to retries?

--

"Since no legitimate resolver would be asking a non authoritative server
for information" isn't true at all

years ago we moved a server to a different location and all sorts of ISP
resolvers did respond with old IPs months later, the dumbest one even
played lottery responding 50% old and 50% new IP

i found that out by random complaints because one domain had 60 count
subdomains and started to query all open rsolvers i was able to find
with script's - a tragedy

that machine was sadly the primary NS for 800 domains and over the
months the old ip could have been ru-used for a new customer running a
nameserver for completly different domains

--

long story short: no sane service should supress replies completly
unless a explicit blacklist saying so is involved



From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a bad thing by using fail2ban to block these IPs?


That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

___
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: Nice new logging feature

[Reindl Harald]

Am 16.12.21 um 10:02 schrieb Borja Marcos:


Hi,

I am trying 9.17 at home and I just noticed a very useful new lame-servers log 
message:

2021-12-16T08:08:20.505Z lame-servers: timed out resolving 
’stupiddomain.com/ANY/IN': X.Y.Z.T#53

I haven’t seen this on 9.16. Are there any plans to include it? 


bind-9.16.23-1.fc34.x86_64

16-Dec-2021 13:08:10.598 lame-servers: connection refused resolving 
'ns2.serverion.eu/A/IN': 94.228.210.122#53
16-Dec-2021 13:11:29.269 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 45.79.19.196#53
16-Dec-2021 13:11:31.804 lame-servers: host unreachable resolving 
'250.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:10.567 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 198.58.118.167#53
16-Dec-2021 13:12:13.903 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.18.44#53
16-Dec-2021 13:12:14.034 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:12:15.773 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 45.33.23.183#53
16-Dec-2021 13:12:15.938 lame-servers: host unreachable resolving 
'166.84.141.45.in-addr.arpa/PTR/IN': 96.126.123.244#53
16-Dec-2021 13:12:46.937 lame-servers: connection refused resolving 
'mx4.itronic.at/A/IN': 85.124.85.125#53
16-Dec-2021 13:13:41.202 lame-servers: host unreachable resolving 
'70.84.141.45.in-addr.arpa/PTR/IN': 72.14.185.43#53
16-Dec-2021 13:13:45.334 lame-servers: host unreachable resolving 
'70.84.141.45.in-addr.arpa/PTR/IN': 45.33.2.79#53
16-Dec-2021 13:13:46.953 lame-servers: REFUSED unexpected RCODE 
resolving '_.93.226.171.in-addr.arpa/A/IN': 203.113.131.1#53
16-Dec-2021 13:13:47.315 lame-servers: FORMERR resolving 
'_.93.226.171.in-addr.arpa/A/IN': 203.113.188.2#53
16-Dec-2021 13:13:47.601 lame-servers: REFUSED unexpected RCODE 
resolving '110.93.226.171.in-addr.arpa/PTR/IN': 203.113.131.1#53

___
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: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 15.12.21 um 15:01 schrieb John Kristoff:

Would I be doing a bad thing by using fail2ban to block these IPs?


This might be dangerous.  If someone spoofs a well formed UDP query
that does what the above does and you block it, what if the spoofed
source is something you don't want blocked?  This doesn't happen often,
but I've seen it happen and people have gotten badly burned by it


it's even an attack surface

nothing easier than forge udp queries to trigger fail2ban for whatever 
IP the attacker wants


feed it with ISP and google resolvers to take your domains down for a 
large part of the world


it's called "self-DOS" - "denial of service" don't need much resources, 
it's enough when you are taking you down at your own

___
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: Millions of './ANY/IN' queries denied

[Reindl Harald]

Am 15.12.21 um 14:33 schrieb Andrew P.:

So why isn't there a way to tell BIND not to respond to queries for which it 
clearly is not authoritative (such as these attack vectors)? Since no 
legitimate resolver would be asking a non-authoritative server for information, 
why should his (or my) public BIND server respond to these even with an error 
message?


because in case of UDP it would make things much worser

how do the client smell that you didn't respond by purpose and distinct 
it from packet loss leading to retries?


--

"Since no legitimate resolver would be asking a non authoritative server 
for information" isn't true at all


years ago we moved a server to a different location and all sorts of ISP 
resolvers did respond with old IPs months later, the dumbest one even 
played lottery responding 50% old and 50% new IP


i found that out by random complaints because one domain had 60 count 
subdomains and started to query all open rsolvers i was able to find 
with script's - a tragedy


that machine was sadly the primary NS for 800 domains and over the 
months the old ip could have been ru-used for a new customer running a 
nameserver for completly different domains


--

long story short: no sane service should supress replies completly 
unless a explicit blacklist saying so is involved




From: bind-users  on behalf of Ondřej Surý 

Sent: Wednesday, December 15, 2021 7:18 AM
To: Danilo Godec
Cc: bind-users@lists.isc.org
Subject: Re: Millions of './ANY/IN' queries denied


Would I be doing a bad thing by using fail2ban to block these IPs?


That’s the question that only you can answer.  The IP addresses are
not attacker’s but victim’s and you would be punishing those networks
by blocking access from them to your network.

Do you absolutely know that these IP addresses doesn’t need access
to your DNS?  If yes, then go ahead.

___
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: host your subdomain on your own ?

[Reindl Harald]

Am 13.11.21 um 17:20 schrieb Grant Taylor via bind-users:

On 11/13/21 9:07 AM, Reindl Harald wrote:

* he needs the delegation because lack of control


Maybe I've lost context, but I thought the overall theme of the thread 
was delegating to a private IP address


"Because I might not be able to control nor have input into 
local-private bind(s)" is the simple reason for the whole thread


otherwise he could make sure they forward the zone over the VPN and case 
closed


now that he can't control the name resolution in the other networks all 
the delegation stuff will simply fail if they use a ISP or 
public-nameserver like 8.8.8.8


how are they supposed to use the *split-horizon* setup from the initial 
post?

___
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: host your subdomain on your own ?

[Reindl Harald]

Am 13.11.21 um 17:00 schrieb Grant Taylor via bind-users:

On 11/13/21 12:59 AM, Reindl Harald wrote:
i doubt that any ISP out there would delegate to a private address and 
when your bind is asked over it's public IP a view won't work


ISP's willingness to do something is a policy decision and that's 
completely different than their capability to do something which is a 
technology decision.


but you have to deal with it

I see zero reason that a parent zone operator can't delegate something 
to a private / non-globally-routed IP.



chicken / egg


Not necessarily.  Just because the Internet at large can't access the IP 
that the child zone is delegated to doesn't mean that business partner's 
can't access it.  --  I believe that I saw in one of the messages that 
there was a VPN between the sites / business partners which did support 
/ provide routing to the private IP.


In some ways, this is similar to making something resolve to 127.0.0.1 
and / or ::1.  That information can be published in globally accessible 
DNS, but it will likely be of very limited value.


you missed my second post!

* he needs the delegation because lack of control
* when the clients network is using a public
  forwarder the delegation simply can't work
* so the problem is lack of control and can't be solved

personally i would simply add additional names point to the LAN 
addresses in my normal public zone, you don't even need a full subdomain 
zone for add "something.priv.example.com" poining to 192.168.196.10




and not to forget: most networks are forwarding to some public 
nameserver which can't reach your private named at all


8.8.8.8 (google) can't hit your internal view

when you can't control something it's exactly that
___
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: host your subdomain on your own ?

[Reindl Harald]

Am 13.11.21 um 08:59 schrieb Reindl Harald:



Am 13.11.21 um 08:16 schrieb Erich Eckner:

On Sat, 13 Nov 2021, Reindl Harald wrote:

i mean when it's private and not www why does the world need to know
about the subdomain?


Because I might not be able to control nor have input into
local-private bind(s) and thus...
clients/nodes on private networks would query www/public bind and
only then would learn of 'priv.zone.top' and then, via that
delegation to my own binds, 'priv.zone.top' would be served to
local-private networks.
- here is where 'views' come to mind, on my binds...


i doubt that any ISP out there would delegate to a private address and 
when your bind is asked over it's public IP a view won't work


chicken / egg


and not to forget: most networks are forwarding to some public 
nameserver which can't reach your private named at all


8.8.8.8 (google) can't hit your internal view

when you can't control something it's exactly that



___
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: host your subdomain on your own ?

[Reindl Harald]

Am 13.11.21 um 08:16 schrieb Erich Eckner:

On Sat, 13 Nov 2021, Reindl Harald wrote:

i mean when it's private and not www why does the world need to know
about the subdomain?


Because I might not be able to control nor have input into
local-private bind(s) and thus...
clients/nodes on private networks would query www/public bind and
only then would learn of 'priv.zone.top' and then, via that
delegation to my own binds, 'priv.zone.top' would be served to
local-private networks.
- here is where 'views' come to mind, on my binds...


i doubt that any ISP out there would delegate to a private address and 
when your bind is asked over it's public IP a view won't work


chicken / egg


___
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: host your subdomain on your own ?

[Reindl Harald]

Am 12.11.21 um 18:55 schrieb lejeczek via bind-users:

On 12/11/2021 17:14, Reindl Harald wrote:
wouldn't it be easier to setup two different subdomains in which case 
you don't need delegation at all - your local named would hist the 
internal subdomain and doing recursion for everything else


i mean when it's private and not www why does the world need to know 
about the subdomain?


Because I might not be able to control nor have input into local-private 
bind(s) and thus...
clients/nodes on private networks would query www/public bind and only 
then would learn of 'priv.zone.top' and then, via that delegation to my 
own binds, 'priv.zone.top' would be served to local-private networks.

- here is where 'views' come to mind, on my binds...


don't get me wrong but when you a) control a local bind where b) a 
public resolver delegates a subzone you should also be able to control 
that clients in this network use your named via dhcp

___
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: host your subdomain on your own ?

[Reindl Harald]

Am 12.11.21 um 17:48 schrieb lejeczek via bind-users:

Hi guys.

I'm looking to setup my subdomin in-house and I'm hoping for some wise 
advises from experts, it's my first foray into this thus go easy on me 
please.


zone.top - is hosted by a public registrar
priv.zone.top - I want to delegate to my own bind
I'd hope for some generic recipe and pointer to docs, thanks.


needs to be done in the parent zone by whoever hosts it

Now what I think might be the tricky part though I get that an expert 
might say - trivial.
I am thinking of 'views' or split-horizon or whatever other nomenclature 
applies, though I hear that that/those are discouraged by experts?
Or! might that above be unnecessary(?) if, it's possible and allowed 
that such public, mine bind will resolve to IPs which are 'private' - 
all that so my 'priv.zone.top' will resolve to whole www but resources 
of the zone/domain will be available, as they are, only in/via private 
networks.


Does that make sense?


wouldn't it be easier to setup two different subdomains in which case 
you don't need delegation at all - your local named would hist the 
internal subdomain and doing recursion for everything else


i mean when it's private and not www why does the world need to know 
about the subdomain?



___
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 service suddenly fails to start

[Reindl Harald]

Am 04.11.21 um 21:11 schrieb Grant Taylor via bind-users:

On 11/4/21 1:27 PM, Bruce Johnson via bind-users wrote:
named-checkconf -z revealed a name had been entered with underscores. 
The person responsible has been sacked. (not really, merely reminded 
no underscores are allowed in A records :-)


You might want to apologize to them.

Underscores are legitimate in DNS record owner names, despite the 
disagreement of their use in hostnames.


how does that matter in context of "no underscores are allowed in A 
records"?

___
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 service suddenly fails to start

[Reindl Harald]

Am 04.11.21 um 20:27 schrieb Bruce Johnson via bind-users:
On Nov 4, 2021, at 12:01 PM, Bruce Johnson > wrote:


This morning our server started failing to reload or start.

checking the status reveals not a lot of info:

systemctl status named-chroot
● named-chroot.service - Berkeley Internet Name Domain (DNS)
  Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; 
enabled; vendor preset: disabled)
  Active: failed (Result: exit-code) since Thu 2021-11-04 11:55:17 
MST; 27s ago
 Process: 2020 ExecStartPre=/bin/bash -c if [ ! 
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -t 
/var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files 
is disabled"; fi (code=exit>


named-checkconf -z revealed a name had been entered with underscores. 
The person responsible has been sacked. (not really, merely reminded no 
underscores are allowed in A records :-)


Does named-checkzone not check for this?


but what should it do at the point of a service restart?

the better question is why don't your admin backends prevent such mistakes
___
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 service suddenly fails to start

[Reindl Harald]

Am 04.11.21 um 20:01 schrieb Bruce Johnson via bind-users:

This morning our server started failing to reload or start.

checking the status reveals not a lot of info:

systemctl status named-chroot
● named-chroot.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; 
vendor preset: disabled)
Active: failed (Result: exit-code) since Thu 2021-11-04 11:55:17 MST; 27s 
ago
   Process: 2020 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; then 
/usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; else echo "Checking of zone files is 
disabled"; fi (code=exit>

Nov 04 11:55:17 elixir bash[2020]: zone 126.140.10.IN-ADDR.ARPA/IN: loaded 
serial 4
Nov 04 11:55:17 elixir bash[2020]: zone 233.196.128.IN-ADDR.ARPA/IN: loaded 
serial 350
Nov 04 11:55:17 elixir bash[2020]: zone 
pharm-classless.124.135.150.IN-ADDR.ARPA/IN: loaded serial 4830
Nov 04 11:55:17 elixir bash[2020]: zone 
bio5-classless.123.135.150.in-addr.arpa/IN: loaded serial 402
Nov 04 11:55:17 elixir bash[2020]: zone 18.129.10.IN-ADDR.ARPA/IN: loaded 
serial 4755
Nov 04 11:55:17 elixir bash[2020]: zone 19.129.10.IN-ADDR.ARPA/IN: loaded 
serial 4756
Nov 04 11:55:17 elixir bash[2020]: zone 118.193.10.IN-ADDR.ARPA/IN: loaded 
serial 9
Nov 04 11:55:17 elixir systemd[1]: named-chroot.service: Control process 
exited, code=exited status=1
Nov 04 11:55:17 elixir systemd[1]: named-chroot.service: Failed with result 
'exit-code'.
Nov 04 11:55:17 elixir systemd[1]: Failed to start Berkeley Internet Name 
Domain (DNS).

We have one dynamically updated zone and only three other zone files that have 
been updated today and named-checkzone says they’re ok.

I'm guessing it’s the zone file after the last successfully loaded one, but we 
have a LOT of zone files; is there a particular order in which they’re loaded 
at startup? I’ve made no changed to named.conf or anything else on this server


ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == "yes" ]; 
then /usr/sbin/named-checkconf -t /var/named/chroot -z "$NAMEDCONF"; 
else echo "Checking of zone files is disabled"; fi (code=exi


this nonsense of bash in systemd units typically comes from 
distributions and so you should at least name which one you are using

___
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: Query on issue#2389 BIND 9.16.10

[Reindl Harald]

Am 19.10.21 um 00:46 schrieb raf:

On Mon, Oct 18, 2021 at 01:02:07PM +0200, Reindl Harald 
 wrote:


Am 18.10.21 um 12:57 schrieb Rajnish Kamboj via bind-users:

Upgrading to latest release will fix the issue


lesson to learn: report issues after you made sure you are using the latest
version which probably would fix it


Can you also help us with scenarios as to why this issue is occurring?
May be this will help us in quick workaround (if possible) till the time we 
plan for latest BIND.


what exactly do you need to plan?
just update!

shoudn't take more than 5 minutes with packages

9.16.10 to 9.16.21 is a bugfix update, case closed


Packaging is not always that simple. For example, on
Debian stable, the current version is 9.16.15. However,
the Debian team will backport security patches from
9.5.16-21 if necessary.


dunno Debian well but on Fedora 2007 it took me not that much time to 
learn build rpms


when one have issues with 9.16.10 it's not likely Debian at all - look 
at 9.16.15 versus 9.16.10 from the OP


even Debian seems to be more recent and i don't like the "we are smarter 
than upstream on only god knows which fixes our package 
contains"-attitude to say it polite


so what's the point of running 9.16.10?

look "Upgrading to latest release will fix the issue" means "i know what 
will fix the issue but i still seek for whatever workaround instead 
solve the problem"

___
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: Query on issue#2389 BIND 9.16.10

[Reindl Harald]

Am 18.10.21 um 12:57 schrieb Rajnish Kamboj via bind-users:

Upgrading to latest release will fix the issue


lesson to learn: report issues after you made sure you are using the 
latest version which probably would fix it



Can you also help us with scenarios as to why this issue is occurring?
May be this will help us in quick workaround (if possible) till the time we 
plan for latest BIND.


what exactly do you need to plan?
just update!

shoudn't take more than 5 minutes with packages

9.16.10 to 9.16.21 is a bugfix update, case closed


-Original Message-
From: Ondřej Surý 
Sent: Monday, October 18, 2021 3:28 PM
To: Rajnish Kamboj 
Cc: bind-users@lists.isc.org
Subject: Re: Query on issue#2389 BIND 9.16.10

Hi,

there were several security issues since 9.16.10, you should be running either 
last 9.16.x release (9.16.21 as of time writing this email) or have all of the 
issues patched.

The thing you are asking for is so wrong on so many levels. Don’t do that, 
upgrade to last version instead.


On 18. 10. 2021, at 11:51, Rajnish Kamboj via bind-users 
 wrote:

Hi Team,
Currently we are using Bind version 9.16.10,
  
My Query

I recently found that there is an issue with the 9.16.10 version. "Issue#2389 BIND 
9.16.10: critical: xfrout.c:1643: INSIST(xfr->sends == 0) failed".
Can anyone please help me to understand the scenario when this issue will 
appear?
  
Note: We are not planning an BIND upgrade currently. This will help me to skip scenarios which may lead to the above issue.


Thanks in advance

___
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 doesn't stop contacting global ROOT DNS servers after commenting(#) the the root hint zone in named.conf

[Reindl Harald]

Am 02.08.21 um 17:28 schrieb Ramesh:

Hello,

I commented the root hint zone section(default) in the named.conf file 
to stop bind from communicating to the global root DNS servers and it 
should only use the internal forwarders available in the options{} section.


|#zone "." IN { # type hint; # file "named.ca "; #};|

But the BIND still communicates to the ROOT DNS server when the query 
can't be answered by the internal forwarders.


* Is this a default behavior?


yes


* Does bind has an inbuilt root hint zone even though the zone is not
 defined in the namd.conf file?


yes
___
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-chroot is not re-positioning my forward and reverse tables

[Reindl Harald]

Am 28.06.21 um 00:44 schrieb ToddAndMargo via bind-users:

On 6/27/21 3:40 PM, ToddAndMargo via bind-users wrote:

On 6/26/21 7:31 PM, ToddAndMargo via bind-users wrote:

On 6/24/21 9:00 PM, ToddAndMargo via bind-users wrote:

The goal is to have bind-chroot do its thing


mount --bind

https://bugzilla.redhat.com/show_bug.cgi?id=1972022#c3

It is not occurring on my zone files.  Is it suppose to?



I have moved my zone fines to /var/named

Mount bind still does not get them.  I had to
manually copy them over.


zone "abc.local" {
 type master;
 # file "/var/named/chroot/var/named/abc.hosts";
 file "abc.hosts";
 allow-update { key DHCP_UPDATER; };
#   allow-update { 127.0.0.1; };
};

zone "255.168.192.in-addr.arpa" {
 type master;
 # file "/var/named/chroot/var/named/abc.hosts.rev";
 file "abc.hosts.rev";
 allow-update { key DHCP_UPDATER; };
#   allow-update { 127.0.0.1; };
};


I am beginning to wonder if mount bind does not
mount bind your zone files, only /etc/named.conf and
named.root.key


seriosly i am beginning to wonder if you should simply give up bind-chroot

it's not the job of the chroot bind-mount setup to mount each and every 
file and 'file "abc.hosts.rev"' without any path makes no sense


just write your files where they are expected from the viewpoint of the 
chroot and ignore "/var/named/chroot" in your configs because it simply 
don't exist from the viewpoint of the process running inside the chroot


anyways, that's not a bind topic at all
___
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: Managing localhost

[Reindl Harald]

Am 25.06.21 um 03:22 schrieb Grant Taylor via bind-users:
Tony's statements surprised me enough that I shaved them for later deep 
read and pondering.  That time has now come.


On 6/21/21 11:00 AM, Tony Finch wrote:
That advice is out of date: nowadays you should not put any localhost 
entries in the DNS, because it can cause problems for web browser 
security. Modern software should suppress queries for localhost so 
they never reach the DNS.


If I'm understanding the problem correctly, it seems to come down to 
anything involving localhost /except/ fully qualified 
localhost.(implicit null).


My motivation was wanting to understand how what Tony was relaying 
related to localhost being it's own top level zone with only an A and / 
or  record(s) resolving to 127.0.0.1 and / or ::1 respectively.


I'm still not convinced that fully qualified localhost.(implicit null) 
is a problem in and of itself.  But I see how unqualified localhost can 
~> is a problem.


he is talking about "localhost.example.com" and nothing else
___
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: do I need to configure a Caching Server

[Reindl Harald]

please only reply to the list

Am 21.06.21 um 18:28 schrieb techli...@phpcoderusa.com:
I am setting up a SOHO PHP web server on my business cable account that 
allows for running servers.  This is a product for small home bound 
businesses.


I have BIND working. The website I am hosting  : 
http://www.keiththewebguy.com/


how is that related to "do I need to configure a Caching Server" and 
forwarders or bringing something new to the response you are quoting?


* you don't need forwarfders at all
* auth zones are not cached anyways
* anything else is cached anyways

just let do named it's job as it does out-of-the-box as said below


On 2021-06-19 01:14, Reindl Harald wrote:

Am 18.06.21 um 20:28 schrieb techli...@phpcoderusa.com:
I am building a home PHP hosting server for learning.  I have a 
commercial connection to the Internet so no blocked ports and my ISP 
allows servers.


unless you are hosting a authoritative zone aka domain on your
nameserver it don't matter what your ISP allows

if you are not hosting any official zone you shouldn't have the port
open to the world because nobody but bots and attackers will ask your
server anyways


I believe I only need a Primary Master Server.  Is this the case?


what is your usecase to begin with?

if it's just internal hostnames for your LAN maybe dnsmasq is the
better solution because it can use simple hostfiles like /etc/hosts
and forwards everything else to your ISP nameserver


My question is, do I need to configure a Caching Server?


there is nothing to configure, if you ask your named for something
it's not authoritative it either forwards or doing recursion (depends
on the configuration) and cache the result based on the TTL


In /etc/bind/named.conf.options:


 [...]

 forwarders {
  1.2.3.4;
  5.6.7.8;
 };

 [...]

Do I need to set the forwarders?


no

let named do it's out-of-the-box job which is recursion - i can't
think of any usecase where i do the work setup a nameserver and then
forward everything to a crappy ISP server

after stop using forwarding all random dns problems where gone and
never came back

___
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: Origin of reverse lookup

[Reindl Harald]

FIRST: this will be my last response to you and if it's only to prevent 
using words leading to moderation


Am 19.06.21 um 15:46 schrieb alcol alcol:

Ohuu I haven't written slave but was not your email
if you want to say something don't quote others taht say right things


please understand that this is my decision


if I don't use words as you could use or like is not your matter


sorry for correcting wrong technical terms and understanding, either 
learn to deal with it or don't ask on places where professionals are present


>>> in past I had a master reverse lookup
>>> maintained from me downloaded from
>>> isp becous iana can't go around the
>>> world to download and to avoid
>>> issues in download.

this is nosense

a) IANA don't download anything from nowhere
b) zone transfers are not downloads
c) worldwide dns don't work that way

RECURSION:

* the resolver asks the root which
  nameserver is responsible for the TLD
* the tld registry tell him the
  nameserver for the zone
* finally it asks that nameservers

how they got their zone-data is irrelevant, the autoritative nameservers 
just respond to specific queries


you initally asked "find who is hosting this reverse lookup?" and the 
answer is simply: look the SOA of the reverse-name


[harry@srv-rhsoft:/downloads]$ dig SOA 6.73.118.91.in-addr.arpa. @8.8.8.8

; <<>> DiG 9.11.32-RedHat-9.11.32-1.fc33 <<>> SOA 
6.73.118.91.in-addr.arpa. @8.8.8.8

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39068
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;6.73.118.91.in-addr.arpa.  IN  SOA

;; AUTHORITY SECTION:
73.118.91.in-addr.arpa. 1799IN  SOA ns2.thelounge.net. 
hostmaster.thelounge.net. 2021050714 3600 1800 1814400 3600


as last part of your reply, please think to yourself as you started to 
quote me with no meaning saying same things as me




Why do you look at the speck that is in your brother's eye and don't 
notice the beam that is in your eye?


--------
*From:* bind-users  on behalf of 
Reindl Harald 

*Sent:* Saturday, June 19, 2021 2:23 PM
*To:* bind-users@lists.isc.org 
*Subject:* Re: Origin of reverse lookup


Am 19.06.21 um 13:24 schrieb alcol alcol:

I see you have time to waste saying strange things


seriously?

dns zones even forard or reverse are downloaded as configured from 
masters to slaves or where are needed


may you show me word "slave" in any line below?


all other remarks are confirmations of what said



that must be why you started with:

  >> Any thoughts on how I might resolve this
  >> or find who is hosting this reverse lookup?


I see u have time to waste  is clear 樂


don't get me wrong but when you know that little about DNS that you
expect a service on the internet cares about what you configured at your
local box you shouldn't be that arrogant!

  >> When I run https://intodns.com/ <https://intodns.com/>
  >> it shows this reverse lookup and not
  >> the one I just configured on my local box.



*From:* bind-users  on behalf of 
Reindl Harald 

*Sent:* Saturday, June 19, 2021 12:36 PM
*To:* bind-users@lists.isc.org 
*Subject:* Re: Origin of reverse lookup


Am 19.06.21 um 12:10 schrieb alcol alcol:

ISP Have is a normale DNS zone as forward ones

they does not offer remote mainteining as you should own all subnet 
class and are directly downloaded from iana if I remember well.


ptr zones are the same way delegated as any other zones


if something go wrong with the zone ISP will have issue from tld.


no

in past I had a master reverse lookup maintained from me downloaded from 
isp becous iana can't go around the world to download and to avoid 
issues in download.


dns zones are not downloaded

as are zones with so few changes isp could allow something like a 
cpannel to change some records.


that don't scale given that most customers just have a single IP

in case you have a /24 the ISP can delegate the whole zone to you, look
at the authoritative nameservers below

[harry@srv-rhsoft:/downloads]$ dig -x 91.118.73.6

; <<>> DiG 9.11.32-RedHat-9.11.32-1.fc33 <<>> -x 91.118.73.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
; COOKIE: 68fa6f61a7537e2c684ca5d260cdc67126f45c0615547511 (good)
;; QUESTION SECTION:
;6.73.118.91.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
6.73.118.91.in-addr.arpa. 7200  IN  PTR arrakis.thelounge.net

Re: Origin of reverse lookup

[Reindl Harald]

Am 19.06.21 um 13:24 schrieb alcol alcol:

I see you have time to waste saying strange things


seriously?

dns zones even forard or reverse are downloaded as configured from 
masters to slaves or where are needed


may you show me word "slave" in any line below?


all other remarks are confirmations of what said



that must be why you started with:

>> Any thoughts on how I might resolve this
>> or find who is hosting this reverse lookup?


I see u have time to waste  is clear 樂


don't get me wrong but when you know that little about DNS that you 
expect a service on the internet cares about what you configured at your 
local box you shouldn't be that arrogant!


>> When I run https://intodns.com/
>> it shows this reverse lookup and not
>> the one I just configured on my local box.


----
*From:* bind-users  on behalf of 
Reindl Harald 

*Sent:* Saturday, June 19, 2021 12:36 PM
*To:* bind-users@lists.isc.org 
*Subject:* Re: Origin of reverse lookup


Am 19.06.21 um 12:10 schrieb alcol alcol:

ISP Have is a normale DNS zone as forward ones

they does not offer remote mainteining as you should own all subnet 
class and are directly downloaded from iana if I remember well.


ptr zones are the same way delegated as any other zones


if something go wrong with the zone ISP will have issue from tld.


no

in past I had a master reverse lookup maintained from me downloaded from 
isp becous iana can't go around the world to download and to avoid 
issues in download.


dns zones are not downloaded

as are zones with so few changes isp could allow something like a 
cpannel to change some records.


that don't scale given that most customers just have a single IP

in case you have a /24 the ISP can delegate the whole zone to you, look
at the authoritative nameservers below

[harry@srv-rhsoft:/downloads]$ dig -x 91.118.73.6

; <<>> DiG 9.11.32-RedHat-9.11.32-1.fc33 <<>> -x 91.118.73.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
; COOKIE: 68fa6f61a7537e2c684ca5d260cdc67126f45c0615547511 (good)
;; QUESTION SECTION:
;6.73.118.91.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
6.73.118.91.in-addr.arpa. 7200  IN  PTR arrakis.thelounge.net.

;; AUTHORITY SECTION:
73.118.91.in-addr.arpa. 7200    IN  NS  ns1.thelounge.net.
73.118.91.in-addr.arpa. 7200    IN  NS  ns2.thelounge.net.

;; ADDITIONAL SECTION:
ns2.thelounge.net.  7200    IN  A   91.118.73.
ns1.thelounge.net.  7200    IN  A   85.124.176.242

usually reverse lookup are resolved with a standard naming with ip and 
isp name


for consumer ranges: yes

if you run a mail server could be usefull 


if you run a mailserver it is a must, at least when you care to deliver
your mails, as well make sure your HELO-hostname matches too

many sites add at least points to the sapm scoring for clients like that:

warning: hostname szkoleniagospodarka.pl does not resolve to address
51.75.72.176: Name or service not known

if not a reverse lookup is not 
so much used


well, in case of servers i prefer PTR/A matching no matter if it is
supposed to send mail and the same goes for internal networks i maintain



*From:* bind-users  on behalf of 
techli...@phpcoderusa.com 

*Sent:* Saturday, June 19, 2021 1:17 AM
*To:* bind-users@lists.isc.org 
*Subject:* Origin of reverse lookup
Hi,

I had my ISP configure a reverse lookup years ago.  They say they no
longer offer that service and there is no reverse lookup for my IP.

I keep running into this old reverse lookup and do not know where it is
coming from.

When I run https://intodns.com/ <https://intodns.com/> <https://intodns.com/ 

<https://intodns.com/>> it shows this

reverse lookup and not the
one I just configured on my local box.

Any thoughts on how I might resolve this or find who is hosting this
reverse lookup?

___
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: Origin of reverse lookup

[Reindl Harald]

Am 19.06.21 um 12:10 schrieb alcol alcol:

ISP Have is a normale DNS zone as forward ones

they does not offer remote mainteining as you should own all subnet 
class and are directly downloaded from iana if I remember well.


ptr zones are the same way delegated as any other zones


if something go wrong with the zone ISP will have issue from tld.


no

in past I had a master reverse lookup maintained from me downloaded from 
isp becous iana can't go around the world to download and to avoid 
issues in download.


dns zones are not downloaded

as are zones with so few changes isp could allow something like a 
cpannel to change some records.


that don't scale given that most customers just have a single IP

in case you have a /24 the ISP can delegate the whole zone to you, look 
at the authoritative nameservers below


[harry@srv-rhsoft:/downloads]$ dig -x 91.118.73.6

; <<>> DiG 9.11.32-RedHat-9.11.32-1.fc33 <<>> -x 91.118.73.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21949
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
; COOKIE: 68fa6f61a7537e2c684ca5d260cdc67126f45c0615547511 (good)
;; QUESTION SECTION:
;6.73.118.91.in-addr.arpa.  IN  PTR

;; ANSWER SECTION:
6.73.118.91.in-addr.arpa. 7200  IN  PTR arrakis.thelounge.net.

;; AUTHORITY SECTION:
73.118.91.in-addr.arpa. 7200IN  NS  ns1.thelounge.net.
73.118.91.in-addr.arpa. 7200IN  NS  ns2.thelounge.net.

;; ADDITIONAL SECTION:
ns2.thelounge.net.  7200IN  A   91.118.73.
ns1.thelounge.net.  7200IN  A   85.124.176.242

usually reverse lookup are resolved with a standard naming with ip and 
isp name


for consumer ranges: yes

if you run a mail server could be usefull 


if you run a mailserver it is a must, at least when you care to deliver 
your mails, as well make sure your HELO-hostname matches too


many sites add at least points to the sapm scoring for clients like that:

warning: hostname szkoleniagospodarka.pl does not resolve to address 
51.75.72.176: Name or service not known


if not a reverse lookup is not 
so much used


well, in case of servers i prefer PTR/A matching no matter if it is 
supposed to send mail and the same goes for internal networks i maintain




*From:* bind-users  on behalf of 
techli...@phpcoderusa.com 

*Sent:* Saturday, June 19, 2021 1:17 AM
*To:* bind-users@lists.isc.org 
*Subject:* Origin of reverse lookup
Hi,

I had my ISP configure a reverse lookup years ago.  They say they no
longer offer that service and there is no reverse lookup for my IP.

I keep running into this old reverse lookup and do not know where it is
coming from.

When I run https://intodns.com/  it shows this 
reverse lookup and not the

one I just configured on my local box.

Any thoughts on how I might resolve this or find who is hosting this
reverse lookup?

Thanks!!

___
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: Origin of reverse lookup

[Reindl Harald]

Am 19.06.21 um 01:17 schrieb techli...@phpcoderusa.com:
I had my ISP configure a reverse lookup years ago.  They say they no 
longer offer that service and there is no reverse lookup for my IP.


don't matter unless you try to send mails from your machine

I keep running into this old reverse lookup and do not know where it is 
coming from.


from the ISP owing the network range

When I run https://intodns.com/ it shows this reverse lookup and not the 
one I just configured on my local box.


whatever you configure on your box is irrelevant to the world unless the 
owner of the network range delegates the reverse zone to your server 
which is unlikely for most cases and impossible for a single IP


Any thoughts on how I might resolve this or find who is hosting this 
reverse lookup?


"whois ip"
___
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: do I need to configure a Caching Server

[Reindl Harald]

Am 18.06.21 um 20:28 schrieb techli...@phpcoderusa.com:
I am building a home PHP hosting server for learning.  I have a 
commercial connection to the Internet so no blocked ports and my ISP 
allows servers.


unless you are hosting a authoritative zone aka domain on your 
nameserver it don't matter what your ISP allows


if you are not hosting any official zone you shouldn't have the port 
open to the world because nobody but bots and attackers will ask your 
server anyways



I believe I only need a Primary Master Server.  Is this the case?


what is your usecase to begin with?

if it's just internal hostnames for your LAN maybe dnsmasq is the better 
solution because it can use simple hostfiles like /etc/hosts and 
forwards everything else to your ISP nameserver



My question is, do I need to configure a Caching Server?


there is nothing to configure, if you ask your named for something it's 
not authoritative it either forwards or doing recursion (depends on the 
configuration) and cache the result based on the TTL



In /etc/bind/named.conf.options:


     [...]

     forwarders {
  1.2.3.4;
  5.6.7.8;
     };

     [...]

Do I need to set the forwarders?


no

let named do it's out-of-the-box job which is recursion - i can't think 
of any usecase where i do the work setup a nameserver and then forward 
everything to a crappy ISP server


after stop using forwarding all random dns problems where gone and never 
came back


___
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: My FC33->FC34 bind-chroot upgrade notes

[Reindl Harald]

Am 17.06.21 um 21:43 schrieb ToddAndMargo via bind-users:

On 6/17/21 3:12 AM, Reindl Harald wrote:
however, in the real world just write "sudo command" is the best you 
can do - for the average user it's complete and leaves no questions


for power users which don't like sudo it should be no deal-breaker to 
type the command without "sudo" in a root shell


case closed



All I have to do is get over hating the sudo command


i don't use it too but i have no problem pastign something with "sudo" 
in front without into a terminal



And I kinda-sorta of expect anyone that uses "bind"
(power uses in the extreme -- genius level) to know
what # and $ at the prompt means


i am that much power-user that my prompt don't show that because i 
perfer colors for different roles and as short as possible prompts :-)

___
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: My FC33->FC34 bind-chroot upgrade notes

[Reindl Harald]

Am 17.06.21 um 07:43 schrieb Todd Chester via bind-users:

On 6/16/21 2:52 PM, Reindl Harald wrote:

Does this alteration at the top make it any clearer?


 Note: at the command prompt, I use the following terminology:
    # means run as root
    $ means run as user

 Inside a file, "#" mean it is a comment


not really - either use the ubuntu "sudo everything" or just type 
"root: command" and "user: command"


: that would confuse the dickens out of me.
I program in Raku (Perl 6) and  ":" has a bunch
of special meanings that I always forget.  So
":" give me a start


but when you follow a how-to which tells you commands to run in the 
terminal leaded by the user you don't do program in Raku


a) the typical user don't program at all
b) i expect from programmers some sense for context
c) # is typcally a comment
d) $ leads a variable in PHP, but we don't talk about PHP
e) the typical user won't remember what # and $ means

however, in the real world just write "sudo command" is the best you can 
do - for the average user it's complete and leaves no questions


for power users which don't like sudo it should be no deal-breaker to 
type the command without "sudo" in a root shell


case closed
___
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 do I identify if bind9 is using 4 cores?

[Reindl Harald]

Am 17.06.21 um 05:32 schrieb Manish Rane:

Hi Team,

I have BIND 9.16.17-Ubuntu on ubuntu and have 4 cores. I have configured

  more /etc/default/bind9
OPTIONS="-n 4"

And then restarted the services. How do I verify if bind9 has spawned 4 
processes and distributed among those?


it's threaded, so no processes and to verify just read your syslogs at 
restart/start of the service


Jun 17 11:59:58 srv-rhsoft named[241354]: found 8 CPUs, using 8 worker 
threads
Jun 17 11:59:58 srv-rhsoft named[241354]: using 7 UDP listeners per 
interface

Jun 17 11:59:58 srv-rhsoft named[241354]: using up to 21000 sockets
___
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: My FC33->FC34 bind-chroot upgrade notes

[Reindl Harald]

Am 16.06.21 um 20:31 schrieb ToddAndMargo via bind-users:

On 6/16/21 2:16 AM, Reindl Harald wrote:



Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users:

...
# means root
$ means user
...


Sometimes, in your configuration file extracts, you use '#' meaning
'this line is a comment'.  I guess this is a write-up for a novice.
The non-novices here have overlooked it, but I'm much closer to the
novice end of the BIND user spectrum than they are and If I were a
*complete* novice, I'd find these uses of '#' very confusing.


Which lines?


lines starting with #

--

here it is a comment sign

    Change /etc/resolv.conf back to
   search your_domain
   nameserver your_IP
   # nameserver 208.67.222.123

--

here it is meant as command running as root

Then restart the service:
  # systemctl restart bind-named.service


Does this alteration at the top make it any clearer?


     Note: at the command prompt, I use the following terminology:
    # means run as root
    $ means run as user

     Inside a file, "#" mean it is a comment


not really - either use the ubuntu "sudo everything" or just type "root: 
command" and "user: command"


___
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: My FC33->FC34 bind-chroot upgrade notes

[Reindl Harald]

Am 16.06.21 um 09:31 schrieb ToddAndMargo via bind-users:

...
# means root
$ means user
...


Sometimes, in your configuration file extracts, you use '#' meaning
'this line is a comment'.  I guess this is a write-up for a novice.
The non-novices here have overlooked it, but I'm much closer to the
novice end of the BIND user spectrum than they are and If I were a
*complete* novice, I'd find these uses of '#' very confusing.


Which lines?


lines starting with #

--

here it is a comment sign

   Change /etc/resolv.conf back to
  search your_domain
  nameserver your_IP
  # nameserver 208.67.222.123

--

here it is meant as command running as root

Then restart the service:
 # systemctl restart bind-named.service
___
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: Need Help with BIND9

[Reindl Harald]

Am 15.06.21 um 10:31 schrieb Reindl Harald:



Am 14.06.21 um 22:37 schrieb techli...@phpcoderusa.com:

keiththewebguy.com [1]. does not actually have the two nameservers
required though that is not the problem. (ns1 and ns2 have same IP)


I have a VPS that runs Plesk and there is only one name server so for 
every domain I have hosted on that VPS the domains have the same name 
server for both host names (at the register) I think some call these 
glue records.


we know that already and it's wrong

you can't have proper DNS with only one nameserver
you can't have proper DNS with two nameservers in the same network or on 
the same line


if you can't provide the minimum of *two* completly independent 
nameservers you can't host DNS - it's that easy


https://www.iana.org/help/nameserver-requirements

Minimum number of name servers

There must be at least two NS records listed in a delegation, and the 
hosts must not resolve to the same IP address.

___
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: Need Help with BIND9

[Reindl Harald]

Am 14.06.21 um 22:37 schrieb techli...@phpcoderusa.com:

keiththewebguy.com [1]. does not actually have the two nameservers
required though that is not the problem. (ns1 and ns2 have same IP)


I have a VPS that runs Plesk and there is only one name server so for 
every domain I have hosted on that VPS the domains have the same name 
server for both host names (at the register) I think some call these 
glue records.


we know that already and it's wrong

you can't have proper DNS with only one nameserver
you can't have proper DNS with two nameservers in the same network or on 
the same line


if you can't provide the minimum of *two* completly independent 
nameservers you can't host DNS - it's that easy


[harry@srv-rhsoft:~]$ nslookup ns1.thelounge.net 8.8.8.8
Server: 8.8.8.8
Address:8.8.8.8#53
Non-authoritative answer:
Name:   ns1.thelounge.net
Address: 85.124.176.242

[harry@srv-rhsoft:~]$ nslookup ns2.thelounge.net 8.8.8.8
Server: 8.8.8.8
Address:8.8.8.8#53
Non-authoritative answer:
Name:   ns2.thelounge.net
Address: 91.118.73.16
___
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: Need Help with BIND9

[Reindl Harald]

Am 12.06.21 um 14:30 schrieb Matus UHLAR - fantomas:

On 11.06.21 18:19, Sten Carlsen wrote:

From my place I resolve both to: 98.191.108.149

keiththewebguy.com. does not actually have the two nameservers 
required though that is not the problem. (ns1 and ns2 have same IP)


BIND seems to work ok but your local settings probably don't point 
your hosts to the right NS.


looks like you have registered domain on two servers, but failed to
provided the servers' IPs. "glue records" is what your domain needs

KEITHTHEWEBGUY.COM. 172800  IN  NS  NS1.KEITHTHEWEBGUY.COM.
KEITHTHEWEBGUY.COM. 172800  IN  NS  ns2.KEITHTHEWEBGUY.COM.
couldn't get address for 'NS1.KEITHTHEWEBGUY.COM': failure
couldn't get address for 'ns2.KEITHTHEWEBGUY.COM': failure
dig: couldn't get address for 'NS1.KEITHTHEWEBGUY.COM': no more


besides that it's not even clar if that zones are meant to be public 
and/or both public nameservers are really pointing to the machine with 
named in question


anyways:
https://intodns.com/

don't run public servers before doing the basic homework

---

this is a NO-GO - they need to be different machines which shouldn't 
live on the same network at all but never be the same machine


Domain NS records   Nameserver records returned by the parent servers are:

ns1.keiththewebguy.com.   ['98.191.108.149']   [TTL=172800]
ns2.keiththewebguy.com.   ['98.191.108.149']   [TTL=172800]

a.gtld-servers.net was kind enough to give us that information.

---

and *that* is why you need *at least* two independent nameservers for a 
domain



Mismatched NS records 	WARNING: One or more of your nameservers did not 
return any of your NS records.
Error 	DNS servers responded 	ERROR: One or more of your nameservers did 
not respond:

The ones that did not respond are:
98.191.108.149

---

Multiple Nameservers 	ERROR: Looks like you have less than 2 
nameservers. According to RFC2182 section 5 you must have at least 3 
nameservers, and no more than 7. Having 2 nameservers is also ok by me.


---

Missing nameservers reported by your nameservers 	You should already 
know that your NS records at your nameservers are missing, so here it is 
again:


ns1.keiththewebguy.com.
ns2.keiththewebguy.com.

---

SOA Error   SOA record  No valid SOA record came back!
MX 	Error 	MX Records	Oh well, I did not detect any MX records so you 
probably don't have any and if you know you should have then they may be 
missing at your nameservers!
WWW 	Error 	WWW A Record 	ERROR: I could not get any A records for 
www.keiththewebguy.com!


(I only do a cache request, if you recently added a WWW A record, it 
might not show up here.)

___
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

[Reindl Harald]

Am 05.06.21 um 19:15 schrieb Ondřej Surý:

Folks, I would appreciate if we can say on the topic. Specifically, I consider 
this rhetorical discussion on the meaning of the word “portable” neither useful 
to the subscribers of this list nor productive.


besides that - i didn't hear a serious reasoning for a native named 
binary on windows these days and given there are tons of ways running a 
linux binary compared to 20 years ago i call it a waste of time


* it eats time better invested
* it makes code more complex
* more complex code implies more errors


___
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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported

[Reindl Harald]

Am 03.06.21 um 20:12 schrieb Danny Mayer via bind-users:
I don't speak for ISC but it's important to understand that support of 
an operating system costs money and unless a company or organization is 
willing to step up with money it cannot be expected to continue support. 
There was originally a need and the money for BIND9 on Windows which is 
why the effort was made.


that's an unproven claim

my unproven claim based on expierience is that these days there was a 
need for named, httpd, php, mysqld and so on on windows


these days where virtualization, WSL and containers exists that need is 
more or less gone



On 6/3/21 4:03 AM, Richard T.A. Neal wrote:
Thanks Vicky and Ondrej for providing clarity. I'll be sad to see it 
when this happens but as I said in my original post I don't 
underestimate the sheer amount of effort required to maintain BIND for 
Windows going forwards so it's completely understandable that you want 
to focus on platforms that are the most widely used and best 
understood by ISC. The retention of the dig client for Windows, even 
if unsupported, will indeed be welcomed by some.


I'll shift my own focus back to BIND on Linux now as well, but I'll 
retain a tertiary BIND server running 9.16 for Windows just so that I 
can help out anyone who subsequently downloads and installs BIND for 
Windows between now and its end-of-support date.

___
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: Unable to start name

[Reindl Harald]

Am 09.04.21 um 08:07 schrieb rams:

Apr 09 05:19:38  named[1354]: generating session key for dynamic DNS
Apr 09 05:19:38 named[1354]: could not create /var/run/named/session.key
Apr 09 05:19:38 named[1354]: failed to generate session key for dynamic 
DNS: permi...ied


/var/run point to /run which is tmpfs and subfolders needs to be 
re-created at boot, normally there should be a config which ensures that 
and be part of the package


cat /usr/lib/tmpfiles.d/named.conf
d /run/named 0755 named named -

if that's missing "/etc/tmpfiles.d" is the location where you place 
manual stuff - /usr/lib is apckage area, /etc is admin-area

___
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: underscore in A or PTR records

[Reindl Harald]

Am 17.02.21 um 10:41 schrieb ONRUBIA AVILES Carlos (CCS/MST):

Matus,

What do you mean with " absolutely no, but since underscore is not valid in hostname 
as per rfc1123, I don't recomment you to use it in hostnamed" ?


_ is not allowed in hostnames


I tried with the following configuration in zone " dekil.nl " and bind do not 
accept it:


hello_mail2.dekil.nl. 3600IN  A   81.246.48.28

I have the following message error:

Feb 17 10:40:41 dnszone904 named[1633]: /etc/bind/zones/master/dekil.nl:19: 
hello_mail2.dekil.nl: bad owner name (check-names)
Feb 17 10:40:41 dnszone904 named[1633]: zone dekil.nl/IN: loading from master 
file /etc/bind/zones/master/dekil.nl failed: bad owner name (check-names)
Feb 17 10:40:41 dnszone904 named[1633]: zone dekil.nl/IN: not loaded due to 
errors


_ is not allowed in hostnames


https://tools.ietf.org/html/rfc1123
2.1  Host Names and Numbers

The syntax of a legal Internet host name was specified in RFC-952 
[DNS:4].  One aspect of host name syntax is hereby changed: the 
restriction on the first character is relaxed to allow either a letter 
or a digit.  Host software MUST support this more liberal syntax.


1. A "name" (Net, Host, Gateway, or Domain name) is a text string up to 
24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign 
(-), and period (.)

___
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: underscore in A or PTR records

[Reindl Harald]

Am 17.02.21 um 09:50 schrieb ONRUBIA AVILES Carlos (CCS/MST):

Hello,

Thanks for these clarifications.
The issue we face is that a telecom provider ask us to implement a PTR record with a name 
like "example_try.net"


point out to that provider it's a bad idea and that they should know that!

i can't count how often developers wasted hours because they used a _ in 
the hostname and MSIE had strange cookie behavior with the illegal 
hostname at the final tests after development web applications on Firefox

___
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: Checking if my DNS server are active

[Reindl Harald]

Am 12.02.21 um 15:21 schrieb The Doctor via bind-users:

Hello,

On of my machines in Running Centos 7 / CPanel.

It says my primary and secondary DNS are not active


intern or public nameservers?

 query-source address 192.168.81.1 port 53;

don't do that!

 listen-on {192.168.81.1; 127.0.0.1; };

looks like internal nameservers which have nothing to do with the 
nameservers responsible for your zones from the view of the world

___
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: Choosing A records based on hosts' load?

[Reindl Harald]

Am 18.01.21 um 10:04 schrieb Marek Kozlowski:

:-)

On 1/18/21 9:59 AM, Reindl Harald wrote:

Am 18.01.21 um 09:49 schrieb Marek Kozlowski:
I believe that such a solution (read to install) should exist. 
Unfortunately I don't know the magic keywords to find it:


I have a group of hosts with different IPs offering the same 
services. I'm able to install some agents on them for monitoring 
their network/cpu/number of users/whatever utilization. I'm wondering 
if there is an option for BIND9 to obtain those load parameters on a 
regular basis (let's say: every 10 minutes) and when queried for the 
A record return ONLY one IP address - the one of the server with the 
lowest utilization?


It can be implemented on those servers but in the solution I'm asking 
about the key point is that the BIND server takes the decision.


this can't work - only a minority of clients is asking your nameserver 
directly, most talk to caches


you try to solve the problem on the wrong side
you need a loadbalancer in front of the cluster


The problem is: I'm supervising the BIND. I'm NOT supervising the other 
servers. Their admins requested such a solution. Personally I agree with 
your opinion but... The question is: is there such a ready solution as I 
described?


i doubt that someone wrote arelieable solution, it's just not the job of 
dns and even if such a solution exists it's not well tested/maintained 
by lack of consumers


reject the request with "i don't solve issues outside my responsibility 
ignoring best practices"


that starts starts with agents (network/cpu/number of users/whatever 
utilization) where you suddenly mix responsibilities


what does it mean for sour nameservers if that agents itself are 
overloaded? does it reduce the quality or even bring down nameservices?


solve problems where they exist instead compromise additional services - 
bind itself can't do it anyways, it would be whatever software which 
decides to update the dns-zone runniong outside of named

___
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: Choosing A records based on hosts' load?

[Reindl Harald]

Am 18.01.21 um 09:49 schrieb Marek Kozlowski:

:-)

I believe that such a solution (read to install) should exist. 
Unfortunately I don't know the magic keywords to find it:


I have a group of hosts with different IPs offering the same services. 
I'm able to install some agents on them for monitoring their 
network/cpu/number of users/whatever utilization. I'm wondering if there 
is an option for BIND9 to obtain those load parameters on a regular 
basis (let's say: every 10 minutes) and when queried for the A record 
return ONLY one IP address - the one of the server with the lowest 
utilization?


It can be implemented on those servers but in the solution I'm asking 
about the key point is that the BIND server takes the decision.


this can't work - only a minority of clients is asking your nameserver 
directly, most talk to caches


you try to solve the problem on the wrong side
you need a loadbalancer in front of the cluster
___
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: Serial number question..

[Reindl Harald]

Am 17.12.20 um 19:56 schrieb Bruce Johnson:

Someone updated out name server and messed up the serial number on the primary; 
as a result our secondaries are not updating properly.

Primary:

bruces-Mac-Mini:~ johnson$ dig @elixir.pharmacy.arizona.edu -t SOA +noall 
+answer pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1297117089 3600 120 1209600 86400


Secondaries:

bruces-Mac-Mini:~ johnson$ dig @dhbns1.pharmacy.arizona.edu -t SOA +noall 
+answer pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400
bruces-Mac-Mini:~ johnson$ dig @ns-remote.arizona.edu -t SOA +noall +answer 
pharmacy.arizona.edu
pharmacy.arizona.edu.   86404   IN  SOA elixir.pharmacy.arizona.edu. 
wunz.elixir.pharmacy.arizona.edu. 1762233707 3600 120 1209600 86400

Is the fix here just setting the serial number on the primary to 1762233708 ?

The various things online I’ve found are all based on “you accidentally set the 
primary more than 2^32 ahead” so you have to do a bunch of modulo arithmetic...


just set it *higher* on the master and you are done
___
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 Zone Files Are Read

[Reindl Harald]

Am 16.12.20 um 19:18 schrieb Tim Daneliuk:

On 12/16/20 11:36 AM, Reindl Harald wrote:

where did i give the advice "don't fail"?
please read my repsonse again!

* the zone fails on the master
* the zone is still available on the slaves
* so the error isn't fatal
* but you recognize your mistake

what happens when the error is in the line of the MX record and named would say 
"well, it's only one line, we still have the zone but no longer an MX"?

it would lead to a *fatal error* for the behavior of the whole zone, even if 
*all* or your nameservers go down it would be better because every delivering 
MTA would just queue the messages in case of a SERVFAIL

without the MX the would go to the A record of the zone which is in most cases 
simply the wrong destination


I agree that in a master-slave topology, your argument makes sense


sorry, i can't think of any network with only one nameserver given that 
DNS is one of the most important services



I this case, the server was a singleton responsible for a small virtual
private network within a much larger one. So. when the server failed to start,
the client had NO DNS for that subnet.
don't get me wrong but that's how one learns the hard way build basic 
redundancy for services he cares and if one don't care it's no problem 
if they fail


you have 3 options:

1: master/slave as recommended always
2: verify zones file before write them
3: fix software which generates broken zones

normally you chose all 3 in the sense of "and" instead of "or"
___
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 Zone Files Are Read

[Reindl Harald]

Am 16.12.20 um 18:26 schrieb Gregory Sloop:

This isn't, IMO, very useful as a response to the OP.


let that decide the OP


To sum up the response; "It's better to never fail!"

Yes, that seems pretty obvious. It *would* be better to never fail. Way, 
way better.

But the big problem in life is; We're always failing! Dammit!

So, learning how to gracefully fail, and understanding what happens and 
why, when something fails, is pretty important to achieve the outcome 
of; "Not failing quite so catastrophically."


loading a invalid zoen file is far away from "fail geraceful"! if a 
comozter don't understand the input fully it's not supposed to guess


So, while I don't have helpful knowledge to impart to the OP, I think I 
can say that giving the advice of "don't fail" doesn't seem very helpful.


where did i give the advice "don't fail"?
please read my repsonse again!

* the zone fails on the master
* the zone is still available on the slaves
* so the error isn't fatal
* but you recognize your mistake

what happens when the error is in the line of the MX record and named 
would say "well, it's only one line, we still have the zone but no 
longer an MX"?


it would lead to a *fatal error* for the behavior of the whole zone, 
even if *all* or your nameservers go down it would be better because 
every delivering MTA would just queue the messages in case of a SERVFAIL


without the MX the would go to the A record of the zone which is in most 
cases simply the wrong destination



*RH> Am 16.12.20 um 17:37 schrieb Tim Daneliuk:

I ran into a situation yesterday which got me pondering something about bind.



In this case, a single line in a zone file was bad.  The devops automation
had inserted a space in the hostname field of a PTR record.



What was interesting was that - at startup - bind absolutely refused
to load the zone file at all.  I would have expected it to complain
about the bad record and ignore it, but load the rest of the
good records.



Can someone please explain the rationale or logic for this?  Not complaining,
just trying to understand for future reference.


RH> it's better not load a invalid zone on a single nameserver at all as you
RH> are supposed to have at least two nameservers and the second one won't
RH> get the failure via master/slave replication

RH> if it has an error something is wrong
RH> if the last version had no error that version is good

RH> for the world *everything* still is good as long there is one slave -
RH> subtle errors can lead to completly unexpected behavior

___
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 Zone Files Are Read

[Reindl Harald]

Am 16.12.20 um 17:37 schrieb Tim Daneliuk:

I ran into a situation yesterday which got me pondering something about bind.

In this case, a single line in a zone file was bad.  The devops automation
had inserted a space in the hostname field of a PTR record.

What was interesting was that - at startup - bind absolutely refused
to load the zone file at all.  I would have expected it to complain
about the bad record and ignore it, but load the rest of the
good records.

Can someone please explain the rationale or logic for this?  Not complaining,
just trying to understand for future reference.


it's better not load a invalid zone on a single nameserver at all as you 
are supposed to have at least two nameservers and the second one won't 
get the failure via master/slave replication


if it has an error something is wrong
if the last version had no error that version is good

for the world *everything* still is good as long there is one slave - 
subtle errors can lead to completly unexpected behavior

___
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: RRL outcome on legitimate traffic...

[Reindl Harald]

Am 01.12.20 um 17:15 schrieb Karl Pielorz:
--On 1 December 2020 at 08:24:50 -0600 Lyle Giese  
wrote:



You need to look at the reply named sends when it trips and starts
limiting UDP traffic source from a given IP address.  It tells the
requestor to try again using TCP instead of UDP.

So if the requestor is a legit dns server, it will retry using TCP and
still get a valid answer.

Named does not blindly just drop traffic.


Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to 
stop sending responses)


irrelevant in context of TCP where forged source with the IP of the 
victim don't survive a handshake


the point of dns amplification over UDP is that the response of ANY 
queries is dramatically larger then the inbound package and no handshake 
is needed

___
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 stats - denied queries?

[Reindl Harald]

Am 30.11.20 um 20:01 schrieb Marc Roos

You assume incorrectly that every such log entry is from spoofed
traffic.


every relevant one, yes


This is about correct logging. Even if it is spoofed, logging the
correct spoofed address is better than logging a range (that include
ip's that are maybe not even participating)


there is nothing like "not even participating" in a /24 in case of 
reflection



There is only, but only one advantage I can think of, and that is
grouping to one log entry.


no, it logs what it does: responses to that /24 are rate-limited because 
otherwise you won't be able to reduce the impact


you still refuse to understand wo is attacker and who is victim! *you 
are* the attacker sending responses larger then the request to the 
forged sources


you are *not* target, you are part of the attack und you have no way to 
do anything against that on a UDP protocol except rate-limit your 
responses because you have no way to find out the real source



-Original Message-
Subject: Re: Bind stats - denied queries?

the source of dns amplification is *always* spoofed because it's by
design the IP of the victim and not the offender

the goal of dns amplification is to flood the connection of the victim
until no regular traffic is possible

the same /24 is sharing the same line and so it doesn't make sense in
that context talk about single ip's at all

it also doesn't make sense to write abuse reports for such things
because additionally to the technical packet flood you also flood human
ressources with nosense there

they aren't the offender, they can't do anything about your issue
because the are *the victim*

you are one of thousands or even millions of hosts the attacker is
trying to get responses from to the victim

please try to understand
https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
and RRL is only useful for that type of attack, everything else don't
matter for a DNS server and more important you can't distinct it anyways

Am 30.11.20 um 18:23 schrieb Marc Roos:

Regardless if the source is spoofed or not, one should log it.
Especially with this amazon abuse cloud, how can you report abuse,
they want to have an ip address to be able to investigate if something



originated from their network.

If you log 0/24 you might as well log no range at all.

Am 30.11.20 um 11:12 schrieb Marc Roos:

Are newer version of bind still logging like this

Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses
to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses
to
3.9.41.0/24

I already reported, that it is not to smart to log 3.9.41.0/24,
better



could be logged 3.9.41.100/24 so you know the offending ip


there is nothing like an "offending ip" in case of dns-amplification
which is usually what happens in context of RRL

it's the forged destination of the attack you see and nothing else

___
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 stats - denied queries?

[Reindl Harald]

Am 30.11.20 um 11:12 schrieb Marc Roos:

Are newer version of bind still logging like this

Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
3.9.41.0/24

I already reported, that it is not to smart to log 3.9.41.0/24, better
could be logged 3.9.41.100/24 so you know the offending ip


there is nothing like an "offending ip" in case of dns-amplification 
which is usually what happens in context of RRL


it's the forged destination of the attack you see and nothing else
___
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 stats - denied queries?

[Reindl Harald]

the source of dns amplification is *always* spoofed because it's by 
design the IP of the victim and not the offender


the goal of dns amplification is to flood the connection of the victim 
until no regular traffic is possible


the same /24 is sharing the same line and so it doesn't make sense in 
that context talk about single ip's at all


it also doesn't make sense to write abuse reports for such things 
because additionally to the technical packet flood you also flood human 
ressources with nosense there


they aren't the offender, they can't do anything about your issue 
because the are *the victim*


you are one of thousands or even millions of hosts the attacker is 
trying to get responses from to the victim


please try to understand 
https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/ 
and RRL is only useful for that type of attack, everything else don't 
matter for a DNS server and more important you can't distinct it anyways


Am 30.11.20 um 18:23 schrieb Marc Roos:

Regardless if the source is spoofed or not, one should log it.
Especially with this amazon abuse cloud, how can you report abuse, they
want to have an ip address to be able to investigate if something
originated from their network.

If you log 0/24 you might as well log no range at all.

Am 30.11.20 um 11:12 schrieb Marc Roos:

Are newer version of bind still logging like this

Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
3.9.41.0/24
Nov 30 10:10:02 ns0 named[1303]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
35.177.154.0/24
Nov 30 10:10:02 ns2 named[1241]: rate-limit: info: limit  responses to
3.9.41.0/24

I already reported, that it is not to smart to log 3.9.41.0/24, better



could be logged 3.9.41.100/24 so you know the offending ip


there is nothing like an "offending ip" in case of dns-amplification
which is usually what happens in context of RRL

it's the forged destination of the attack you see and nothing else


___
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: Two copies of recent posts

[Reindl Harald]

Am 26.11.20 um 03:01 schrieb Mark Andrews:

The message that generated this thread had the following:

To: upendra.gan...@gmail.com
Cc: bind-users , BIND Users 

Note the 2 different addresses for bind-users.  Both where delivered to 
lists.isc.org in a single SMTP
transaction as you noted (ESMTP id 026B967ED73) because the MTA worked out they 
both needed to be delivered to the same server.  They where then sent through 2 
different instances mailman.  One for bind-users@lists.isc.org
and one for bind-us...@isc.org and re-injected (ESMTP id B380C67F367 and ESMTP 
id E414B67F36E).


why is it that both exists when the system isn't capable of *basic* 
"suppress_duplicates = yes"?


that's also annoying in context of sieve / mua filters


On 26 Nov 2020, at 12:35, Paul Kosinski via bind-users 
 wrote:

Yes indeed: I sent the last email (and this one) to bind-users and CC-ed to 
you. That explains why there are two different ESMTP IDs.

The question is, have you, like I have, received two copies of any emails (from 
lists.isc.org) where there *identical* ESMTP IDs in their associated sequences of 
"Received:" headers. This would indicate that the duplication was caused by an 
intermediate MTA. (The one I previously indicated was mx.pao1.isc.org, which is the one 
and only MX for lists.isc.org.)

On Tue, 24 Nov 2020 22:46:06 -0500
Jim Popovitch via bind-users  wrote:


On Tue, 2020-11-24 at 22:22 -0500, Paul Kosinski wrote:

My reading of the headers (below) does *not* suggest "Reply All".

Rather, they show that mx.pao1.isc.org sent/forwarded the email once,
and it was received by lists.isc.org once with ESMTP ID 026B967ED73.
But then lists.isc.org resent/forwarded it more than once, as it was
received a few seconds later by lists.isc.org (again!) with two
*different* ESMTP IDs: B380C67F367 and E414B67F36E.

This suggests to me that lists.isc.org is being a bit too diligent in
delivering its email.



I just received 2 copies of your post, with 2 different ESMTP IDs...
because you sent it to 2 different recipients.  That same thing would
happen if you sent it to bind-users@lists.isc.org and
bind-users@lists.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

Re: Two copies of recent posts

[Reindl Harald]

Am 25.11.20 um 04:46 schrieb Jim Popovitch via bind-users:

On Tue, 2020-11-24 at 22:22 -0500, Paul Kosinski wrote:

My reading of the headers (below) does *not* suggest "Reply All".

Rather, they show that mx.pao1.isc.org sent/forwarded the email once,
and it was received by lists.isc.org once with ESMTP ID 026B967ED73.
But then lists.isc.org resent/forwarded it more than once, as it was
received a few seconds later by lists.isc.org (again!) with two
*different* ESMTP IDs: B380C67F367 and E414B67F36E.

This suggests to me that lists.isc.org is being a bit too diligent in
delivering its email.



I just received 2 copies of your post, with 2 different ESMTP IDs...
because you sent it to 2 different recipients.  That same thing would
happen if you sent it to bind-users@lists.isc.org and
bind-users@lists.isc.org.


are list servers still that bad?
our lmtpd kills even real "reply-all" duplicates

the point is that the message in question was *not* a reply-all. i got 
one identical too in a thread i never where active and simply deleted it 
long before that subject appeared

___
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: Two copies of recent posts

[Reindl Harald]

Am 23.11.20 um 04:58 schrieb Jim Popovitch via bind-users:

On Sun, 2020-11-22 at 21:56 -0500, Paul Kosinski via bind-users wrote:

I've been getting two identical copies of recent posts to this list...


Me too, but it's because of people hitting reply-all thinking that they
are replying to the list and the poster.  


why don't you just read what you respond to when "Upon examination of 
the headers of the two copies, it looks like ISC's list-servers are 
doing the duplication" including the headers where part of the original 
post?


typically that happens when a connection was interruptred (no matter 
smtp or local lmtp) in the moment it would have said "OK got it" from 
the destination hop and so the client tries again


below the headers of the OP

P.S.: this is a reply-all by intention because it takes ages on this 
list when you are moderated because you answered to a personmal attack 
instead suck it


-

Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id B72843283403
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id 7B3C3607948F
for ; Sun, 22 Nov 2020 18:48:18 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id B380C67F367;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)

-

Received: from iment0.iment.com (localhost [127.0.0.1])
by imes.imemail.iment.com (Postfix) with ESMTP id EDA193283403
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (lists.isc.org [149.20.1.60])
by iment0.iment.com (Postfix) with ESMTP id B3A43607948F
for ; Sun, 22 Nov 2020 18:48:27 -0500 (EST)
Received: from lists.isc.org (localhost [127.0.0.1])
by lists.isc.org (Postfix) with ESMTP id E414B67F36E;
Sun, 22 Nov 2020 23:47:27 + (UTC)
X-Original-To: bind-users@lists.isc.org
Delivered-To: bind-users@lists.isc.org
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53])
 by lists.isc.org (Postfix) with ESMTP id 026B967ED73;
 Sun, 22 Nov 2020 23:47:23 + (UTC)

--
___
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: [External] Re: How can I launch a private Internet DNS server?

[Reindl Harald]

Am 08.11.20 um 14:44 schrieb Timothe Litt:


I'm amazed that this thread has persisted for so long on this list of 
knowledgeable people




me too, i would understand that on the spamassassin list but not here 
and what i *really* don't understand is jumping into the thread with "I 
just wanted to comment that there is no requirement to run a secondary 
DNS server"


even if it would not be a requirement (but it is) it's common sense not 
to contradict best practices everyone running critical services is following


there are enough beginners which don't follow best practices anyways, no 
need to encourage them


RFC1034 , one of the two 
foundational RFCs for the DNS:


P.18 in section 4.1 (NAME SERVERS => Introduction):

A given zone will be available from several name servers to insure its
availability in spite of host or communication link failure.  By
administrative fiat, we require every zone to be available on at least
two servers, and many zones have more redundancy than that.

In case the font is too small, the key phrase is:

"we require every zone to be available on at least two servers"

That's "REQUIRE" at least TWO SERVERS

i heard of registries whcih require even 3 and when they say they 
require it means you have them or you can't register a domain, no RFC 
needed to begin with


https://tools.ietf.org/html/rfc1537 
 documents common 
misconfigurations - that is, cases of non-conformance to the RFCs that 
the author encountered circa 1993.  It was superseded in 1993 by RFC 
1912 , where section 2.8 starts 
with "You are required to have at least two nameservers for every 
domain".  Neither document supersedes RFC1034; rather they attempt to 
help with interpreting it.


https://www.iana.org/help/nameserver-requirements 
 consolidates 
information from several RFCs, since the DNS has evolved over time.  
It is not an RFC, but a convenient summary. It primarily documents the 
tests performed by IANA when it processes a delegation change to the 
root, .INT, and .ARPA zones.  These tests validate conformance to the 
RFCs.  As the introduction says, "These tests do not measure against 
best practices or comprehensively measure protocol conformance. They 
are a practical set of baseline requirements that catch common 
misconfiguration errors that impact stable operations of the DNS."


Bottom line: two servers per zone are required by the DNS 
architecture.  It's not folklore.  It's not optional.



yes

It is true that the DNS is robust enough to function with a number of 
misconfigurations (including just one server for a zone, since in 
practice this is almost indistinguishable from transient conditions.)


Nonetheless, the goal of the DNS architecture (and most of its 
operators) is to have a stable and robust name service. 
Misconfigurations, such as those documented in rfc1527, make the DNS 
unstable and fragile.  The architecture tends to contain the effects 
of many misconfigurations, but that doesn't make them wise.


As I noted earlier: "DNS appears deceptively simple at first blush.  
Setting up a serviceable infrastructure requires an investment of 
thought and on-going maintenance.  You will not be happy if you skimp 
on that investment, since broken DNS is externally visible - and 
frequently catastrophic."


I'll finish with a 1987 quote from Leslie Lamport on distributed 
systems, which the DNS most certainly is:


"A distributed system is one in which the failure of a computer you 
didn't even know existed can render your own computer unusable."


Can the quibbling stop now?



thank you
___
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 can I launch a private Internet DNS server?

[Reindl Harald]

first: there *is* a requirement of a secondary nameserver
https://www.iana.org/help/nameserver-requirements

Am 07.11.20 um 14:21 schrieb alcol alcol:
you can't run a sec. srv. from your own. You need some action from 
ADMIN-C or TECH-C


yeah, someone needs to tell the registry the nameservers that's it, 
nobody expect something work out of the blue



otherwise it will not work at all x RFC SOA refresh 24H


no idea what that means, but it makes no sense


In all case a sec. srv. on the same net


no *not* on the same net

thelounge.net.  86400   IN  NS  ns1.thelounge.net.
thelounge.net.  86400   IN  NS  ns2.thelounge.net.

ns1 = 85.124.176.242
ns2 = 91.118.73.16

in fact ns2 is the master, ns1 is the salve for historical reasons, both 
hosting some hundret domains, both operated at my own for 12 years now


in fact both are even on the same *redundant* cluster
and the whole backends and automation is homegrown



*From:* bind-users  on behalf of Kevin 
A. McGrail 

I just wanted to comment that there is no "requirement" to run a
secondary DNS server.  It's certainly best practice and should be
considered.  However, the goal of having two DNS servers is to promote
redundancy if DNS fails but other services you need have not

this is *not* true at all

https://www.iana.org/help/nameserver-requirements

Requirements for Name Servers

These tests are performed for the set of NS records and any associated 
IP addresses for those name servers. For each individual hostname, tests 
are performed against each IP address and protocol pair.

Minimum number of name servers

There must be at least two NS records listed in a delegation, and the 
hosts must not resolve to the same IP address.

___
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 can I launch a private Internet DNS server?

[Reindl Harald]

Am 05.11.20 um 20:04 schrieb Michael De Roover:

On Thu, 2020-11-05 at 11:27 -0600, Chuck Aurora wrote:

On 2020-11-05 07:36, Bob Harold wrote:

You appear to have confused 'secondary' authoritative servers with
a
second 'resolver'.
Authoritative servers - listed in the NS records - are used by
other
DNS servers, not by end users, and they will get used equally with
the
slaves, if your parent zone has the right NS records also.  Those
are
good to outsource the secondaries.


It should perhaps be pointed out here that the DNS protocol has no
means to distinguish among different types of NS host.  (Yes, there
is
the SOA MNAME, but that is not used by resolvers.)  One NS is as good
as any other NS.


These (SOA and behavior for resolvers) probably describe where I got
confused, thanks for the explanations!


for many years our SOA was the slave :-)
___
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: [External] Re: How can I launch a private Internet DNS server?

[Reindl Harald]

Am 07.11.20 um 15:36 schrieb Kevin A. McGrail:

On 11/7/2020 9:04 AM, Reindl Harald wrote:

first: there *is* a requirement of a secondary nameserver
https://www.iana.org/help/nameserver-requirements


Does that requirement apply to the use-case? Based on the first
sentence, "These are the technicals tests we perform for delegation
changes in the zones we manage (root zone, .INT, .ARPA).", I would guess
it's not applicable.


"Technical requirements for authoritative name servers" includes that 
usecase too no mattaer wthat "technical tests are applied"


-

https://tools.ietf.org/html/rfc1537
Common DNS Data File Configuration Errors

6. Missing secondary servers

> It is required that there be a least 2 nameservers
> for a domain.

-

that above is common knowledge virtually forever and the difference of 
"must" and "should" in IETF wordings is also very clear

___
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 can I launch a private Internet DNS server?

[Reindl Harald]

Am 06.11.20 um 13:25 schrieb Tom J. Marcoen:

First of all, sorry that I cannot reply within the thread, I was not
yet a member of the mailing list when those emails were sent.


On Thu 15/Oct/2020 18:57:16 +0200 Jason Long via bind-users wrote:


Excuse me, I just have one server for DNS and that tutorial is about secondary
DNS server too.


Just skip the chapter about the secondary.  You're better off buying secondary
DNS services externally.  A good secondary offloads your server noticeably, and
keeps the domain alive in case of temporary failures.

Best
Ale


Is it not a requirement to have at least two authoritative name
servers? I believe all TLDs require at least two name servers but I
must be mistaking as no one pointed this out yet.


yes, and "You're better off buying secondary DNS services externally" 
don't say anything else


the point is that the two nameservers are required to be located on two 
different ip-ranges anyways to minimize the risk that both going down at 
the same time

___
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 can I launch a private Internet DNS server?

[Reindl Harald]

Am 05.11.20 um 12:59 schrieb Michael De Roover:

On Thu, 2020-11-05 at 11:31 +0100, Alessandro Vesely wrote:

A good secondary offloads your server
noticeably, and
keeps the domain alive in case of temporary failures.


AFAIK, authoritative slave servers are only used when the master is
confirmed to be down


impossible because nobody can know from the outside which is slave and 
which is master


in doubt none of the public reachable is master at all, both slaves and 
pull from a internal master not public reachable

___
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: Domain Control Validation

[Reindl Harald]

it makes no sense what you ask for
why would you point with your whole webserver to geocerts?

a CNAME is what it is - and it can't exist with other revord types
so you can't have a CNAME for www.example.com and at the same time a 
A-record or MX


Am 30.10.20 um 18:11 schrieb Khuu, Linh Contractor via bind-users:


/Hello,/

//

/I have a question. Does anyone know if CNAME can be added for Domain 
Control Validation. For example,/


//

/www.example.com  3600 IN CNAME 
/_8DA14D435F7042B71E212832EBFFD76B.www.geocerts.net//


//

/Can this record be done in BIND?/

//

/Thanks,/

/Linh Khuu
Network Security Specialist
Northrop Grumman IS | Civil Systems Division (CSD)/

/Social Security Administration
Office: 410-965-0746
Pager: 443-847-7551
Email: linh.k...@ssa.gov /

/Team’s email: dnsfwad...@ssa.gov  
(#DNSFWADMIN)/




___
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 can I launch a private Internet DNS server?

[Reindl Harald]

Am 16.10.20 um 11:34 schrieb Michael De Roover:

Interesting article, thanks for sharing this! I'm slightly confused
about some things in it though. Does this mean that any traffic will be
put on the connection tracker and be treated as stateful unless we use
CT --notrack, or can the kernel make a heuristic based on what's in the
iptables rule (i.e. if it only covers a port or a network range, it
must be stateless)


conntrack is *always* part of the game unless you set "notrck" in the 
raw-table which is the only stateless one


raw -> mangle -> filter

at the point conntrack steps in the filter-table with your normal rules 
is not part of the game at all


https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png
___
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: CNAME restrictions

[Reindl Harald]

Am 04.08.20 um 19:34 schrieb Matus UHLAR - fantomas:
> On 04.08.20 17:29, Leroy Tennison wrote:
>> I have a situation where, due to the system's location (IP subnet),
>> its DNS
>> name is ..datavoiceint.com.  We have a
>> certificate for *.datavoiceint.com which we prefer to use
> 
> wildcard in certificates only covers one level of subdomains, so
> *.datavoiceint.com will cover .datavoiceint.com but not
> anything under it.
> 
> you will have to strip the   part or get other certificate

proper wildcard certifiocates are looking like this

X509v3 Subject Alternative Name: DNS:*.buildserver.thelounge.net
DNS:*.thelounge.net
DNS:thelounge.net

in other words: you have "*.domain.tld" and "domain.tld" in your SAN
___
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: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Reindl Harald]

Am 23.07.20 um 06:28 schrieb Ted Mittelstaedt:
> But truthfully you are proving my point.  The simple fact is that bind
> will compile WITHOUT using a FreeBSD port.  Linux is 10 times worse
> because they aren't even including the c compiler or development tools
> anymore.  

that's nonsense and there is no reason to have them installed by
default, that's wat a package manger is for

> But many "systemadmins" out there think they are Unix admins
> yet are afraid to compile programs. 

and many real admins know that a compiler don#t belong to a production
system and is only needed on the buildserver building packages

if you type "make install" you aere doping it 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

Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Reindl Harald]

Am 20.07.20 um 19:45 schrieb Ted Mittelstaedt:
> On 7/17/2020 11:35 AM, John W. Blue wrote:
>> Speaking about things to be annoyed over ..
>>
>> I am still ticked that FreeBSD dropped BIND from the distribution for
>> something called unwinding or whatever it is.
>>
> 
> I'm not happy that happened either but the simple fact is that if BIND
> would quit dropping support so fast for it's older versions that never
> would have happened.  The fundamental problem was that BIND dropped
> support for it's older versions before the distros dropped support for
> their distros.  This is happening with a lot of other software packages.

how has this anything to do with the fact that there is one named in
whatever version in your distribution?

it has also nothing to do with bind9 versus bind

it's a debian hobby to make such things like apache2 or bind9 where the
service is just httpd and named, no number and a completly different
name as debian is using

> When FreeBSD was used mostly for servers it wasn't a problem.  But more
> and more people are using it for desktop use where they want to
> basically install it and forget about it, never run patches, never give
> a fig about security.  Simpler programs like Unbound have less code
> and so less things to go wrong, need less patches, and are easier to
> support for a longer period of time so they get supported for a longer
> period of time.  Also, Unbound's main purpose in life is as a caching
> dns program.  Nobody who runs a server on FreeBSD uses Unbound.

when i use a pure cache i run unbound and don't know why i wouldn't do
so on whatever OS which can run 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: issue of Amplification attack

[Reindl Harald]

Am 12.07.20 um 06:23 schrieb ShubhamGoyal:
> Dear sir,
> Thank you  for give me answer for my previous
> question,  Sir now we are suffer from amplification attack so is there
> any method in bind to stop DNS Amplification attack.
> I am thinking to stop or drop ANY type queries from our DNS Recursive
> resolver , so please tell me how can we drop or stop ANY type queries
> from bind.

there where a recent discussion you missed in the past few days, our
config for years:

options {
 ...
 minimal-responses  yes;
 minimal-anyyes;
 rate-limit
 {
  responses-per-second 10;
  window   5;
 };
}

___
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: [DoD Source -- ssshhhh Top Secret] Re: Dumb Question is an A or AAAA record required?

[Reindl Harald]

Am 09.07.20 um 17:20 schrieb Michael De Roover:
> On 7/9/20 5:03 PM, Reindl Harald wrote:
>> but it still has nothing to do with your domain by definition, the PTR
>> could be anything
> Of course it can be, they're completely separate name spaces. However
> would it make any sense in practice to point it somewhere else entirely?
> You'd probably be better off not setting it at all then. I'd argue that
> they're meant to match each other.
>> but how does that change anything in the simple fact that "Would the
>> lack of A records affect pointer records? Seems like it would" given
>> that the PTR zone is a dns zone like anything else
>> while it's smart (at least when you want to send mails) that your IP has
>> a sane PTR and that the name maps back to the IP the dns system couldn't
>> care less
> My thoughts exactly. They can technically be different and the DNS
> itself indeed couldn't care less (but applications checking for that
> might).. but would it make sense to? I mean yeah I suppose that they can
> exist without the other. Not uncommon for A records to be without PTR
> records, and I guess that a PTR record without an A record could work
> too..? But again, aside from the theoretical possibility, why would you
> want to set your PTR records to not match at least one of your A records?

they question was "Would the lack of A records affect pointer records?"
an dthe answer is clearly *no*

my first response was "while it's smart (at least when you want to send
mails) that your IP has a sane PTR and that the name maps back"

so it's not a matter of "would it make any sense in practice" and "why
would you want to" because nobody want's and that was not the question

case closed, period


___
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