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

Re: Barclays bank domain unresolvable only on some servers

[Paul Kosinski]

A *bank* not using DNSSEC??  Glad I don't have any money there.



On Sun, 16 Jun 2019 14:00:36 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> 
> On Sun, 16 Jun 2019, Mark Andrews wrote:
> 
> > The servers for this zone are broken, they do not respond to
> > queries with DNS COOKIE options present.  You can add server
> > options to named.conf to work around this while Barclays fix their
> > servers / firewalls.  Modern recursive servers are no longer
> > working around broken servers that do not respond to queries.  See
> > DNS flag day.  It looks like Barclays ignored the messages.
> 
> They have some history of ignoring messages:
> 
> $ whois barclays.com | grep DNSSEC
> DNSSEC: unsigned
> 
___
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: Help: BIND _ Recursive query

[Paul Kosinski]

I gather "recursion yes" (explicit or default) controls whether BIND
*does* recursion itself, in the sense of querying other DNS servers for
data it doesn't have, not whether it *issues* queries with the
"recursion desired" flag set. (Somewhat confusing terminology, in my
opinion.)

So is the "recursion desired" flag only set when there are forwarders?
Presumably it is set in the case of "forward only", but what happens if
there are forwarders defined and both "recursion yes" (default) and
"forward first" (default) are specified?


On Mon, 4 Mar 2019 19:30:36 +0100
Matus UHLAR - fantomas  wrote:

> >On 4 Mar 2019, at 16:20, Paul Kosinski wrote:
> >> provides our users with general caching DNS service for
> >> all other domains.
> >
> >[...]
> >
> >> Its "named.conf" file doesn't list any "forwarders" any more, and
> >> "forward-only" is gone, but it still has a leftover "recursion yes"
> >> clause. Am I correct is assuming that this is now useless and can
> >> be removed?
> 
> On 04.03.19 16:33, Niall O'Reilly wrote:
> >If you want "general caching DNS service" to continue to work,
> >you'll need to keep "recursion yes".
> 
> actually "recursion yes;" is the default, so if you remove it, it
> stays set to yes (unless it's set to "no" somewhere).
> 
> recursion is the feature that allows BIND to resolve domains not
> configured locally, you surely need it enabled.
___
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: Help: BIND _ Recursive query

[Paul Kosinski]

We have a BIND server on our LAN which is authoritative for our ".local"
domain and also provides our users with general caching DNS service for
all other domains.

Its "named.conf" file doesn't list any "forwarders" any more, and
"forward-only" is gone, but it still has a leftover "recursion yes"
clause. Am I correct is assuming that this is now useless and can be
removed?

Thanks.


On Mon, 4 Mar 2019 07:37:11 +1100
Mark Andrews  wrote:

> Iterative mode is the default lookup mode for recursive servers.  It
> is where the server follows the delegations from the root servers to
> talk to the authoritative servers directly.  Recursive mode is where
> you use another recursive server (in iterative mode) to talk to the
> authoritative servers. Stub resolvers (in applications) use recursive
> mode.
> 
> > On 4 Mar 2019, at 2:17 am, Matus UHLAR - fantomas
> >  wrote:
> > 
> > On 03.03.19 07:36, vivek wrote:
> >> thanks, that means for Bind service to work  we have to have the
> >> "recursion yes" else the forwarder will also not work.
> >> 
> >> Actually I m bit confused between Recursive vs Iterative query
> >> mode , so does this mean Bind will only work in Recursive query
> >> mode & this makes the "Forwarder "  to do his required job.
> >> 
> >> Help in understand so in what scenarios will use/configure Bind in
> >> Iterative query mode.
> > 
> > iterative mode happend when domain is configured locally, otherwise
> > recursive mode is used. you don't need to configure 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

Re: Forward zone inside a view

[Paul Kosinski]

I haven't analyzed the details and pitfalls, but could a Web proxy
mechanism of some sort be of help? In particular, rather than having
your users directly access "teamviewer.org" (or whatever), have them to
access "teamviewer.local", which is resolved by your internal DNS to a
specialized proxy server.

Then set up this proxy server to forward those requests to
"teamviewer.org", *not* its IP address (since that can, of course,
change). This is likely the hard part, but the proxy can at least
assume that it never gets HTTP(S) requests in general. 

In other words, move the mapping one level up in the protocol stack,
from the DNS layer to the HTTP(S) layer.

And, if the proxy can support the equivalent of name-based hosting, then
it could support multiple local domain redirects, if needed in the
future. 

P.S. PRIVOXY is probably able at least to do the redirect for a single
domain -- and it's lightweight.




On Thu, 7 Feb 2019 15:00:47 -0500
Alan Clegg  wrote:

> On 2/7/19 2:30 PM, Roberto Carna wrote:
> > Dear, thanks for your contact. I've used teamviewer.com
> >  just for tests.
> > 
> > Desktops I mentioned can only access to web apps from internal
> > domains, but in some web apps there are links to download
> > Teamviewer client software from Internet. I can create a private
> > zone "teamviewer.com " with all the
> > hostnames and IP's we will use, but if they change I will be in
> > trouble.
> 
> Sounds to me like a use for a global block with RPZ and a passthrough
> for the domain that needs to be ... uh ... passed through.
> 
> And from my experience, this is never going to work because whatever
> the "only thing we want to resolve" is, it will rely on something
> else that you don't (currently) resolve.
> 
> Anyone that has ever tried to block their "smart TV" so that it only
> allows certain apps but not others will know exactly what I'm talking
> about.
> 
> AlanC

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

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

Re: Question about visibility

[Paul Kosinski]

Maybe port scanners will find open ports pretty quickly, but I've found
that using non-standard ports is helpful in reducing traffic, at least.
For example, SSH on port 22 gets lots of SYNs but moving it elsewhere,
and making 22 totally unresponsive discourages most such attempts. This
increases security slightly a priori, and may also improve security by
simplifying the firewall log(s).

When using OpenVPN over UDP, the standard port 1194 can be subject to
random and/or attack packets. These have to be processed and rejected
(since their HMACs etc. hopefully won't pass decryption). This won't
occur in TCP mode, of course, but UDP tends to be more efficient,
especially since TCP over TCP tends to clog up.

P.S. When you come right down to it, *all* computer (software) security
is "security by obscurity", whether the obscurity of passwords, private
keys, etc. For example, DES is no longer used because 56-bit keys are no
longer obscure enough to hide from modern computers.


On Wed, 24 Oct 2018 13:24:41 +
Timothy Metzinger  wrote:

> There's no security in obscurity.  Automated port scanners will sweep
> your system in a couple of seconds.
> 
> Tim Metzinger
> 
> From: bind-users  on behalf of G.W.
> Haywood via bind-users  Sent: Wednesday,
> October 24, 2018 12:15:10 PM To: bind-users@lists.isc.org
> Subject: Re: Question about visibility
> 
> Hi there,
> 
> On Wed, 24 Oct 2018, Hardy, Andrew wrote:
> 
> > Further to the original post, as well as not creating a DNS record
> > and "possibly" adding robot.txt with appropriate content, as
> > discussed, I presume that if I run the http server on a personally
> > selected unprivileged port then it is very "unlikely" the site pages
> > will be indexed/discovered/etc surely?
> >
> > Thoughts?
> 
> A server on a non-standard port is often neglected.  Its security may
> be less well maintained than one that is intentionally public.
> 
> That's just the sort of thing that criminals are looking for.  They'll
> probably find it, and then they'll attack it.
> 
> --
> 
> 73,
> Ged.
> ___
> Please visit
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C0%7C636759801644561901sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSblAfVbLI%3Dreserved=0
> to unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7C%7C0b805cc1bd334bd7ea4808d639aa77ec%7C84df9e7fe9f640afb435%7C1%7C0%7C636759801644561901sdata=CqjF4k0IMJVEbFnKVPzflLNxc8LyguCF7iSblAfVbLI%3Dreserved=0
> 
> Tim Metzinger
> 703.963.3015
> 
___
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: Operational Notification: Some releases of BIND are too strict when handling referrals containing non-empty answer sections

[Paul Kosinski]

Code refactoring is nothing compared to what Mozilla did to Firefox!

It's hard to believe they didn't change the name, given that they
totally changed the add-on interface and thereby removed so many of the
features that made Firefox our browser of choice.


On Thu, 20 Sep 2018 09:48:08 +0100 (BST)
"G.W. Haywood via bind-users"  wrote:

> Hi there,
> 
> On Wed, 19 Sep 2018, Michael McNally wrote:
> 
> >   ... code refactoring ...
> 
> That phrase always sends shudders through my corpus.
> 
___
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: SRV record not working

[Paul Kosinski]

Extra complexity -- "man dig" yields 289 lines while "man nslookup"
yields only 160 lines.

Also, dig is not simply an extension of nslookup (which I long ago
abbreviated to nsl), but is significantly different, so it using it
involves the human analog of a cache miss.


On Sat, 18 Aug 2018 20:12:01 +0200
Reindl Harald  wrote:

> 
> 
> Am 18.08.2018 um 20:02 schrieb Paul Kosinski:
> > When I started using Linux almost 20 years ago, I think there was
> > only nslookup, and no dig. So by habit, I tend to use it unless the
> > extra power of dig outweighs its extra complexity. 
> 
> which extra complexity?
> 
> because you have to add an @ when you want to use a non-default
> nameserver and that you need "dig -X" for a reverse-lookup?
> 
> you can use dig as nslookup, it's not required that you add a record
> type - just "dig whatever" which is in that case even shorter
> 
> > On Sat, 18 Aug 2018 11:42:20 -0600
> > Grant Taylor via bind-users  wrote:
> > 
> >> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> >>> I don't think anyone hates nslookup (well maybe a few do )
> >>> I suppose the immense dislike stems from the fact that it's the
> >>> default utility under Windows. Folks who use dig as their default
> >>> realize that when used properly, dig provides much more
> >>> functionality than nslookup. For example, try using TSIG with
> >>> nslookup or getting a NSID response. These are only a couple of
> >>> examples. There's other reasons to change. The output from dig is
> >>> much more comprehensive. And, yes, if you install the bind tools
> >>> from ISC under Windows, dig works quite well.
> >>
> >> I've been told that nslookup will lie and provide incorrect
> >> information in some situations.  I have no idea what situations
> >> that is.  I would love to learn what they are.
> >>
> >> If you know of such an example, please enlighten me.
> >>
> >> As such, I tend to use nslookup on platforms without dig when or
> >> until I have reason to not do so
> 
> 
___
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: SRV record not working

[Paul Kosinski]

When I started using Linux almost 20 years ago, I think there was only
nslookup, and no dig. So by habit, I tend to use it unless the extra
power of dig outweighs its extra complexity. I don't remember what I
used on Windows back when I was regularly using both.


On Sat, 18 Aug 2018 11:42:20 -0600
Grant Taylor via bind-users  wrote:

> On 08/18/2018 07:25 AM, Bob McDonald wrote:
> > I don't think anyone hates nslookup (well maybe a few do ) I 
> > suppose the immense dislike stems from the fact that it's the
> > default utility under Windows. Folks who use dig as their default
> > realize that when used properly, dig provides much more
> > functionality than nslookup. For example, try using TSIG with
> > nslookup or getting a NSID response. These are only a couple of
> > examples. There's other reasons to change. The output from dig is
> > much more comprehensive. And, yes, if you install the bind tools
> > from ISC under Windows, dig works quite well.
> 
> I've been told that nslookup will lie and provide incorrect
> information in some situations.  I have no idea what situations that
> is.  I would love to learn what they are.
> 
> If you know of such an example, please enlighten me.
> 
> As such, I tend to use nslookup on platforms without dig when or
> until I have reason to not do so.
> 
> 
> 
___
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 question

[Paul Kosinski]

We have a couple of small domains whose DNS is served by BIND on our dedicated 
machines. Almost 3 years ago we had set up DMARC records, and were getting 
reports from various MXs every day until a couple of days ago (Aug 13). Then 
they suddenly stopped!

Nothing in the BIND config or zone files was changed, and our Postfix mail logs 
(on our dedicated server) don't show *anything* addressed to our DMARC target 
since then. (I.e., it's not that our spam filtering is dropping them.)

Has anyone ever observed anything like this?

Thanks!
___
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: Domain name based multihome routing?

[Paul Kosinski]

We do something somewhat similar with our LAN. We have a new cable
connection and an old DSL connection. The cable is 60x faster, but has
a dynamic IP and blocks various ports (esp. 25), so we keep the DSL so
we can send email directly etc.

Obviously, we don't want to stream video or even do much Web browsing
over the DSL. So we have set up a Linux computer to serve as a gateway
and firewall: it runs IPtables, Privoxy, HAVP (virus filter for HTTP),
ClamAV and even Bind (a 3rd DNS server for our small domains).

This works fairly straightforwardly because decision as to whether to
use cable or DSL is made according to the *source* IP address, rather
than the destination IP address (or domain name, or port). Since
many browsers (we use Firefox) and other Internet software have the
ability to specify a proxy for Internet access, we usually connect them
to a proxy server on the gateway which in turn binds to an alias IP on
either the NIC connected to the DSL modem or the cable modem.

Then we have 2 routing tables, the default one for the (original) DSL
and a second one for cable. Each routing table gas its own default
route, and each is 'via' the corresponding modem.  To decide which way
packets go, we make use of a 'rule' table (iproute2) which says which
routing table to use. It has entries generated by iproute2 functions
such as:

  /sbin/ip rule add from lookup cable
  /sbin/ip rule add to lookup cable
  /sbin/ip rule add iif  br2   lookup cable

This last rule says the *everything* from (sub) LAN 2 goes via cable.
This allows whole sets of devices (such as our computer dedicated to TV)
to be connected strictly to cable.

Note that even though you bind to an alias IP on the NIC physically
connected to a specific modem, if that modem isn't the overall default
route, you still need a 'rule' to make the kernel do the right thing.

In summary, this scheme does not give you totally automatic control of
what kind of traffic goes by what physical link, but it does allow
different browser instances on a single computer to use different
physical links via proxying, plus it easily allows different devices on
the LAN to be handled differently (since they each have their own IP
address).

--

On Wed, 27 Jun 2018 13:17:41 -0500
Dale Mahalko  wrote:

> On Wed, Jun 27, 2018 at 12:27 PM, Darcy Kevin (FCA) <
> kevin.da...@fcagroup.com> wrote:
> 
> > I’m not convinced DNS has any valuable role to play here. Seems
> > like this is a traffic-shaping challenge; maybe one of the open
> > source traffic shaping tools would fit the bill.
> >
> 
> A Google search for multihome traffic shaping yields nothing obvious.
> 
> Do you have specific details you can share about exactly how that
> would be done?
> 
> Also how is traffic shaping going to tell the difference between a
> background Apple iOS update or Windows update that need to use the
> DSL, and the high priority data streams that are more important to
> me, that need to use the cellular modem?
> 
> 
> Shaping is not routing, it just prioritizes some data streams over
> others. I don't see how shaping is going to know whether to use the
> DSL or the Cellular ... without inspecting the domain name before a
> connection is established which is what I'm already discussing
> here...
___
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: Stopping name server abuse

[Paul Kosinski]

Most of your replies seem not to address the (immediately
preceding) paragraph they appear to be responding to.


On Mon, 25 Jun 2018 22:15:07 +0200
Reindl Harald  wrote:

> 
> 
> Am 25.06.2018 um 22:01 schrieb Paul Kosinski:
> > Somebody who has irresponsibly (and apparently wantonly, given his
> > refusal to fix it) delegated his domain(s) to your DNS server is
> > essentially causing a (modest bandwidth) distributed denial of
> > service attack on your server. I don't think that the "responsible"
> > thing to do is to sit there and suffer from a significantly
> > increased load.
> 
> no, but you proposed timeout don't change that anyways
> it makes things only worser
> 
> if you have noticeable increased load in real life becuase of some
> domains you no longer want to host on a nameserver you are lost
> anyways and calling that a distributed denial of service is a joke
> 
> > What should be done is to get the domain(s) revoked if the owner
> > continues to refuse to remedy the problem: it is *he*, not you, who
> > is being irresponsible. 
> 
> if you make things worser for everyone without any gain *you are*
> irresponsible because you don't understand the outcome of your actions
> like funny timeouts
> 
> > And if the queries are coming via an innocent
> > ISP's resolver, then they are inadvertently assisting in the attack,
> > and should be contacted and asked to help in the remediation. (Note
> > that *their* resources, as well as yours, are being wasted.)
> 
> you will contact every ISP and resolver admin out there?
> seriously?
> and ask them to do what exactly?
> 
> if you call me and tell me your story about domains pointing to your
> nameserver and why we as ISP don#t stop asking the response you
> deserve is not allowed legally
> 
> the question was how to reduce the load and your answers where how to
> increase load and make things worser for everybody and things much
> complexer - the only correct way to get this *finally* resolved is
> force the registry of the domain to remove your nameservers and
> that's it instead of calling innocent parties or playing technical
> games with no gain
___
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: Stopping name server abuse

[Paul Kosinski]

Somebody who has irresponsibly (and apparently wantonly, given his
refusal to fix it) delegated his domain(s) to your DNS server is
essentially causing a (modest bandwidth) distributed denial of service
attack on your server. I don't think that the "responsible" thing to do
is to sit there and suffer from a significantly increased load.

What should be done is to get the domain(s) revoked if the owner
continues to refuse to remedy the problem: it is *he*, not you, who is
being irresponsible. And if the queries are coming via an innocent
ISP's resolver, then they are inadvertently assisting in the attack,
and should be contacted and asked to help in the remediation. (Note
that *their* resources, as well as yours, are being wasted.)


On Mon, 25 Jun 2018 17:47:23 +0200
Reindl Harald  wrote:

> Am 25.06.2018 um 17:37 schrieb Barry Margolin:
> > In article ,
> >  Paul Kosinski  wrote:
> > 
> >> How does *not* responding to a UDP query take longer for the
> >> *server* than responding to UDP a query? Both responding and
> >> (deliberately) not responding require identifying the query, but
> >> not responding bypasses the time the server would need to
> >> construct the response, plus time spent in the network stack. (I'm
> >> assuming we don't care about client side "expense".)
> > 
> > If there's no response, the client retries several times. It will
> > try all the servers that the zone is delegated to, so you'll put
> > more load on multiple servers.
> > 
> > NXDOMAIN responses are cached, it's one hit and then nothing for a
> > while
> 
> and additionally "I'm assuming we don't care about client side
> "expense" is nonsense because the client in question is typically a
> *innocent* ISP resolver or something like 8.8.8.8 and the attitude "i
> don't care about them" is irresponsible because as sysadmin you are
> expected to think what your actions mean for the whole ecosystem
> 
> 
___
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: Stopping name server abuse

[Paul Kosinski]

How does *not* responding to a UDP query take longer for the *server*
than responding to UDP a query? Both responding and (deliberately) not
responding require identifying the query, but not responding bypasses
the time the server would need to construct the response, plus time
spent in the network stack. (I'm assuming we don't care about client
side "expense".)

Of course, if not responding to a UDP query provokes a TCP query, that
might increase the total server time needed, since TCP is inherently
more expensive for short transactions like DNS.

P.S. If you have something like iptables (with its string matching) in
front of your DNS server, you could just drop UDP queries for bogus
domains rather than letting them in at all. Or you could even route
them to a special lightweight server that just yields canned responses.
(This wouldn't work for TCP, because the query doesn't come until after
the connection is established.)



On Mon, 25 Jun 2018 15:32:44 +0200
Reindl Harald  wrote:

> 
> 
> Am 25.06.2018 um 05:39 schrieb Paul Kosinski:
> > Is it possible to get BIND not to respond at all, thereby causing
> > a timeout on the query? That would perhaps reduce load more than
> > NXDOMAIN or deleting the sone(s) would.
> 
> timeouts are expensive for both sides by definition
> 
> > On Mon, 25 Jun 2018 00:03:09 +0200
> > jo...@hasig.de wrote:
> > 
> >> yes, but it minimizes the use of resources because the only answer
> >> is nxdomain. j.
> >>
> >> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> >>> In article ,
> >>>   jo...@hasig.de wrote:
> >>>
> >>>> hi,
> >>>> why dont you just delete the zones?
> >>>
> >>> That won't stop the queries from coming to the server
> 
> 
___
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: Stopping name server abuse

[Paul Kosinski]

Is it possible to get BIND not to respond at all, thereby causing
a timeout on the query? That would perhaps reduce load more than
NXDOMAIN or deleting the sone(s) would.


On Mon, 25 Jun 2018 00:03:09 +0200
jo...@hasig.de wrote:

> yes, but it minimizes the use of resources because the only answer is
> nxdomain. j.
> 
> Am 24.06.2018 um 23:41 schrieb Barry Margolin:
> > In article ,
> >   jo...@hasig.de wrote:
> > 
> >> hi,
> >> why dont you just delete the zones?
> > 
> > That won't stop the queries from coming to the server.
___
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: DNSSEC and nsupdate

[Paul Kosinski]

Setting the permissions of a *private* key to 0644 sounds like a bad
idea. Maybe you mean 0640?


On Fri, 2 Mar 2018 23:28:28 +
"Prof. Dr. Michael Schefczyk"  wrote:

> Dear Mark,
> 
> I did get the issue resolved while setting up a test environment.
> 
> The issue is that normal permissions in the key-directory are
> root:bind 0644 for the public key and root:bind 0600 for the private
> key. The issue disappears when setting the private key to 0644 also
> and that must be done before starting bind - before using nsupdate is
> not enough.
> 
> Do you know if these permissions are standard or a consequence of
> starting DNSSEC via webmin?
> 
> Test setup - BIND 9.10.3-P4-Debian stretch:
> 
> /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> include "/etc/bind/named.conf.log";
> key rndc-key {
>   algorithm hmac-md5;
>   secret "ctHOTtudBPhdKIgaC2baPA==";
>   };
> key nsupdate {
>   algorithm HMAC-SHA512;
>   secret
> "E0tzjpBzrcpGiZwmlqsE86hTzI2UAXNlm/pRNl2blZaze4Edn7vSHWP6
> 14gmwKKXYQPKHwnG83HTWURbqRykMQ=="; }; controls {
>   inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys
> { rndc-key; }; };
> 
> /etc/bind/named.conf.options
> options {
>   directory "/var/cache/bind";
>   dnssec-validation auto;
> 
>   auth-nxdomain no;# conform to RFC1035
> allow-recursion { any; };
> };
> 
> /etc/bind/named.conf.local
> zone "testzone.com" {
>   type master;
>   file "/var/lib/bind/testzone.com.hosts";
> update-policy  { grant nsupdate zonesub TXT; };
> key-directory "/var/lib/bind";
> auto-dnssec maintain;
>   };
> 
> Regards,
> 
> Michael Schefczyk
> 
> -Ursprüngliche Nachricht-
> Von: Mark Andrews [mailto:ma...@isc.org] 
> Gesendet: Montag, 26. Februar 2018 01:57
> An: Prof. Dr. Michael Schefczyk 
> Cc: bind-users@lists.isc.org
> Betreff: Re: DNSSEC and nsupdate
> 
> 
> > On 26 Feb 2018, at 8:12 am, Prof. Dr. Michael Schefczyk
> >  wrote:
> > 
> > Dear Mark,
> > 
> > Thank you very much! No, chroot is not involved. Package
> > debootstrap (required for chroot as far as I understand) is not
> > even installed.
> > 
> > It would be great to understand, what the error message:
> > 
> > warning: dns_dnssec_findzonekeys2: error reading private key file 
> > fqdn/ECDSAP384SHA384/41844: file not found
> > 
> > really means. One does specify the key directory. Does the error
> > message imply, that the key directory should have as many levels of
> > subdirectories as the error message contains slashes? In the lowest
> > directory level, how would a key file need to be named. Not the old
> > convention of K[fqdn]+number+keyid.key or .private anymore?
> 
> No that hasn’t changed.
> 
> error reading private key file fqdn/ECDSAP384SHA384/41844
> 
> is short hand for
> 
> error reading private key file for ‘fqdn' with algorithm
> ECDSAP384SHA384 and key id 41844.
> 
> At this stage I suggest that you post actual config details and
> actual command lines rather than describing what you have done as the
> error will be in the details which we can’t see without them.
> 
> > Regards,
> > 
> > Michael
> > 
> > Technische Universität Dresden
> > Fakultät Wirtschaftswissenschaften
> > Lehrstuhl für Entrepreneurship und Innovation Prof. Dr. Michael 
> > Schefczyk
> > D-01062 Dresden
> > 
> > Fon: +49-3 51-4 63-3 68 81
> > Fax: +49-3 51-4 63-3 68 83
> > www.gruenderlehrstuhl.de
> > 
> > 
> > 
> > 
> > Are you running chrooted? Did you make the keys visible in the
> > chroot area?
> > 
> > 
> >> On 25 Feb 2018, at 2:37 am, Prof. Dr. Michael Schefczyk
> >>  wrote:
> >> 
> >> Dear All,
> >> 
> >> For a long time already, I am using a bind master DNS server based
> >> on debian set up via webmin. It is currently Debian Stretch with
> >> bind 9.10. I am using DNSSEC.
> >> 
> >> The  webmin setup leads to all keys being stored in /var/lib/bind.
> >> The naming scheme is K[fqdn]+number+keyid.key or .private. There
> >> is one key-signing key and one zone-signing key for each fqdn.
> >> Resigning works via a perl srcipt / cronjob shipped by webmin.
> >> 
> >> To be able to generate future letsencrypt wildcard certificates, I
> >> would like to implant acme challenges as TXT records via DNS.
> >> Using nsupdate, the dnssec signing becomes troublesome. The error
> >> message in update_debug.log is:
> >> 
> >> Date/Time info: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': adding an RR at '_acme-challenge.fqdn' TXT "..."
> >> Date/Time error: client IP#36210/key nsupdate: updating zone
> >> 'fqdn/IN': found no active private keys, unable to generate any
> >> signatures Date/Time error: client IP#36210/key nsupdate: updating
> >> zone 'fqdn/IN': RRSIG/NSEC/NSEC3 update failed: not found
> >> 
> >> Looking 

Re: DNS performance Help when query log is off -- which default parameters will impact the DNS performance

[Paul Kosinski]

Google search for "man named" turns up:

  https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/man.named.html

which says (among more details):

  named [-4] [-6] [-c config-file] [-d debug-level] [-E engine-name] [-f]
[-g] [-M option] [-m flag] [-n #cpus] [-p port] [-s] [-S #max-socks]
[-t directory] [-U #listeners] [-u user] [-v] [-V] [-x cache-file]

For more explanation, look at:

  
https://kb.isc.org/article/AA-01249/0/UDP-Listeners-choosing-the-right-value-for-U-when-starting-named.html



On Thu, 22 Feb 2018 01:50:22 +
"PENG, JUNAN"  wrote:

> Hi, Paul
> 
> UDP listeners per interface
> 
> Do you know how to modify this parameter -- UDP listeners per
> interface
> 
> version: BIND 9.10.5-S1  (Unknown)
> boot time: Tue, 13 Feb 2018 06:12:53 GMT
> last configured: Tue, 13 Feb 2018 06:12:53 GMT
> CPUs found: 4
> worker threads: 4
> UDP listeners per interface: 3
> number of zones: 102
> debug level: 0
> xfers running: 0
> xfers deferred: 0
> soa queries in progress: 0
> query logging is OFF
> recursive clients: 0/900/1000
> tcp clients: 0/15000
> server is up and running
> 
> BR
> Michael
___
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: DNS performance Help when query log is off -- which default parameters will impact the DNS performance

[Paul Kosinski]

Could it be that you're network limited?

In any case, the values of the following parameters may be illuminating
(they may be obtained via "rndc status").

  CPUs found
  worker threads
  UDP listeners per interface

For example, my very lightly loaded authoritative server reports:

  version: BIND 9.10.6  (Not currently available)
  boot time: Fri, 12 Jan 2018 23:49:54 GMT
  last configured: Wed, 21 Feb 2018 05:00:02 GMT
  CPUs found: 4
  worker threads: 4
  UDP listeners per interface: 3
  number of zones: 4
  debug level: 0
  xfers running: 0
  xfers deferred: 0
  soa queries in progress: 0
  query logging is ON
  recursive clients: 0/0/1000
  tcp clients: 0/100
  server is up and running

--

On Wed, 21 Feb 2018 20:59:16 +
"PENG, JUNAN"  wrote:

> Hi, Tony
> 
> During my performance test,  I also tested the performance without
> query logs.  I disabled the query log feature , but  it seemed that
> QPS  couldn't  go higher (about 75KQPS)  when CPU still had lots of
> room  --  Named CPU Usage was about 250%,  but in theory  it can
> reach to 400% (4 vCPU).
> 
> 
> In your opinion,  which default parameters I need pay attention to ,
> which will impact system capacity performance when query log is off?
> 
> 
> Our Bind version is 9.10.5.  Do you know what version you think will
> have better multi-threading ?
> 
> 
> Thank you very much!
> 
> Michael
> 
> -Original Message-
> From: PENG, JUNAN 
> Sent: Wednesday, February 21, 2018 11:32 AM
> To: 'Tony Finch' 
> Subject: RE: Help 
> 
> Another thing:
> 
> When query log is on.
> 
> Traffic is 35k QPS,   the Named CPU usage is 260%
> Traffic is 40K QPS,  the Named CPU usage is 260% Traffic is 50K QPS,
> the Named CPU usage is 260% Traffic is 70 -100 KQPS, the named CPU
> usage is still 260% 
> 
> When the named CPU usage has a limitation 260% here ? (in theory, it
> should be 400%)
> 
> BR
> Michael
> 
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
> Sent: Wednesday, February 21, 2018 11:09 AM
> To: PENG, JUNAN 
> Cc: bind-users@lists.isc.org
> Subject: Re: Help 
> 
> PENG, JUNAN  wrote:
> >
> > Why Query log off/on  feature is impacting named CPU Usage ?
> 
> It has to serialize query processing in order to write to the log,
> and that serialization barrier limits the parallelism that it can
> achieve (due to Amdahl's law).
> 
> Tony.
___
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: SOA settings

[Paul Kosinski]

Speaking of units, University of Chicago Professor Nicholas Metropolis
(who had been one of the original Manhattan Project scientists at Los
Alamos) remarked that the standard lecture period of 50 minutes lasted
approximately 1 Micro-Century.


On Fri, 2 Feb 2018 17:00:10 -0500
Warren Kumari  wrote:

> On Fri, Feb 2, 2018 at 3:31 PM, Dave Warren  wrote:
> > On Fri, Feb 2, 2018, at 11:57, Warren Kumari wrote:
> >> Hopefully Lewis knows / understand that we are just squabbling
> >> amongst ourselves because we've know each other for a long time
> >> and this is in good humor.
> >
> > Yes indeed :)
> >
> >> The actual values used are open to tuning, but in the original
> >> posting, you, that was 15 seconds, and was *probably* a typo for 15
> >> minutes. I personally always use seconds in my zonefiles, and avoid
> >> the new fangled hours / weeks / syntax.
> >
> > I'm the exact other way around, I prefer content to be as human
> > readable as possible, and in my experience most humans work better
> > with smaller numbers including units (especially under
> > stress/pressure).
> 
> What?! You mean you still think in archaic units like hours and laghu
> and days and fortnights and similar?! Weird Do you measure length
> in alen? Or kyndemil?
> 
> I use seconds for *everything* -- when pointy-haired boss types ask if
> I'm actually working on a project (instead of, you know, snarking on
> mailing lists) I tell them that I've put in "more than 2834 seconds in
> the past 2 weeks alone". The arbitrary precision and large number
> makes it sound like I've done way more than, you know, less than an
> hour.
> 
> It only takes a few 2678400 seconds to get into this habit - if you
> are having a hard time adjusting, I'd recommend Kris Allen's seminal
> work - https://www.youtube.com/watch?v=PwYnG2DGbPo   [0] - this is
> only the first in a planned series; IIRC, the next one will cover the
> number of seconds needed to cook an egg to the desired yolk
> consistency, and the following one, for some unknown reason, helps you
> remember the gestation period of a muskrat.
> 
> >
> > Each to their own, obviously.
> >
> 
> Apparently.
> W
> P.S: You are welcome for the earworm.
> 
> 
> 
___
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: Zone give from one second to another error...

[Paul Kosinski]

Michelle (and others who may be interested),

I have found mxtoolbox.com to be helpful in diagnosing DNS and related
problems. It is able do all kinds of DNS lookups from *outside* your
domain so you can see what your normal Internet users see. It will do
basic stuff (manually initiated) for free, and will do continual
(automated) monitoring if you pay them.


On Sun, 24 Dec 2017 07:57:08 +0200
Michelle Konzack  wrote:

> Hello Harald,
> 
> On 2017-12-24 06:26:03 Reindl Harald hacked into the keyboard:
> > https://intodns.com/24v-technic.info
> 
> This site is realy cool!
> 
> However...
> 
> > Nameserver records returned by the parent servers are:
> > dns3.tamay-dogan.net.   ['78.47.247.21'] (NO GLUE)   [TTL=86400]
> > dns2.tamay-dogan.net.   ['217.147.94.23'] (NO GLUE)   [TTL=86400]
> > dns1.tamay-dogan.net.   ['78.47.104.44'] (NO GLUE)   [TTL=86400]
> 
> ...can you explain me the thing with the GLUE?
> I do not understand this.
> How to GLUE someting?
> 
> Note:   will be removed soon, as I migrate my servers  to
> Estonia and will be reenabled as  which is  much
> shorter. I have only to convince my Registrar, that I need more then
> three DNS in the setup (this is currently a technical limitation
> @ISP).
> 
>Also 2 additional MX will be re-added...
> 
>Unfortunately I have not gotten bind9 running with PostgreSQL
> yet which is realy annoying.
> 
> Thanks
> 
___
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 algorithm in DNS

[Paul Kosinski]

I don't call *everything* a search, but I would claim that any
practical mapping of a relatively sparse set of keys into values in
another set would require a search at some point. Only direct indexing
of sub-sequences of characters in domain names into sub-trees whose
eventual leaves were IP addresses would not involve at least simple
searches (such as in B-trees). And such trees with fully branching --
index-only, no search required -- nodes would tend asymptotically to
take exponential storage space.

(This behavior might be somewhat mitigated by the fact that domain
names are not random strings of characters, but rather follow certain
linguistic statistics.)


On Thu, 9 Nov 2017 17:56:03 +0100
Reindl Harald <h.rei...@thelounge.net> wrote:

> 
> 
> Am 09.11.2017 um 15:55 schrieb Paul Kosinski:
> > Exact matching needs a search algorithm too
> 
> no it don't - unless you call everything "search"
> https://en.wikipedia.org/wiki/Hash_table
> 
> > On 9 Nov 2017 02:28:48 -
> > "John Levine" <jo...@iecc.com> wrote:
> > 
> >> In article <mailman.21.1510187088.749.bind-us...@lists.isc.org> you
> >> write:
> >>> -=-=-=-=-=-
> >>>
> >>> I am Munkhbaatar, a master course student studying on mechanism
> >>> and algorithm of DNS.I want to search algorithm in DNS, but i
> >>> have not found the documents clearly explaining this on the web.I
> >>> guess it's just a "list search", but I am not sure.Please tell me
> >>> the details of the search algorithm.
> >>
> >> There is no search algorithm, only exact match.  See RFCs 1034,
> >> 1035, and 2181

___
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 algorithm in DNS

[Paul Kosinski]

Exact matching needs a search algorithm too.

If the DNS server in only authoritative for a couple of domains (and
subdomains), a simple linear search would be adequate (or even optimal,
due to its low overhead). Many DNS servers, however, are authoritative
for multiple domains, and so might need something like a binary search
or hash table.

Reverse DNS (PTR resolution) could also need a similar algorithm, as an
ISP's server could easily cover a lot of disparate domains with its
block of assigned IP addresses. (Although the IP address, being part of
a dense range, could be converted to an index number, I suppose.)


On 9 Nov 2017 02:28:48 -
"John Levine"  wrote:

> In article  you
> write:
> >-=-=-=-=-=-
> >
> >I am Munkhbaatar, a master course student studying on mechanism and
> >algorithm of DNS.I want to search algorithm in DNS, but i have not
> >found the documents clearly explaining this on the web.I guess it's
> >just a "list search", but I am not sure.Please tell me the details
> >of the search algorithm. 
> 
> There is no search algorithm, only exact match.  See RFCs 1034, 1035,
> and 2181.
> 
> R's,
> John
___
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: Different forwarder for certain response ip (result ip )

[Paul Kosinski]

Maybe he has no say in what ISP is used, and they have draconian policies...


On Sat, 16 Sep 2017 19:48:51 +0200
Matus UHLAR - fantomas  wrote:

> . . .
> >Note:1.2.3.4 is not what they really return . I've changed it for
> >privacy .
> 
> why? it's your ISP, there's no need to hide IP they send to you...
> it's not your privacy, is it?
> 
> >But it is one fixed ip address which returns in case of manipulation
> >occurs
> 
> I think you could translate that IP to NXDOMAIN using RPZ.
> 
> btw, dnsmasq has "bogus-nxdomain" option for this. When you forward
> togoogle, you could use dnsmasq as well.
___
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: make AAAA type the default for dig

[Paul Kosinski]

Has IPv4 faded away and I didn't notice? Unlike the well planned switch
to Area Codes, IPv6 is not backward compatible.

(The telcos would have gotten rather a lot of complaints if they said
every had to get a new telephone number, and also -- new telephones.)


On Wed, 14 Jun 2017 22:10:25 +1000
Mark Andrews  wrote:

> 
> In message , "Marco
> Davids (SIDN)" writes:
> > Hi,
> >
> > Not sure if this has been proposed before, but I am wondering:
> >
> > Has ISC ever considered to change the default 'dig -t' option from
> > A to ?
> >
> > --
> > Marco
> 
> This would break too many scripts.  You can do this for yourself
> by setting the type in $HOME/.digrc
> 
> % cat ~/.digrc
> -t 
> % dig isc.org
> ;; BADCOOKIE, retrying.
> 
> ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> isc.org
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1235
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL:
> 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 3ababe63d14205ae8cec9f7659412776a8b43cb46b335466 (good)
> ;; QUESTION SECTION:
> ;isc.org. IN  
> 
> ;; ANSWER SECTION:
> isc.org.  6   IN  
> 2001:4f8:0:2::69
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Jun 14 22:09:26 AEST 2017
> ;; MSG SIZE  rcvd: 92
> 
> % 
> 
___
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: Tuning suggestions for high-core-count Linux servers

[Paul Kosinski]

It's been some years now, but I had worked on developing code for a high
throughput network server (not BIND). We found that on multi-socketed
NUMA machines we could have similar contention problems, and it was
quite important to make sure that threads which needed access to the
same memory areas weren't split across sockets. Luckily, the various
services being run were sufficiently separate that we could assign the
service processes to different sockets and avoid a lot of contention.

With BIND, it's basically all one service, so this is not directly
possible. 

It might be possible, however, to run two (or more) *separate*
instances of BIND and do some strictly internal routing of the IP
traffic to those separate instances, or even to have separate NICs
feeding the separate processes. In other words, have several BIND
servers in one chassis, each with its own NUMA memory area.



On Fri, 2 Jun 2017 07:12:09 +
"Browne, Stuart"  wrote:

> Just some interesting investigation results. One of the URL's Matthew
> Ian Eis linked to talked about using a tool called 'perf'. For the
> hell of it, I gave it a shot.
> 
> Sure enough it tells some very interesting things.
> 
> When BIND was restricted to using a single NUMA node, the biggest
> call (to _raw_spin_lock) showed 7.05% overhead.
> 
> When BIND was allowed to use both NUMA nodes, the same call showed
> 49.74% overhead; an astonishing difference.
> 
> As it was running unrestricted, memory from both nodes was more used:
> 
> [root@kr20s2601 ~]# numastat -p 22441
> 
> Per-node process memory usage (in MBs) for PID 22441 (named)
>Node 0  Node 1   Total
>   --- --- ---
> Huge 0.000.000.00
> Heap 0.450.120.57
> Stack0.710.641.35
> Private  5.28 9415.30 9420.57
>   --- --- ---
> Total6.43 9416.07 9422.50
> 
> Given the numbers here, you wouldn't think it should make much of a
> difference.
> 
> Sadly, I didn't get which CPU the UDP listener was attached to.
> 
> Anyway, what I've changed so far:
> 
> vm.swappines = 0
> vm.dirty_ratio = 1
> vm.dirty_background_ratio = 1
> kernel.sched_min_granularity_ns = 1000
> kernel.sched_migration_cost_ns = 500
> 
> Query rate thus far reached (on 24 cores, numa node restricted): 426k
> qps Query rate thus far reached (on 48 cores, numa nodes
> unrestricted): 321k qps
> 
> Stuart
> 
> 'perf' data collected during a 3 minute test run:
> 
> [root@kr20s2601 ~]# ls -al perf.data*
> -rw---. 1 root root  717350012 Jun  2 08:36 perf.data.24
> -rw---. 1 root root 1366620296 Jun  2 08:53 perf.data.48
> 
> 'perf' top 5 (24 cores, numa restricted):
> 
> Overhead  Command  Shared Object Symbol
>7.05%  named[kernel.kallsyms] [k] _raw_spin_lock
>6.96%  namedlibpthread-2.17.so[.] pthread_mutex_lock
>3.84%  namedlibc-2.17.so  [.] vfprintf
>2.36%  namedlibdns.so.165.0.7 [.] dns_name_fullcompare
>2.02%  namedlibisc.so.160.1.2 [.] isc_log_wouldlog
> 
> 'perf' top 5 (48 cores):
> 
> Overhead  Command  Shared Object Symbol
>   49.74%  named[kernel.kallsyms] [k] _raw_spin_lock
>4.52%  namedlibpthread-2.17.so[.] pthread_mutex_lock
>3.09%  namedlibisc.so.160.1.2 [.] isc_log_wouldlog
>1.84%  named[kernel.kallsyms] [k] _raw_spin_lock_bh
>1.56%  namedlibc-2.17.so  [.] vfprintf
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Slow zone signing with ECDSA

[Paul Kosinski]

"The tinfoil hat brigade in some distributions has resisted using them,
fearing some conspiracy to provide not-so-random numbers."

I think the NSA *did*, in fact, compromise the "Dual Elliptic Curve
Deterministic Random Bit Generator" and paid RSA to make it the default
in one of their products -- https://en.wikipedia.org/wiki/Dual_EC_DRBG.


On Wed, 19 Apr 2017 22:09:28 -0400
Timothe Litt  wrote:

> 
> On 19-Apr-17 21:43, Mark Andrews wrote:
> > ...
> > DSA requires random values as part of the signing process.  Really
> > all CPU's should have real random number sources built into them
> > and new genuine random values should only be a instruction code
> > away.
> >
> > Mark
> Most recent ones do.  See RDRAND for Intel (and AMD).  Even Raspberry
> Pi.
> 
> The tinfoil hat brigade in some distributions has resisted using them,
> fearing some conspiracy to provide not-so-random numbers.  (Despite
> the fact that /dev/random hashes/whitens the inputs to the entropy
> pool.) You may need to take a positive action to enable use of the
> hardware source.  Google RDRAND for plenty of entertainment.
> 
> There are also fairly inexpensive (~usd 50) USB devices that provide
> reasonable entropy quality at decent speeds.  (But much lower than
> RDRAND.)  They're good for the old hardware that you recycle for
> single-purpose servers.
> 
> Systems that have low activity/low entropy can benefit from
> entropybroker (https://www.vanheusden.com/entropybroker/).  Use it to
> distribute entropy from those who have to those who don't.  It's
> really handy for VMs, and for that isolated system that you use for
> your root keys.
> 
> For most uses, use /dev/urandom - which doesn't block.  /dev/random
> will block if the entropy pool is depleted.  (However, if you have a
> hardware source, very, very rarely.)  /dev/random is recommended for
> long lived keys - which usually includes KSKs, and may include ZSKs.
> I don't believe named makes a distinction...you get to pick one for
> everything.
> 
> Timothe Litt
> ACM Distinguished Engineer
> --
> This communication may not represent the ACM or my employer's views,
> if any, on the matters discussed. 
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: BIND 9 windows XP builds

[Paul Kosinski]

I would think that a Internet-connected box that is severely
compromised (e.g., has malware running with maximal privileges) is
about as bad as having the LAN that the box is on connected to the
Internet directly (without a Firewall etc.).

In particular, such a box could be remote controlled to attack XP in
whatever way XP is vulnerable to attacks from the Internet at large.


On Tue, 18 Apr 2017 22:58:47 +
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> I guess I'm not so worried about a non-Internet-connected Windows XP
> box forwarding to an Internet-connected box that's running a modern
> (preferably non-Windows) OS. Assuming that the BIND versions are
> patched up to date, of course.
> 
> To be sure, all things must come to end, and XP support for BIND is
> no exception. But, the risk calculation runs something like: is there
> still enough critical mass of BIND-on-XP out there that there is a
> *bigger* risk incurred by no longer incorporating new security
> updates, or, has the population dwindled to the point where *only*
> the withdrawal of support will get the remainder to
> upgrade/replace/refresh their XP boxes?
> 
>   
> -
> Kevin
> 
> 
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf
> Of Paul Kosinski Sent: Tuesday, April 18, 2017 5:09 PM
> To: bind-users@lists.isc.org
> Subject: Re: BIND 9 windows XP builds
> 
> Yes, I suppose not every machine running BIND is connected to the
> Internet. But how many are network inaccessible to every machine that
> *is* connected to the Internet and might be compromised?
> 
> We run a local BIND for our LAN to avoid HOSTS files, but that same
> machine is connected to the Internet -- and runs a different instance
> of BIND to be authoritative for our domain. (No, not a separate
> machine, it's a very small installation.)
> 
> So, how many BINDs are completely isolated from the Internet, even
> under transitive closure of the internal network? It's surely a
> proper subset of all instances of BIND, but I doubt if it's other
> than a quite small subset.
> 
> 
> On Tue, 18 Apr 2017 17:22:24 +
> "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:
> 
> > Unspoken and false assumption: that every machine running BIND is 
> > connected to the Internet.
> > 
> > I'm no fan of old, broken Microsoft OSes (or even the newer ones,
> > for that matter), but let's be clear here: BIND is for anyone who
> > doesn't want to maintain a "hosts" file. "Connected to the
> > Internet" is a much smaller subset of *that* set.
> > 
> > - Kevin
> > 
> > -Original Message-
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On
> > Behalf Of Paul Kosinski Sent: Monday, April 17, 2017 9:08 PM
> > To: bind-users@lists.isc.org
> > Subject: Re: BIND 9 windows XP builds
> > 
> > I can see somebody running XP for some "legacy" software that
> > doesn't run nicely on newer versions of Windows, but I would think
> > it extremely risky to have such a machine connected to the Internet.
> > 
> > Maybe whoever runs BIND on XP should consider converting that
> > machine to Linux, and running BIND on Linux?
> > 
> > 
> > On Mon, 17 Apr 2017 20:30:43 +
> > Evan Hunt <e...@isc.org> wrote:
> > 
> > > Greetings,
> > > 
> > > For some time ISC has been providing three Windows builds for
> > > each release of BIND 9: x64, win32, and windows XP.
> > > 
> > > Windows XP is well past its end of life and is no longer
> > > receiving security updates.  I'd like to stop supporting it after
> > > the upcoming maintenance release, but it's been pointed out to me
> > > that a significant number of people -- many thousands -- are
> > > downloading the XP version every time we put out a new release.
> > > 
> > > This information surprised me. If you're one of those people,
> > > would you mind responding, either on or off the list, to discuss
> > > it?  Why are you using XP to run a name server?  Is it possible
> > > you're still using the XP build out of inertia, but your OS would
> > > work equally well with the win32 build?  If you're really still
> > > running XP, do you have a plan for transitioning to something
> > > newer?
> > > 
> > > We want to support the needs of our users, but to do that we have
> > > to understand those needs, so please let us know what yours are.
> > > Thanks,
> > > 
> > > --
> > > Evan Hunt -- e...@isc.org
> > > Internet Systems Consortium, Inc.

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

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

Re: BIND 9 windows XP builds

[Paul Kosinski]

Yes, I suppose not every machine running BIND is connected to the
Internet. But how many are network inaccessible to every machine that
*is* connected to the Internet and might be compromised?

We run a local BIND for our LAN to avoid HOSTS files, but that same
machine is connected to the Internet -- and runs a different instance of
BIND to be authoritative for our domain. (No, not a separate machine,
it's a very small installation.)

So, how many BINDs are completely isolated from the Internet, even
under transitive closure of the internal network? It's surely a proper
subset of all instances of BIND, but I doubt if it's other than a quite
small subset.


On Tue, 18 Apr 2017 17:22:24 +
"Darcy Kevin (FCA)" <kevin.da...@fcagroup.com> wrote:

> Unspoken and false assumption: that every machine running BIND is
> connected to the Internet.
> 
> I'm no fan of old, broken Microsoft OSes (or even the newer ones, for
> that matter), but let's be clear here: BIND is for anyone who doesn't
> want to maintain a "hosts" file. "Connected to the Internet" is a
> much smaller subset of *that* set.
> 
>   - Kevin
> 
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf
> Of Paul Kosinski Sent: Monday, April 17, 2017 9:08 PM
> To: bind-users@lists.isc.org
> Subject: Re: BIND 9 windows XP builds
> 
> I can see somebody running XP for some "legacy" software that doesn't
> run nicely on newer versions of Windows, but I would think it
> extremely risky to have such a machine connected to the Internet.
> 
> Maybe whoever runs BIND on XP should consider converting that machine
> to Linux, and running BIND on Linux?
> 
> 
> On Mon, 17 Apr 2017 20:30:43 +
> Evan Hunt <e...@isc.org> wrote:
> 
> > Greetings,
> > 
> > For some time ISC has been providing three Windows builds for each 
> > release of BIND 9: x64, win32, and windows XP.
> > 
> > Windows XP is well past its end of life and is no longer receiving 
> > security updates.  I'd like to stop supporting it after the
> > upcoming maintenance release, but it's been pointed out to me that
> > a significant number of people -- many thousands -- are downloading
> > the XP version every time we put out a new release.
> > 
> > This information surprised me. If you're one of those people, would 
> > you mind responding, either on or off the list, to discuss it?  Why 
> > are you using XP to run a name server?  Is it possible you're still 
> > using the XP build out of inertia, but your OS would work equally
> > well with the win32 build?  If you're really still running XP, do
> > you have a plan for transitioning to something newer?
> > 
> > We want to support the needs of our users, but to do that we have
> > to understand those needs, so please let us know what yours are.
> > Thanks,
> > 
> > --
> > Evan Hunt -- e...@isc.org
> > Internet Systems Consortium, Inc.

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

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

Re: BIND 9 windows XP builds

[Paul Kosinski]

I can see somebody running XP for some "legacy" software that doesn't
run nicely on newer versions of Windows, but I would think it extremely
risky to have such a machine connected to the Internet.

Maybe whoever runs BIND on XP should consider converting that machine to
Linux, and running BIND on Linux?


On Mon, 17 Apr 2017 20:30:43 +
Evan Hunt  wrote:

> Greetings,
> 
> For some time ISC has been providing three Windows builds for each
> release of BIND 9: x64, win32, and windows XP.
> 
> Windows XP is well past its end of life and is no longer receiving
> security updates.  I'd like to stop supporting it after the upcoming
> maintenance release, but it's been pointed out to me that a
> significant number of people -- many thousands -- are downloading the
> XP version every time we put out a new release.
> 
> This information surprised me. If you're one of those people, would
> you mind responding, either on or off the list, to discuss it?  Why
> are you using XP to run a name server?  Is it possible you're still
> using the XP build out of inertia, but your OS would work equally
> well with the win32 build?  If you're really still running XP, do you
> have a plan for transitioning to something newer?
> 
> We want to support the needs of our users, but to do that we have to
> understand those needs, so please let us know what yours are.  Thanks,
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
> ___
> 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

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

Re: Bind Queries log file format

[Paul Kosinski]

"I’ve been around long enough to remember when upward compatibility was
something that was expected."

Having been around since before even Unix, I must say I agree totally.

As I understand it, Linus does not take kindly to Linux Kernel changes
that break forward/upward compatibility (of the ABI). I don't think BIND
should do any less.

If a new format is needed for more extensive logging, then add a new
log option (just as new Kernel interfaces are added from time to time).


On Tue, 7 Feb 2017 22:25:36 -0600
Larry Stone  wrote:

> I’ve been around long enough to remember when upward compatability
> was something that was expected. A program built to work with the
> current version of data (e.g. data records, log records, whatever) or
> even a shared library was expected to be able to continue to work
> with all future versions without the need for changes or
> rebuilding/recompiling. For data, that meant new fields went on the
> end of the record so that anything expecting the old format still
> found everything where it always was and the new stuff was at the end
> of the record where the old programs never even looked. But sadly,
> this appears to be a lost art these days.
> 
> Where I work, we have a data set that has 20 years of data in it.
> Over the years, the record length was extended but once a field was
> placed at a given point in the record, it never, ever moved so that
> programs written years ago that had no need for the new fields still
> ran just fine. And with hundreds if not thousands of programs around
> the company that read this data set, insuring that format changes did
> not break things was a very high priority. Occasionally, fields went
> away in which case that spot in the record was just left blank for
> all new records.
> 
> For the BIND log records described below, what I describe appears to
> be what was done through 9.10.0. But then at 9.11.0, we have a field
> in the middle of the record being changed (EDNS changed to
> EDNS+version). What, IMHO, should have been done here was to put the
> version on the end (either going with a split filed - EDNS in one
> place and the version in another or by duplicating EDNS by having it
> without version where it was and then again with version on the end
> of the record) so that old programs parsing the log file still
> worked. So instead of:
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO,
> > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed,
> > EDNS + version, TCP, DO, CD, cookies, local address 9.12.0: client,
> > qname, qclass, qtype, RD, signed, EDNS + version, TCP, DO, CD,
> > cookies, local address, ecs
> 
> 
> it should have been
> > 9.10.0: client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO,
> > CD, local address 9.11.0: client, qname, qclass, qtype, RD, signed,
> > EDNS, TCP, DO, CD, cookies, local address, EDNSversion 9.12.0:
> > client, qname, qclass, qtype, RD, signed, EDNS, TCP, DO, CD,
> > cookies, local address, EDNSversion, ecs
> 
___
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: Forwarding via different external networks

[Paul Kosinski]

"... whatever else you use to failover from the primary to the
secondary would automatically ensure BIND resolves too."

That's the root of the problem: there is no automatic failover, and
providing one is a lot of work. I was hoping there was a simple BIND
config option so that BIND itself could fail-over the DNS lookups and
solve the immediate problem.


On Sat, 27 Aug 2016 23:29:08 -0700
Dave Warren <da...@hireahit.com> wrote:

> On Sat, Aug 27, 2016, at 11:32, Paul Kosinski wrote:
> > So my question is, is it possible to configure my forwarding BIND to
> > have a primary and *secondary* path for sending out DNS queries? As
> > far as I can tell, the "query-source address" option in named.conf
> > only allows one outbound interface to be (implicitly) specified,
> > and I don't want to leave the outbound interface unspecified as
> > that would defeat monitoring and logging on the specific interface.
> > The "forwarders" option *does* allow multiple DNS servers to be
> > specified, but that doesn't help if the network path is down.
> > 
> > P.S. I suppose I might try something with policy routing, but that
> > was already a nightmare to set up, since I use DSL vs cable based
> > on the source and type (e.g. HTTP, SSH) of the traffic rather than
> > the more common destination.
> 
> Since you're forwarding anyway, why not forward to a pair of public
> servers, 8.8.8.8 and 8.8.4.4, or 4.2.2.1 and 4.2.2.2, and then use
> youe routing table or other technique to route traffic for each
> destination IP?
> 
> However, since you run BIND, why bother with forwarding queries at
> all, I would recommend just resolving without forwarders, in which
> case BIND doesn't need any particular connection and whatever else
> you use to failover from the primary to the secondary would
> automatically ensure BIND resolves too.

___
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: Forwarding via different external networks

[Paul Kosinski]

"Your better bet is surely to dump the forwarders and to do your own 
recursion."

It doesn't solve the connectivity issue, but it sounds reasonable in
it's own right: I'll have to try it.


On Sat, 27 Aug 2016 14:32:09 -0500
/dev/rob0 <r...@gmx.co.uk> wrote:

> On Sat, Aug 27, 2016 at 02:32:42PM -0400, Paul Kosinski wrote:
> > Currently, I forward all outbound DNS via the DSL to the ISP's
> > DNS servers. (I have more confidence in the DSL provider not 
> > interfering with DNS than in Comcast.)
> 
> FWIW, it has been many years since I have dealt with Comcast as a 
> customer, but I can tell you for sure that Comcast employs some very 
> clueful DNS experts.
> 
> > However, there have been a couple of cases recently when the DSL 
> > was not getting beyond their gateway router, which meant that DNS 
> > would fail, causing much HTTP(S) to fail even though the cable 
> > network was working quite nicely.
> > 
> > So my question is, is it possible to configure my forwarding BIND 
> > to have a primary and *secondary* path for sending out DNS queries?
> 
> Your better bet is surely to dump the forwarders and to do your own 
> recursion.
___
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

Forwarding via different external networks

[Paul Kosinski]

I have a rather unusual network with a gateway machine that connects to
two ISPs: a slower DSL with a static IP and a faster cable (Comcast)
with a DHCP IP. The gateway machine runs two instances of BIND (plus
the usual firewalling): an authoritative one for a couple of domains
(and only those domains!), and a forwarding-only one for use by internal
clients (to reduce external DNS requests via the usual caching that
BIND provides).

Currently, I forward all outbound DNS via the DSL to the ISP's DNS
servers. (I have more confidence in the DSL provider not interfering
with DNS than in Comcast.) However, there have been a couple of cases
recently when the DSL was not getting beyond their gateway router,
which meant that DNS would fail, causing much HTTP(S) to fail even
though the cable network was working quite nicely.

So my question is, is it possible to configure my forwarding BIND to
have a primary and *secondary* path for sending out DNS queries? As far
as I can tell, the "query-source address" option in named.conf only
allows one outbound interface to be (implicitly) specified, and I don't
want to leave the outbound interface unspecified as that would defeat
monitoring and logging on the specific interface. The "forwarders"
option *does* allow multiple DNS servers to be specified, but that
doesn't help if the network path is down.

P.S. I suppose I might try something with policy routing, but that was
already a nightmare to set up, since I use DSL vs cable based on the
source and type (e.g. HTTP, SSH) of the traffic rather than the more
common destination.
___
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: how to log client MAC address?

[Paul Kosinski]

If the client is at all remote (i.e. the request passes through a
router), the MAC address isn't preserved.


On Sat, 6 Aug 2016 17:42:59 -0700
Fima Leshinsky  wrote:

> I'd like to log the client's MAC address. Is this possible? Could
> someone point me in the right direction?
> 
> Thank you!
> Fima
___
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: outgoing-traffic

[Paul Kosinski]

I thought port 0 was never valid as either source or destination.


On Wed, 27 Jul 2016 11:22:06 +0300
"Ejaz"  wrote:

> 
> Thanks you. 
> 
> The traffic will go to router which is handled by the Network dept.
> The fear  that may router can crash   if we  start enabling the
> packet capture since it is layer 7. 
> 
> Is advisable,  if we  deny outbound UDP port 0  from the DNS servers,
> after enabling firewall.
> 
> 
> Ejaz 
> 
> -Original Message-
> From: S Carr [mailto:sjc...@gmail.com] 
> Sent: Wednesday, July 27, 2016 10:51 AM
> To: Ejaz 
> Cc: bind-users 
> Subject: Re: outgoing-traffic
> 
> On 27 July 2016 at 08:41, Ejaz  wrote:
> > Thanks for all.
> >
> > But the strange thing is that if the request comes on 53 port then
> > it should go only from 53 is it?? Why goes out from 0, any clue
> > would be highly appreciate.
> >
> > Regards
> > Ejaz
> 
> Where's the packet capture to review?
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Shared libraries loaded after chroot

[Paul Kosinski]

I have avoided the problem chroot causes in a fairly general fashion by
using "mount --bind". For example:

  /bin/mount --bind /lib /chroot/dns/lib

will make the entire /lib directory available to the chrooted BIND,
assuming the path /chroot/dns is created beforehand to serve as the
chroot base for running BIND.

N.B. The "--bind" option to mount has nothing to do with BIND or DNS.
 (Look at the 'mount' manual for more details.)

This can be made as specific as desired by using multiple "mount --bind"
commands as needed for example:

  /bin/mount --bind /usr/bin   /chroot/dns/usr/bin
  /bin/mount --bind /usr/lib   /chroot/dns/usr/lib
  /bin/mount --bind /usr/lib64 /chroot/dns/usr/lib64

This is a lot easier than figuring out what files to copy, and all that
is needed after an update is to re-issue all the relevant "mount --bind"
commands.

I have heard that chroot does not provide unbreakable isolation, and,
of course, many extra files are made available to the chrooted process
compared to copying the minimum number of individual files. But I have
more than 500 separate "mount --bind" instances on one of my Linux
machines, setting up multiple chroot environments, and have not seen
any problems.

___
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: Nsupdate usage scenario

[Paul Kosinski]

Interesting idea -- it never occurred to me that I could have separate
zone files for sub-domains.

So, if I had a tiny zone file for "dynamic.example.com" alone, and a
bigger zone file for all the other stuff for "example.com", could I be
*sure* that nsupdate would *only* modify the tiny file, and not mess
with the bigger, main file?

Or would I also have to put a ZONE statement as the first line of the
nsupdate data stream specifying "dynamic.example.com" as the zone to be
updated? (And would that *guarantee* the main file was not changed?)


On Mon, 2 May 2016 14:15:21 -0500 (CDT)
"Jeremy C. Reed"  wrote:

> What about using a specific zone file just for the purpose of the
> single A record you want to maintain using dynamic updates?
> 
___
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

Nsupdate usage scenario

[Paul Kosinski]

I was trying to use nsupdate to automatically update a single A record
in our domain to its latest dynamic, but public, IP address. Although it
did indeed rewrite the zone file to reflect the new IP address, it also
rearranged all the entries in the file into seemingly random order
(maybe sorted by hash value, tree-walk order, or even named's internal
table address?).

Except for this single dynamic IP address, the zone file is maintained
by hand with a text editor, so rearranging it into an arbitrary order
would make hand maintenance much more difficult.

If there is a way to have nsupdate preserve the original order of the
zone file -- simply modifying the one A record "in place" and updating
the serial number -- that would be nice. If not I guess I will have to
continue using the little Perl script I wrote to do just that.

Paul



___
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