Re: Problem with a certain domain

[Paul Kosinski via bind-users]

Could you send the email from another account (which doesn't use your DNS 
server)? It's not too hard to set up a free account with services like Outlook, 
Yahoo or (if desperate) Gmail.


On Mon, 03 Jun 2024 18:46:40 +0200
Thomas Barth via bind-users  wrote:

> Hello,
> 
> I cannot send them an email to inform about a dns problem. The mail gets 
> stuck in the queue.
> 
> postqueue -p
> (Host or domain name not found. Name service error for name=mx.renr.es 
> type=A: Host not found, try again)
>   r...@mallorcazeitung.es
> 
> 
> Bind reports a communication error.
> 
> dig mx.renr.es
> ;; communications error to 127.0.0.1#53: timed out
> 
> I could enable the bind logging:
> 
> 03-Jun-2024 18:34:22.681 client @0x7f014c88ed68 127.0.0.1#54496 
> (mallorcazeitung.es): query: mallorcazeitung.es IN MX +E(0)K (127.0.0.1)
> 03-Jun-2024 18:34:36.098 client @0x7f014ef48168 127.0.0.1#59706 
> (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1)
> 03-Jun-2024 18:34:41.106 client @0x7f014dd71768 127.0.0.1#56423 
> (mx.renr.es): query: mx.renr.es IN A +E(0)K (127.0.0.1)
> 
> Should I perhaps ask the mail user to unsubscribe from this website due 
> to troubles of bad configuration?
-- 
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: consolidating in-addr.arpa data

[Paul Kosinski via bind-users]

On Sat, 16 Sep 2023 10:22:26 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> ...
>I'd be surprised if the OP couldn't manage with 2^20 IPs in a segment -
> but then I guess he does work in the .gov domain.
   ^^^
  
The OP's contact email is "@alaska.gov".  Since the population of Alaska is 
only about 3/4 million (well below 2^20), I can't imagine that alaska.gov would 
possibly need more than one 10.0.0.0/8 IPv4 address per person in Alaska.  :-)
-- 
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: Controlling which interface named uses

[Paul Kosinski via bind-users]

On Sat, 10 Jun 2023 19:24:03 +0200
Ondřej Surý  wrote:

> You are over-complicating things. If unconfigured, named binds the outgoing 
> UDP to 0.0.0.0 (::0), which means the chosen IP address is picked by the 
> kernel. You need to configure priorities on your interfaces in the kernel - 
> ip route is your friend.
> 
> And for goddess’ sake, don’t do anything wild like proposed round robin 
> across default routes. That would be a living hell to debug.
> 
> Ondřej
> --
> Ondřej Surý — ISC (He/Him)




If you have some external interfaces you *don't* want named to use, but might 
want other outgoing traffic to use, you would need some "policy based routing", 
which can get complicated. In Linux, this is controlled by "ip rule" (not "ip 
route").
-- 
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: ,Re: caching does not seem to be working for internal view

[Paul Kosinski via bind-users]

On Wed, 3 Aug 2022 15:10:39 -0400
Timothe Litt  wrote:

> Hmm.  Your resolv.conf says that it's written by NetworkManager.
> 
> What I suggested should have stopped it from updating resolv.conf.
> 
> See 
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking
> 
> After restarting the service, did you edit (or replace) resolv.conf to 
> remove the AT address?
> 
> If not, stop here & edit the file.
> 
> If so, perhaps some other manager is editing the file without replacing 
> the comment.
> 
> Check to see if resolv.conf is a symlink - some managers (e.g. 
> systemd-resolved) will do that.  Not sure when/if it found its way to 
> centos (I don't run it), but if it's there, systemctl stop & disable 
> it.  It would be running on 127.0.0.53:53, but it usually points 
> resolv.conf to itself.
> 
> The other managers that I know of aren't in redhat distributions.
> 
> You may need to use auditing to identify what is writing the file.
> 
> Timothe Litt
> ACM Distinguished Engineer


"Helpful" software such as NetworkManager has a habit of getting in the way of 
figuring out what is wrong with systems, especially networked ones. Since none 
of the 8 computers on my home LAN are ever used in different locations, I don't 
use NetworkManager (etc.): I don't see why such add-ons are useful unless the 
computer is used on multiple networks. But distros install a lot of stuff in an 
attempt to "simplify" Linux for newbies. (Even Windows, which now may have more 
millions of experienced users than brand new users, acts as if no one has ever 
used a computer before.)

-- 
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: Stopping ddos

[Paul Kosinski via bind-users]

On Wed, 3 Aug 2022 13:47:41 +0200
Victor Johansson via bind-users  wrote:

> Hey,
> 
> I just want to add that there is a better way to do this in iptables 
> with hashlimit. The normal rate limit in iptables is too crude.
> 
> Below is an example from the rate-limit-chain, to which you simply send 
> all port 53 traffic from the INPUT chain (make sure to exclude 
> 127.0.0.1/127.0.0.53 though :) ).
> 
> 
> -A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
> -A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT
> 
> -A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont rate-limit 
> localhost" -j RETURN
> -A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec 
> --hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name DNS-drop 
> --hashlimit-htable-expire 2000 -j ALLOW
> -A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
> -A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]" -j DROP
> 
> 
> //Victor
>


I was using iptables hashlimit for a while but stopped. It wasn't really 
solving my main problem, which was not so much "overloading" my BIND server as 
causing my log files to get filled with useless warnings about bad queries (or 
packets dropped).

It would be nice if BIND had way to record such error messages into a dumpable 
table with query, source IP and count.

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

DNSSEC adoption

[Paul Kosinski via bind-users]

There has been lots of discussion recently about DNSSEC issues, including 
whether it's desirable to sign internal zones. Independent of this most recent 
issue, a couple of weeks ago I did an informal survey, using DNSVIZ, of various 
TLDs. I found the following rather surprising results:

DNS-VIZ and "associates"

TLD Signed? Comments
--  --- 
dnsviz.net  yes with 1 warning (!)
iana.orgyes
icann.org   yes
isc.org yes
arin.netyes
ietf.orgyes with many warnings & errors

sandia.gov  yes with many warnings & 1 error
verisign.comyes
dns-oarc.netyes


Widely used and/or hi-tech

TLD Signed? Comments
--  --- 
google.com  no
gmail.com   no
youtube.com no
apple.com   no
microsoft.com   no
amazon.com  no
walmart.com no
outlook.com no
1e100.net   no
facebook.comno
twitter.com no
instagram.com   no
ibm.com no
mozilla.org no
wikipedia.org   no
redhat.com  no
w3c.org no
bankofamerica.com no

Does anybody have an explanation for why such big domains don't bother using 
DNSSEC?


P.S.  My opinion is that it probably worthwhile to sign internal zones, 
especially for organizations that are tempting targets and have many internal 
computers.

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

[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.
> 
> --
> Ondřej Surý — ISC (He/Him)

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.
-- 
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: Contents of bind-users digest...

[Paul Kosinski via bind-users]

On Tue, 6 Jul 2021 12:44:15 +
"MURTARI, JOHN"  wrote:

> Folks, let me add my desire for a quick download dig supporting DoH.  It 
> could really help with some testing, some ready stuff for Ubuntu 18/20,  
> Redhat/CentOS, could make a lot of people happy.   Maybe the libs included 
> and we set the LD_LIBRARY_PATH, or a 'static' link?
> 
> 
> It only takes a 'few minutes' more -- once you spend a few hours getting the 
> whole environment setup.  some don't build it all the time.
> 
> 
> I'll give ISC Five Stars on Google! 
> 
> 
> > On 6 Jul 2021, at 05:56, Eric Germann via bind-users 
> >  wrote:
> >
> > Has ISC given any thought to releasing dig as a separate source package?
> >
> > It?s good for testing DoH, but you need to build the entire bind package to 
> > get it.  It would be useful for support analysts without the overhead of 
> > compiling all of bind to get it  
> 
> Really, it a couple of extra megabytes of disk space and a couple of extra 
> minutes of compile
> time.  Dig is not a stand alone component.  It depends on libisc, libdns, 
> libisccfg, libirs, and
> libbind9.  Thats most of the libraries we build.  It makes no sense to have a 
> seperate source
> package for dig.


It isn't mainly the disk space and extra build time, it's the complexity. 
Somebody who only wants 'dig' would have to figure out how to isolate it from 
the result of the build. This would be especially troublesome after doing a 
"make install" (which I suspect is necessary to get the 'dig' executable 
properly set up) as there would be a whole lot of undesired stuff installed. 
Perhaps adding a "install-dig-only" option to the make file would be possible 
and not a lot of work?
___
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: Limit actions on control channel?

[Paul Kosinski via bind-users]

It ought to be possible to write a front-end to listen on the standard control 
channel and only forward (properly-keyed) 'status' requests to the "real" port 
that BIND listens to. 

>From looking at the RNDC exchange via Wireshark however, you'd have to adapt 
>some of BIND's code that does the encryption / key-signing of RNDC requests. 
>Still, for us users, that might be safer -- and more update resistant -- than 
>modifying BIND itself.


On Thu, 17 Jun 2021 11:48:36 -0800
John Thurston  wrote:

> I see I can define (using the 'controls' statement) a 'read-only' inet 
> channel. I suspect I could define a couple of channels on the same 
> address if I put them on different ports. Is there a way to define a 
> single 'read-write' channel, and then limit certain keys to read-only 
> access on it?
> 
> Here's the scenario:
> 
> I'd like to have a single control channel listening (on port 953, for 
> example). I'd like to say the key named "foo" can do lots of things, but 
> the key named "bar" can only submit a "status" message. This would let 
> our monitoring application ask for "status" without also letting it ask 
> for "reload" or "flushname".
> 
___
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

[Paul Kosinski via bind-users]

The site mxtoolbox.com has a suite of tools to check your DNS, email and Web 
servers from the outside. They're easy to use and might turn up something.


On Fri, 11 Jun 2021 09:10:32 -0700
techli...@phpcoderusa.com wrote:

> Hi,
> 
> The two domains I am working with on my SOHO home server are 1) 
> keiththewebguy.com  and 2) phpcodetest.com.
> 
> I setup keiththewebguy.com first and configured BIND9 for it on the same 
> server.
> 
> To try to troubleshoot I configured phpcodetest.com on the same box, 
> however it uses Zoneedit for DNS.  phpcodetest.com works as expected.
> 
> keiththewebguy.com does not work which uses my local BIND9.
> 
> I've tried everything I can think of.  I've tested the config files, run 
> dig, and verified port 53 is open.
> 
> I took the zone file for keiththewebguy.com from my VPS that runs Plesk 
> and previously hosted keiththewebguy.com.  I forgot to change the IP 
> addresses in the zone to my SOHO box and the website on my VPS was 
> accessible.  When I changed the IP addresses in the zone file to my SOHO 
> box the website quit working.
> 
> I assumed this meant I had an Apache issue and that is when I added 
> phpcodetest.com to test Apache.  I've checked apache several times...  
> And I just checked it again.
> 
> The server I am using is an old i3 laptop that I upgraded with a SSD.  
> It has 4GB RAM.
> 
> I am using Ubuntu 20.04lts and BIND9.
> 
> My connection is a commercial/business Internet connection provided by 
> my cable company for home office usage. This connection does not block 
> ports.
> 
> I followed the Ubuntu 20.04 server manual to configure BIND9 and I have 
> searched the Internet for more information.
> 
> If you need any additional information let me know.
> 
> Thank you for your help!!
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: No more support for windows

[Paul Kosinski via bind-users]

On Fri, 4 Jun 2021 13:58:40 -0700
Gregory Sloop  wrote:

> This feels a lot like responding to trolls, but I'll instead assume that 
> you're asking (or making a point) in good faith.
> 
> So, we'll stipulate that - you're actually interested in truth and knowledge.
> 
> So, it's easily compiled on Mac, Unix, FreeBSD, Linux, SunOS, RaspPi, etc.
> And it compiles on a huge range of hardware, CPU's etc.
> 
> I'd consider that highly portable.


I'd consider it moderately portable.

Among Open Source software, I'd consider the following highly portable: 
Firefox, Chromium, LibreOffice, Thunderbird, Claws-Mail, Scribus, Inkscape, 
Gimp, Krita, VLC, QT(!) and who knows how many others that run on Unix-like 
systems *and* on Windows.

And among closed source software, Chrome is obviously highly portable (by 
Google), and Acrobat Reader and Flash (RIP) are highly portable (by Adobe).

P.S. I am not a fan of Windows, but it is widespread, and many people even use 
it for Internet servers.
___
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: Syslog with BIND on CentOS

[Paul Kosinski via bind-users]

If you can have BIND log directly to a file, couldn't you use a FIFO 
(prwxrwxrwx) or Unix domain socket (srwxrwxrwx) and avoid the disk I/O by 
sending the log data directly to the forwarder? (E.g., Pulse Audio listens on a 
socket for audio data from an application, and sends it in real-time to the D/A 
hardware driver etc.)


On Fri, 21 May 2021 00:17:11 +0200
Anand Buddhdev  wrote:

> On 20/05/2021 23:34, John Thurston wrote:
> 
> Hi John,
> 
> > My subsequent read of the docs indicates that BIND on CentOS 7, while
> > being told it is sending to 'syslogd', is sending to 'journald' which is
> > handling all the messages and forwarding them on to 'syslogd'. I don't
> > want journald handling my thousands of messages per second from BIND. I
> > don't want that information in my journal logs. I just want it out in
> > the central syslog server.  
> 
> On CentOS, journald listens on the syslog socket, and intercepts ALL log
> messages, and logs them into files that are either in a memory-based
> tmpfs (the default), or to disk (if you configure journald that way).
> After intercepting the log message, and saving it to the journal,
> journald then forwards the message to rsyslog, which listens on a
> different socket.
> 
> > Is there some direct way to get the logging channel of BIND pointed
> > directly into the local syslogd? (which would then apply its forwarding
> > rules to get traffic to the central syslog server)  
> 
> As far as I know, BIND just calls the syslog functions, and so the log
> messages will go to whatever is listening on the default syslog socket
> (journald on CentOS). I don't think there's any way to point BIND to
> rsyslog's socket.
> 
> > I thought about trying to rip jourald out entirely, and quickly decided
> > that was a path to madness.  
> 
> That is indeed the path to madness. On systemd-based servers, you can't
> really do without journald.
> 
> > The only thing I can come up with is to activate dnstap, and have some
> > other process absorbing the data and spewing it directly to the central
> > syslogd.  
> 
> You could also log directly to files (bypassing syslog), and then have
> some process follow the files and send the logs to a remote server.
> 
> Regards,
> Anand

___
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: where are the testing docs ?

[Paul Kosinski via bind-users]

Actually, it's in keeping with the *original* definition of hacking!


On Sun, 9 May 2021 23:55:13 -0600
@lbutlr  wrote:

> On 06 May 2021, at 09:57, Dennis Clarke via bind-users 
>  wrote:
> > I do NOT trust a build result where I had to go hacking into all the
> > Makefiles just to get it to build. You install without doing testing?  
> 
> That's a very strange definition of "hacking". Setting makefile [preferences 
> and options is not in and way "hacking".
> 
___
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: Using RNDC to control remote access to my BIND server

[Paul Kosinski via bind-users]

A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP) IP 
address for my very simple domain. It worked, except that it totally messed up 
the organization of the zone file. Since the file only has 44 active lines 
(which are organized logically), I maintain it by hand. After nsupdate made the 
one line change, the zone file became unmaintainable.

Was this a bug in nsupdate, or does nobody try to understand their zone files.

P.S. Now I use $INCLUDE and just overwrite the included file with the new A 
record (using a simple bash script via an encrypted connection).



On Fri, 23 Apr 2021 12:21:22 +0200
Anand Buddhdev  wrote:

> Hi Greg,
> 
> You don't need to SSH into a remote server to do dynamic DNS updates!
> The "nsupdate" tool can send the dynamic DNS updates directly to your
> remote server over the DNS protocol.
> 
> You appear to be confused about what the various tools do, so here's a
> summary:
> 
> 1. ssh is used to log into a remote server, get a shell, and run
> operating system commands.
> 
> 2. rndc is for controlling a running BIND server. It can be used to
> check the status of BIND, reload it, etc.
> 
> 3. nsupdate is for modifying a zone directly (whether on the local
> machine, or some remote machine) using the dynamic DNS protocol.
> 
> Having read your message, it seems that you need to use "nsupdate". You
> don't need "ssh" or "rndc" for this.
> 
> Regards,
> Anand
> 
> On 23/04/2021 11:50, Greg Donohoe wrote:
> 
> > Thank you for the suggestions. I am looking into those now.
> > Yes we can run nsupdate again on the remote server but I would still need
> > to connect to the remote server to do this.
> > We were thinking of using SSH to the remote server but we want to explore
> > any other option rather than SSH for the secure connection.
> > I was thinking that it may be possible to use RNDC or some other tool to
> > update the remote BIND server zone files (either by modifying the zone file
> > that is already there or replacing the zone file with the new one I created
> > locally).
> > RNDC looks like it is a non starter for what I want but nsdiff may be a
> > good option.  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

Interesting, although we host different domains, in and from different 
geographic areas, we got the same queries as yours on the same day, with some 
at about the same time (we're EDT).

13-Apr-2021 02:19:58.468 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:58.638 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.365 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:19:59.366 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.568 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:03.820 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 02:20:04.546 security: info: client 76.20.145.58#3074 (sl): query 
(cache) 'sl/ANY/IN' denied


13-Apr-2021 03:04:25.379 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:25.553 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied
13-Apr-2021 03:04:26.539 security: info: client 92.204.191.45#2927 (sl): query 
(cache) 'sl/ANY/IN' denied

This is not a complete list, but they all were on Apr 13 (and near your times).

==

On Tue, 13 Apr 2021 15:23:20 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hi Paul,
> 
> Many thanks for your reply.  Yours is exactly the sort of reply I was hoping
> for because I feel like I have been banging my head on a brick wall for months
> now looking for someone else who cares whether their nameserver is an engine
> for this sort of abuse.  I was beginning to wonder if I was the only person
> in the world seeing this kind of abuse and regarding it as a problem.
> 
> I will leave another while to see if more clueful replies like yours arrive
> and then I will reply back to the list again myself to try to move the thread
> in the direction of requesting a solution which can easily be implemented by
> anyone and does not involve packet filters, firewalls, IPtables and so on.
> 
> In the meantime, I thought it would be interesting to see if I also got
> the same abusive queries you logged below.  Unfortunately (or fortunately)
> I am packet filtering incoming queries with source port 80 so they did not
> make it as far as the logs in my case.  Here are a few that did make it to
> my logs.  Maybe they are in yours too?
> 
> Regards,
> Peter Coghlan.
> 
> 13-Apr-2021 06:20:10.867 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.396 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.743 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 06:20:11.804 GMT 76.20.145.58#3074 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.746 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:32.935 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:33.993 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
> 13-Apr-2021 07:04:34.047 GMT 92.204.191.45#2927 (sl): query: sl IN ANY +E(0)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

Interesting observation. I just did lookups on 4 recent (< 24 hrs ago) 
'sl/ANY/IN' queries logged by our BIND and got:

2 Comcast cable IPs (hsd1.tx.comcast.net and hsd1.ma.comcast.net)
1 OVH Hosting IP (Montreal)
1 Afranet IP (Tehran!)

The whois info for the OVH IP contains the line:

  Comment:   Failover IPs


On Tue, 13 Apr 2021 14:04:14 -0700
Carl Byington via bind-users  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On Tue, 2021-04-13 at 22:32 +0200, Julien Salort wrote:
> > Reading this thread, I considered simply enabling the fail2ban
> > named-refused jail, but they advise against it because it would end
> > up
> > blocking the victim rather than the attacker.  
> 
> In the particular case of the .sl denied queries, I don't think these
> are forged queries from the attack victim. Something else is going on
> here. We see queries from systems like these, almost exclusively
> consumer endpoints:
> 
> 142-197-133-231.res.spectrum.com.
> mta-162-154-195-235.kya.rr.com.
> mobile-166-173-63-176.mycingular.net.
> prg03s05-in-f193.1e100.net.
> prg03s05-in-f1.1e100.net.
> pool-173-79-59-79.washdc.fios.verizon.net.
> 174-30-51-96.wrbg.centurylink.net.
> c-174-53-75-253.hsd1.va.comcast.net.
> 174-081-062-250.res.spectrum.com.
> cpe-174-106-58-62.ec.res.rr.com.
> 192.sub-174-214-12.myvzw.com.
> stop-looking-at-drifteds-ip.gov.
> 252.243.53.179.d.dyn.claro.net.do.
> ip184-186-26-40.no.no.cox.net.
> dsl-187-193-200-41-dyn.prod-infinitum.com.mx.
> dsl-189-178-58-206-dyn.prod-infinitum.com.mx.
> customer-189-216-112-75.cablevision.net.mx.
> 189.223.57.66.dsl.dyn.telnor.net.
> 212-149-157-12.rev.dnaip.fi.
> 
> It seems unlikely that someone is trying to attack those specific
> endpoints. Unless the attack is *very* widely distributed and they are
> actually attacking the ISP infrastructure. But in that case, this seems
> to be a simultaneous attack on almost every major ISP, which I find
> unlikely.
> 
> 
> -BEGIN PGP SIGNATURE-
> 
> iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCYHYHGhUcY2FybEBmaXZl
> LXRlbi1zZy5jb20ACgkQL6j7milTFsG2xwCeNRKi5df2TdmaWyJQJhGCraf1UIoA
> n0zp1wmsrlc9yeDc/wXJCy8xBToC
> =Ir5g
> -END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

Re: Preventing a particular type of nameserver abuse

[Paul Kosinski via bind-users]

We also get *lots* of suspicious queries of the same kind, from various 
privileged and unprivileged ports, which I'm pretty sure are DDoS attempts. For 
example:

  12-Apr-2021 23:44:17.767 security: info: client 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:44:19.477 security: info: client 107.213.131.17#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:00.908 security: info: client 98.229.97.172#80 (sl): query 
(cache) 'sl/ANY/IN' denied
  12-Apr-2021 23:45:01.263 security: info: client 98.229.97.172#80 (sl): query 
(cache) 'sl/ANY/IN' denied

Besides not wanting to be an unwilling DDoS amplifier, these bother me because 
they're filling up my BIND/named log files.

I've tried using IPtables hashlimit to throttle the requests, but have had 
little success. I've even tried blocking the responses with IPtables packet 
content matching plus hashlimit, but that doesn't help my log files!



On Mon, 12 Apr 2021 20:41:13 +0100 (WET-DST)
Peter Coghlan  wrote:

> Hello,
> 
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate.  It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.
> 
> In many cases, the source port is a low number such as 53, 80, 96 or 443
> for example which might make some sense if these were TCP queries but they
> are all UDP queries and apart from attempting to target port 53, attempting
> to target the other low UDP port numbers make no sense to me.
> 
> I have searched high up and low down for any discussion about this kind
> of abuse and found very little regarding abusive queries for the root
> nameservers, none at all regarding the sl domain (although it is a difficult
> term to search for) and nothing at all regarding the oddball source ports
> either.
> 
> Even though the "refused" responses from my nameserver are "small", the
> general persistence of the abusers over a long period of time suggests to
> me that they are finding these queries effective for some kind of abuse,
> perhaps by way of having a very large number of nameservers return them
> (unless they are too stupid to care whether the queries are answered or
> refused which I suppose is also possible).
> 
> As far as I can see providing no response at all in any instance when a
> code 5 refused response would normally be returned would be the appropriate
> thing for my nameserver to do here and doing this would cause no difficulties
> at all with any legitimate queries or anyone who is not an abuser.  Am I
> correct here?
> 
> I have searched for a way to prevent my nameserver from responding
> to these queries at all in order to reduce the impact on the targets
> of this abuse.  All results of my research point to the use of
> rate limiting as the only approach available for dealing with this
> sort of issue.
> 
> The abusive queries are clearly designed to circumvent the widely
> suggested "errors-per-second 5" as they arrive in groups of five
> per second and applying this limitation has little or no effect
> on them.
> 
> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.
> 
> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them.  I
> also routinely packet filter all UDP dns queries with source port
> numbers less than 1024 which I hope is the appropriate cutoff point.
> 
> Is there anything else I can do to reduce the impact of this abuse
> of my nameserver on others?
> 
> My feeling is that mine can't be the only nameserver experiencing this
> kind of abuse and that many nameserver admins probably would not even
> notice it unless they had query logging or query-error logging turned
> on and checked the logs.
> 
> Regards,
> Peter Coghlan.
___
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 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

[Paul Kosinski via bind-users]

Well said! 


On Mon, 29 Mar 2021 16:11:54 +0100
Tony Finch  wrote:

> alcol alcol  wrote:
> 
> > seriously? is like linux/unix FAQ   
> 
> Please, if you can't be helpful, don't reply at all. We all have to learn
> somehow, and the best way to show your knowledge is to share it generously.
> 
> Tony.
___
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: lists.isc.org and DMARC

[Paul Kosinski via bind-users]

Our DMARC Policy has been "p=quarantine" since 30 Jun 2019, so I guess it won't 
affect us. (It was "p=none" before that -- we only started using DKIM in Apr 
2017.)


On Tue, 16 Feb 2021 20:54:30 + (UTC)
Dan Mahoney  wrote:

> Greetings bind-users netizens.
> 
> Dan Mahoney, ISC SysAdmin here.
> 
> This is a message about lists.isc.org and DMARC.  If you aren't concerned 
> with DMARC, you can ignore it.  
> 
> Over a year ago, we added adaptations to lists.isc.org to allow mail from 
> DMARC-protected domains to be delivered.
> 
> If you've seen problems with the way lists.isc.org currently handles DMARC 
> (rewriting the From: header if your sending-domain has a restrictive 
> [p=reject or p=quarantine] DMARC policy), we'd like to hear from you at 
> listmas...@isc.org as we are considering making a slightly broader change.
> 
> We are considering setting lists.isc.org to ALSO rewrite the From: header, 
> even if your sending-domain has a DMARC (p=none) policy.  We think this is 
> important because otherwise a domain, in rolling out DMARC with p=none to 
> start, will see false positives from mailing lists (indicating that 
> messages sent via that list would be rejected by the final recipients' 
> mailservers/filters).
> 
> We believe it makes sense for lists.isc.org to behave the same for *ANY* 
> DMARC policy and are considering implementing that in the next few weeks.  
> We will keep you updated here.
> 
> -Dan Mahoney
> ISC

___
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: Problems with interfaces going down

[Paul Kosinski via bind-users]

Would it be possible to use a virtual interface from within bind/named that 
gets mapped by some privileged facility to a hardware interface? (This is the 
sort of thing that VMs have to do all the time.) For example, could a brctl 
bridge help?

Or maybe CAP_NET_BIND_SERVICE would allow the interface to be reactivated (if 
it's a privileged port issue).

Just brainstorming.

Paul


On Fri, 12 Feb 2021 18:33:21 -0500
bindus...@prograde.net wrote:

> Greetings,
> 
> I’ve been fighting a two-fold problem with named (bind 9.16.11) running on 
> macOS.
> 
> 1: If an ethernet interface being listened to drops link, named immediately 
> stops listening to it:
> 
> 12-Feb-2021 17:33:19.326 no longer listening on 192.168.88.220#53
> 
> and
> 
> 2: when link returns I get 2 tries to reestablish listening:
> 
> 12-Feb-2021 17:33:39.458 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:39.463 creating IPv4 interface en1 failed; interface ignored
> 12-Feb-2021 17:33:41.946 listening on IPv4 interface en1, 192.168.88.220#53
> 12-Feb-2021 17:33:41.951 creating IPv4 interface en1 failed; interface ignored
> 
> which both fail because named is no longer running as root.
> 
> --
> 
> Where I’m confused is that this ISC KB article:
> 
> https://kb.isc.org/docs/aa-00420
> 
> seems to imply that the "no longer listening" event is due to a periodic 
> interface scan finding the interface "unavailable".
> 
> That doesn’t fit my observations since it happens as soon as link is lost. If 
> some minutes-long periodic scan were needed to detect the interface being 
> down it would take, on average, half of that period to happen. It does not.
> 
> Further, I tried what the KB article advised by adding the option:
> 
>   interface-interval 0;
> 
> That does seem to stop the periodic scan (since my log is no longer filled 
> with errors) but the “no longer listening” event still occurs right when the 
> interface drops.
> 
> --
> 
> Is it not possible to have named drop to a non-root user (via -u) but still 
> recover from (or ride through) a momentary ethernet link loss?
> 
> Having the server stop working due to a switch I have no control over burping 
> is very suboptimal.
> 
> Thanks for any ideas.
> 
>
___
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 9.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

I don't think tcpdump was installed by default with various versions of Debian 
that I set up in the last few years for networking. I didn't bother to install 
it, as it's output is different enough (old fashioned?) from the sharks to be 
annoying. It *was* installed with OpenSuSE 15.2 though. (OpenSuSE 15.2 -- the 
"stable" release that wants you to update something every day.)


On Fri, 12 Feb 2021 00:35:53 +
"John W. Blue via bind-users"  wrote:

> Most people like yourself that do not care about OS purity often are not 
> obligated (granted super broad generalization) to explain their changes to an 
> Enterprise Change Management Board (ECMB or similar) for deviations from a 
> "standard image".
> 
> That is also 100% okay too.  Those types of shops/sysadmins also typically 
> don't have a buckets of cash sitting around either so you work with makes 
> sense and use the resources available to get it done.
> 
> The over-arching point is that the lowest common denominator for proper 
> troubleshooting is that tcpdump is useful and it does not need to be sourced 
> or installed.  It is ready to go out of the box for nearly all situations 
> that could potentially be encountered.
> 
> Usually. 
> 
> Murphy's law of unintended consequences should always be account for.
> 
> John
___
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 9.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

I rather prefer tshark to tcpdump: it's essentially the command line version of 
wireshark, and thus has wireshark's protocol "dissecting" abilities.


On Wed, 10 Feb 2021 22:20:08 +
"John W. Blue via bind-users"  wrote:

> Three words:  tcpdump and wireshark
> 
> It is like peanut and jelly .. hall and oates .. salt and pepper .. ebb and 
> flow .. pen and paper .. I could go on but …
> 
> Know them.  Love them.  They are your newest best friends.
> 
> 
> 
> Using tcpdump IMHO should be the first tool anyone uses when troubleshooting 
> seemly unexplainable DNS weirdness.
> 
> Knowing what is being put on the wire (or lack thereof) is critical since it 
> provides key factual data points that decisions can be made on.  When running 
> tcpdump on the DNS server I personally prefer this command:
> 
> tcpdump -n -i  -s 65535 -w 
> 
> dash n is telling tcpdump that you do not want it to resolve hostnames.  This 
> is an important option when doing DNS troubleshooting because you do not want 
> extra resolutions taking place.
> dash s is saying gimme the full packet.
> dash w is the name of the file you want the output saved in.
> 
> After starting the command, run several queries from a host and ctrl+c to 
> exit.
> 
> Once you get your file into wireshark now you can start slicing n dicing on 
> the data!
> 
> Here is handy wireshark filter:  dns.qry.name == internet-dns1.state.ma.us
> 
> By using a filter of dns.flags.rcode == (number here) you can drive off into 
> the weeds and get super granular with sorting the data.  For example 
> “dns.flags.rcode == 2” will show you all of the server failures for queries.
> 
> It is hard to provide further guidance on what to do since what you find in 
> the pcap is only a starting point.
> 
> Good hunting!
> 
> As an aside I would like to mention that you do not need to travel home to 
> get situational awareness when the diggui.com website can be used instead.
> 
> Also.  For the people running .us tld .. SHA1 for DNSSEC .. really?
> 
> https://dnsviz.net/d/state.ma.us/dnssec/
> 
> John
___
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 9.11 serving up false answers for a single domain.

[Paul Kosinski via bind-users]

Do you know about mxtoolbox.com? It (and other similar sites) does a good job 
of diagnosing DNS-related problems. I use it now and then to check out my own 
sites, as it gives a "second opinion".

In particular its "DNS Lookup' function reported the following for 
"internet-dns1.state.ma.us"

  Type  Domain Name IP Address  TTL
  A internet-dns1.state.ma.us   170.63.70.3615 min
  ...
  Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:44:08 PM (UTC -6), 
just for you.


But its "DNS Check" function them reported

  dns:internet-dns1.state.ma.us  
  No Results Found
  ...
  Reported by internet-dns2.state.ma.us on 2/9/2021 at 10:51:04 PM (UTC -6)

and later

  ...
  Reported by internet-dns3.state.ma.us on 2/9/2021 at 10:54:13 PM (UTC -6)

Strange indeed: sounds like they have problems.



On Tue, 9 Feb 2021 22:50:19 -0500
"sami's strat"  wrote:

> Thanks Mark.
> 
> However, the traceroute to the hostnamed failed for the same reason.
> Please note:
> 
> [root@myhost data]# dig internet-dns1.state.ma.us
> 
> 
> 
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us
> 
> ;; global options: +cmd
> 
> ;; Got answer:
> 
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61641
> 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> 
> 
> ;; OPT PSEUDOSECTION:
> 
> ; EDNS: version: 0, flags:; udp: 4096
> 
> ;; QUESTION SECTION:
> 
> ;internet-dns1.state.ma.us. IN  A
> 
> 
> 
> ;; Query time: 1263 msec
> 
> ;; SERVER: 192.168.33.12#53(192.168.33.12)
> 
> ;; WHEN: Tue Feb 09 22:34:15 EST 2021
> 
> ;; MSG SIZE  rcvd: 54
> 
> 
> 
> [root@myhost data]# dig internet-dns1.state.ma.us +trace
> 
> 
> 
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> internet-dns1.state.ma.us
> +trace
> 
> ;; global options: +cmd
> 
> .   516485  IN  NS  c.root-servers.net.
> 
> .   516485  IN  NS  e.root-servers.net.
> 
> .   516485  IN  NS  f.root-servers.net.
> 
> .   516485  IN  NS  l.root-servers.net.
> 
> .   516485  IN  NS  m.root-servers.net.
> 
> .   516485  IN  NS  d.root-servers.net.
> 
> .   516485  IN  NS  g.root-servers.net.
> 
> .   516485  IN  NS  k.root-servers.net.
> 
> .   516485  IN  NS  b.root-servers.net.
> 
> .   516485  IN  NS  h.root-servers.net.
> 
> .   516485  IN  NS  a.root-servers.net.
> 
> .   516485  IN  NS  i.root-servers.net.
> 
> .   516485  IN  NS  j.root-servers.net.
> 
> .   516485  IN  RRSIG   NS 8 0 518400
> 202103 2021020922 42351 .
> QCzDH8eHlHVbx4SxIIwk8xnk6ky/q+zRh8KAUfI98lqHcIP4NLxzCe6f
> mC2sNX1VcthEy6Lwnobm8OyJCRpNEHedYrS01aMhAVzUfM+/PJ9MWn0w
> SkmXxyZMJZXF/kl4GDNX0x/GW3+DkeTeZI9+B540Yvj47qJv2bD9nIQG
> NtE7bDze7bgMJkIuBlEzPfwp7YW5ud8qdC6HdUoEMqygwZcWAiQu8gpb
> q21z8W5hcdci1OouDFytNWrXAvfSsuR635+GzSj+RZjYo+447uP7lKsK
> N5aeVQ/BPh5jM32xVO+zwyp7v9Nky1vSP/BchMQ/3cqg3Ee7zobl8OQd CSd/SA==
> 
> ;; Received 1097 bytes from 192.168.33.12#53(192.168.33.12) in 0 ms
> 
> 
> 
> us. 172800  IN  NS  a.cctld.us.
> 
> us. 172800  IN  NS  b.cctld.us.
> 
> us. 172800  IN  NS  c.cctld.us.
> 
> us. 172800  IN  NS  e.cctld.us.
> 
> us. 172800  IN  NS  f.cctld.us.
> 
> us. 172800  IN  NS  k.cctld.us.
> 
> us. 86400   IN  DS  21364 8 1
> 260D0461242BCF8F05473A08B05ED01E6FA59B9C
> 
> us. 86400   IN  DS  21364 8 2
> B499CFA7B54D25FDE1E6FE93076FB013DAA664DA1F26585324740A1E 6EBDAB26
> 
> us. 86400   IN  RRSIG   DS 8 1 86400 202103
> 2021020922 42351 .
> rujvGB0s2bsqzBuzRliH6QK9vH84ETZV7gZMEhJyzMFofWhj9ZZaNWE/
> VvdA9rC16IOEocvARv2rOqk7G3KTzdkHHZcwcZSQyVqsOIaIywGFuEgd
> viSXF6+M5MocUgEMp5dtt6SBLHG+lE/FV/3HylKSHsxdO/F6PeWKgcBZ
> D4lZQ6w5asmlbdKJKMhlWPp6UaxBE7ACaxndBQixoNqXQuPrXpXi1Fnj
> ntFtTfn57hMyrdTojIJ8X7/HKjCrbm3CL/WJ+VZR051OGCdZVjpUaDXR
> x7G9lDhu3K5clar9PGYyUJM7+RBKzrQJep7HrjL2nZdoTyfY4i33S+EZ sTlTOA==
> 
> ;; Received 707 bytes from 199.7.91.13#53(d.root-servers.net) in 4 ms
> 
> 
> 
> state.ma.us.7200IN  NS  internet-dns3.state.ma.us.
> 
> state.ma.us.7200IN  NS  internet-dns1.state.ma.us.
> 
> state.ma.us.7200IN  NS  internet-dns2.state.ma.us.
> 
> state.ma.us.3600IN  DS  47628 7 2
> 5379F9F747214E5A63416775396BCFF98FA4867AE66E09BCBEBE0DCC 1682C369
> 
> state.ma.us.3600IN  DS  41388 7 1
> 36D899932AF794EADD671161515E48FE829BB7FE
> 
> state.ma.us.  

Re: Scripting dnssec-verify - processing command output

[Paul Kosinski via bind-users]

It sounds to me like dnssec-verify is sending the output in question to STDERR 
instead of STDOUT.


On Sat, 06 Feb 2021 19:02:28 +
Matthew Richardson  wrote:

> I have been using Perl to do a reasonable amount of scripting, running bind
> utilities and processing the results into variables.  The details below are
> from Bind 9.11.27 on Centos 7.
> 
> The code:-
> 
> $resp = `dig -t soa example.com`;
> print "dig resp:'$resp'\n";
> 
> gets the result of the dig command into the variable $resp and prints it.
> 
> However:-
> 
> $resp = `dnssec-verify -I text -o example.com example.com.zone`;
> print "dnssec-verify resp:'$resp'\n";
> 
> displays the results of the dnssec-verify command on the console and leaves
> the variable $resp empty.
> 
> Any ideas would be appreciated...
> 
> As an aside, using dnssec-keygen DOES put the results into the variable.
> 
> Best wishes,
> Matthew
___
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

[Paul Kosinski via bind-users]

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

-Paul K.




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.
> 
> -Jim P.
>
___
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

[Paul Kosinski via bind-users]

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.



On Sun, 22 Nov 2020 22:58:07 -0500
Jim Popovitch via bind-users  wrote:

> 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.  People really need to verify
> who they are replying to, it's easy to see from the "Servfail on Bind
> -9.16.1" thread where the problem(s) exist.
> 
> Note Paul, I only received one copy of your post, and you should be only
> receiving one copy of my reply.
> 
> -Jim P.


-
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

Two copies of recent posts

[Paul Kosinski via bind-users]

I've been getting two identical copies of recent posts to this list
(such as this item). This only started happening in the past 24 hours
or so. Is anyone else seeing this?

Upon examination of the headers of the two copies, it looks like ISC's
list-servers are doing the duplication. 

(The first part of the actual message follows the headers.)

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


On Mon, 23 Nov 2020 10:47:20 +1100
Mark Andrews  wrote:

> Ok.  Lets start by debugging this from the trust anchor downwards.
> Lets see what "dig +dnssec +cd dnskey .” returns.  It should return
> something like below with 2 DNSKEY records and a RRSIG for the DNSKEY.
> The RRSIG is regenerated daily so it will likely differ.  The DNSKEY
> records should be a exact match.  In this case flags contains ‘ad’ which
> means that the RRset has previously been validated.

> > 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: How can I launch a private Internet DNS server?

[Paul Kosinski via bind-users]

With regard to using chroot, hasn't named/BIND long had the "-u" (user)
and "-t" (directory) options to accomplish the same thing more easily?


On Fri, 16 Oct 2020 12:47:35 -0500
Chuck Aurora  wrote:

> /me catching up on earlier parts of this thread,
> 
> On 2020-10-15 11:42, alcol alcol wrote:
> > A DNS server can exist if you follow NIC instractions.
> >  Mainly have you a leased line ever on? primary DNS can't be down or
> > NIC could down your domain.
> >  Then you have to install and configure it. Better a fedora core , and  
> 
> I'm not sure what all that means (language barrier, perhaps), but I
> have some gripes with what I do understand.
> 
> First, re: Fedora, no one distro/OS can truly claim to be best.  The
> best advice to a beginner is to choose one and to learn it very well.
> Fedora can be a good choice, as can other GNU/Linux distros, as also
> can be various *BSD flavors.  The point is: it depends what the user
> is comfortable to manage.
> 
> > CHROOT, DNS is one of the services more targeted to enter inside a
> > system.  
> 
> False.  A chroot is a fine idea if you know how to set it up and to
> maintain it, but it is certainly not a requirement for a beginner.  A
> beginner in BIND (as in anything else) will do best by starting simple
> and building on what is learned.
> 
> Also, while DNS is indeed a target of abuse, I honestly cannot recall
> a single exploit of BIND 9 that would lead to system penetration.  It
> is true that BIND's named has had more than its share of security
> issues and bugs, but TTBOMK all of these have been crashes, causing
> only denial of 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: Deconstructing the Great Firewall of China

[Paul Kosinski via bind-users]

The article is from 2016, probably before DNSSEC become so widespread.
But I would guess that their current overall approach is not a radical
departure from what was outlined in the article.


On Tue, 23 Jun 2020 13:41:18 +0200
Alessandro Vesely  wrote:

> On 2020-06-05 9:29 p.m., Paul Kosinski via bind-users wrote:
> > A very interesting article on how China uses DNS (among other things)
> > to "control" Internet usage.
> > 
> > https://blog.thousandeyes.com/deconstructing-great-firewall-china/  
> 
> 
> The term "DNSSEC" appears just once in that article, after the
> picture.  Yet, maps[*] show China as a fully operational country in
> that respect.
> 
> [*] https://www.dnssec-deployment.org/tag/maps/
> 
> Best
> Ale
___
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

Deconstructing the Great Firewall of China

[Paul Kosinski via bind-users]

A very interesting article on how China uses DNS (among other things)
to "control" Internet usage.

https://blog.thousandeyes.com/deconstructing-great-firewall-china/
___
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: DoH plugin for BIND

[Paul Kosinski via bind-users]

I wasn't complaining about port 25, I was just citing it as a
counterexample to the claim that ISPs "must" pass all traffic.

I think that most ISPs tell customers how to set up their email clients
(NUAs) including what port to use. Of course it seems that now most
people use Web based email like Gmail, Yahoo (and even Comcast/Xfinity)
so they never see port numbers.


On Sat, 2 May 2020 15:51:58 +0200
Reindl Harald  wrote:

> Am 02.05.20 um 15:41 schrieb Michael De Roover:
> > In my experience and from what I've heard, very few.   
> 
> if that would be true how comes that most mail clients still default to
> 25 for submission and years after closing port 25 on our mailserver i
> still struggle with customers smartphones still not using 587?
> 
> in fact 10 years ago some ISP's *tried* to kill outbound port 25 because
> there is no point in using it from a homemachine and at that time we
> struggeled also to explain our customers that 25 is plain wrong
> 
> finally they gave up because the damage of open port 25 is killed with
> dnsbl but the customer support went crazy with "why can't i send email
> with my internet connection"
> 
> > Even if your ISP allows it, chances are that other mail servers will reject 
> > it  
> 
> that's a completl different story
> 
> > On 5/2/20 3:30 PM, Paul Kosinski via bind-users wrote:  
> >> How many ISPs allow traffic on port 25? My impression is that even many
> >> (non-enterprise) business customers can't use port 25  
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: DoH plugin for BIND

[Paul Kosinski via bind-users]

How many ISPs allow traffic on port 25? My impression is that even many
(non-enterprise) business customers can't use port 25.


On Sat, 2 May 2020 09:28:54 +0200
Reindl Harald  wrote:

> Am 02.05.20 um 09:00 schrieb Michael De Roover:
> > That's actually my biggest concern with DoH, ISP blocking. It doesn't
> > seem as obvious as it is with DoT, but deep packet inspection (DPI) is
> > already a thing. Don't expect an ISP that wants to block DoT to not
> > (want to) block DoH either. The crux of the problem at that point is not
> > the technology, it is the ISP's incentives. If the ISP wants to block
> > DoT for whatever reason, personally I'd consider it.. not exactly fine
> > but at least their right to do so. That's their decision to make.   
> 
> seriously?
> 
> that seems to be some US attitude, no wonder what happens there with
> user attitudes like "but at least their right to do so"
> 
> the ISP by definition has exactly one right: get money for his service
> which is described as "route and transfer every package, don't look at
> it, don't mangle it, you have no business about the content of my traffic"
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Problem to transfer reverse zone DNS on secondary DNS servers

[Paul Kosinski via bind-users]

I was pleased that I was able to get our two (successive) ISPs to set
up reverse DNS for our small number of IP addresses, and each twice to
change them when they moved us to moved us to new IP ranges (due to the
IPv4 crunch). It never even occurred to me that it might be possible to
have them delegated to our DNS server (which could handle it, being
BIND running native on a Linux VM on their hardware -- no "helpful"
ISP mandated interface software to interfere with configuration). 

P.S. Unfortunately our 2 current IPs, although adjacent, are not /31,
and thus would require 2 delegations


On Fri, 27 Dec 2019 13:40:11 -0700
Grant Taylor via bind-users  wrote:

> On 12/27/19 1:22 PM, Reindl Harald wrote:
> > nobody out there will delegate single /255 ip's
> 
> I've had multiple different ISP's delegate reverse DNS for single IPs 
> (/32 or /128) multiple times.
> 
> Some used RFC 2317 Classless IN-ADDR.ARPA Delegation, others used 
> standard delegation.
> 
> Some ~> many ~> maybe most will not delegate in any way.  But enough 
> have done so (repeatedly) to definitely NOT be able to say nobody
> will delegate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Peculiar DNS queries

[Paul Kosinski via bind-users]

Every so often, we get a run of peculiar queries to our (BIND / named)
DNS server. Note the apparently random mix of lower case and upper case
letters in the domain names.

Does anybody have any idea why somebody would be doing this? (It's
legal, I guess, but quite non-standard.)

Dec 22 12:05:43 iment0 named[10333]: client 134.0.217.68#20012 (Www.IMent.coM): 
query: Www.IMent.coM IN  -E (216.55.100.246)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.54#53150 (Www.iMent.Com): 
query: Www.iMent.Com IN  -E (216.55.100.246)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.53#27016 (WWw.imENT.cOm): 
query: WWw.imENT.cOm IN A -E (216.55.100.245)

Dec 22 12:05:44 iment0 named[10333]: client 134.0.217.69#23417 (WWw.IMeNt.cOM): 
query: WWw.IMeNt.cOM IN A -E (216.55.100.245)

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

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

Re: Zoneformat

[Paul Kosinski via bind-users]

"... long ago adapted to using full numbers, including area codes, for
pretty much *all* phone dialing ..."

Except that that proved to be so onerous that people often use "speed
dialing" for commonly dialed numbers. (Not to mention the fact that
people usually address their friends and coworkers by short names.)


On Mon, 28 Oct 2019 12:19:35 -0400
Kevin Darcy  wrote:

> [ Classification Level: PUBLIC ]
> 
> My opinion? It's better to wean your users away from shortnames than
> to try to cobble together kludges, on the client side or the BIND
> side, to support a bad habit. Shortnames introduce ambiguity, lead to
> nasty surprises, are inefficient and insecure. Just like we (in the
> U.S. at least) long ago adapted to using full numbers, including area
> codes, for pretty much *all* phone dialing, people can adapt to using
> FQDNs. They've already adapted to it, overwhelmingly, for Internet
> web traffic (notwithstanding some "helpful" browsers that will tack
> on "www" to the front of a shortname, and ".com" at the end, which is
> often *not* what is wanted or safe). Why have a different user
> experience, when on or off the enterprise network, a perimeter that
> is quickly eroding? Just use FQDNs everywhere, keep it consistent.
> 
> Anyway, that's my 2-cents, from someone who has been battling the
> "shortname disease" for decades, with a substantial amount of
> (although not perfect) success.
> 
> 
>   - Kevin
> 
> On Mon, Oct 28, 2019 at 8:56 AM MEjaz  wrote:
> 
> > Noxexistent domain error .
> >
> > Here is my configuration.
> > ===
> >
> > zone "crm365app" {
> > type master;
> > file "crm365app.cyberia.net.sa.hosts";
> > allow-query {any;};
> > };
> >
> >
> > File
> >
> > 
> > [root@ns1 ~]# cat  /var/named/crm365app.cyberia.net.sa.hosts
> > $TTL 3600
> > ;   Addresses and other host information
> > ;
> > ;
> >
> > @   IN  SOA ns1.cyberia.net.sa. root.cyberia.net.sa. (
> > 2015034459 ; serial
> > 43200   ; refresh every 12 hours
> > 4320; retry after 1 hour
> > 1209600  ; expire after 2 weeks
> > 21600 )  ; minimum
> >
> > ; Define the name servers and mail servers
> >
> > IN  NS  ns1.cyberia.net.sa.
> > IN  NS  ns2.cyberia.net.sa.
> >
> > IN  MX  10 smtp.cyberia.net.sa.
> >
> > ; Define localhost
> > *INA   127.0.0.1
> >
> > ; Define hosts in this zone
> >
> >
> > www IN  CNAME   webhost.cyberia.net.sa.
> > crm365app   IN  A   212.71.33.252
> >
> > =zone file
> > end=
> >
> > [root@ns1 named]# host crm365app
> > Host crm365app not found: 3(NXDOMAIN)
> >  [root@ns1 named]# named-checkzone crm365app
> > crm365app.cyberia.net.sa.hosts
> > zone crm365app/IN: loaded serial 2015034459
> > OK
> >
> > -Original Message-
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On
> > Behalf Of Reindl Harald
> > Sent: Monday, October 28, 2019 1:46 PM
> > To: bind-users@lists.isc.org
> > Subject: Re: Zoneformat
> >
> >
> >
> > Am 28.10.19 um 11:01 schrieb MEjaz:
> > > *From:* MEjaz [mailto:me...@cyberia.net.sa]
> > > *Sent:* Monday, October 28, 2019 10:27 AM
> > > *To:* 'bind-users-boun...@lists.isc.org'
> > > 
> > > *Subject:* Zoneformat
> > >
> > > Is ther any way I can create the zone without the (.) I mean non
> > > fully qualified domain name just as "example" instead
> > > "example.com"'
> >
> >
> > what is the problem you try to solve?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: search and ndots support in bind utilities

[Paul Kosinski via bind-users]

Following https://www.icann.org/en/system/files/files/sac-064-en.pdf,
it sounds like modest groups of Internet users (such as informal clubs)
that don't have their own official domain (like "iment.com") are out of
luck if they would like to have local subdomains -- unless they want to
use the quite misleading reserved TLD "test", that is.

It's really too bad that the committee that expanded the space of TLDs
weren't as farsighted as those who allocated the IPv4 addresses to
include non-routable ones for local (intra-LAN) use.

P.S. Note that the domain implied by the PTR lookup result of such a
group's external IP address, although unique, is usually not suitable.
Most can change without notice due to DHCP, and they also tend to be
something unworkable, like "c-66-31-152-1.hsd1.ma.comcast.net.".


On Mon, 30 Sep 2019 09:35:57 -0600
Paul Ebersman  wrote:

> pemensik> I am aware search is a no-no in DNS community. However, is
> pemensik> there any public documentation to this change? Is there RFC
> pemensik> recommending not to use search or how it should be used,
> pemensik> related to today's top level domains?
> 
> pemensik> While I agree it is dangerous, there are still people using
> pemensik> it. I think we should point them at some document,
> pemensik> explaining what are possible dangers. How to use it safe
> pemensik> way or how to avoid using it at all.
> 
> See ICANN SSAC doc 64:
> 
>   
> 
> It goes into detail on why search/suffix lists are a bad idea.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

DMARC test

[Paul Kosinski via bind-users]

Testing how lists.isc.org handles DMARC "Quarantine" (and "Reject")
policy. The enterpr...@mozilla.org mailing list forwards such email in a
way that some recipients choke on it (i.e., can't validate it).
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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