Re: Useful tip on nsupdate -- readline support.

[Mukund Sivaraman]

Hi Ondrej

On Wed, Jun 12, 2019 at 04:08:20PM +0200, Ondřej Surý wrote:
> Hey list,
> 
> I believe this needs addressing from the BIND team.
> 
> > * readline is GPL
> 
> BIND 9 supports compilation with libedit which is 99% drop-in replacement
> since 2015 (017cbd44).

I had mentioned libedit in my email too. However, readline is more
likely to be found in a Linux distribution (that an appliance bases off)
unless the packager knows about the GPL linkage and includes libedit as
a dependency.

While BIND is MPL licensed, linkage to GPL makes the overall work (of
that program) be covered by GPL. So even supporting readline adds in
additional restrictions past the MPL implicitly for the covered programs
(and arguably modified BIND library code). Perhaps you may consider a
warning about less permissive dependencies than MPL in the documentation
or at configure time, so BIND customers are aware of it.

(My comment was not based on just a random observation that it could
happen, but I'm not at liberty to discuss it.)

> The well-established open-source distributions are well aware of the readline
> firm stand on the GPL vs LGPL for the downstream users of the library.

The comment was directed at commercial (closed-source) re-distributors
of BIND such as appliance vendors, so they can check their builds.

> > libcap (POSIX capablities) is GPL similarly.
> 
> 
> No, it’s really not.  libcap is 3-clause BSD with following exception added:
> 
> > ALTERNATIVELY, this product may be distributed under the terms of the
> > GNU General Public License (v2.0 - see below), in which case the
> > provisions of the GNU GPL are required INSTEAD OF the above
> > restrictions.  (This clause is necessary due to a potential conflict
> > between the GNU GPL and the restrictions contained in a BSD-style
> > copyright.)
> 
> e.g. the primary license is 3-clause BSD, but in case you need to use libcap
> in GNU GPL project, you are allowed to do so without considering potential
> conflicts between 3-clause BSD and GPL 2.0

I was not aware of the BSD option. Fedora lists it as a GPL
package. That clears linking vs. libcap.

BTW, if this revelation was somehow problematic, then I take it back and
will go mind my own business.

Mukund
___
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: Useful tip on nsupdate -- readline support.

[Mukund Sivaraman]

On Tue, Jun 11, 2019 at 10:03:30AM -0400, Warren Kumari wrote:
> Hi there all,
> 
> I manually use nsupdate to make some changes to some of my zones -
> most recently I had to add a bunch of reverse DNS records. These are
> all very similar - the first octet changes, and then the target name
> changes. Unfortuniatly nsupdate doesn't support readline, and so the
> obvious "press up arrow, edit previous line, press enter" doesn't
> work, and so I end up entering one line, copying that into an editor,
> making changes, pasting, making changes, etc.
> 
> I just stumbled across this --
> https://dnsworkshop.de/nsupdate-history.html by Carsten Strotmann
> 
> Basically, uses rlwrap to wrap readline support into nsupdate - you
> just call `rlwrap nsupdate` and magically nsupdate now supports
> editing.
> 
> 'tis a simple trick, but removes much annoyance.

nsupdate has built-in readline support (when it finds it during build).
(Though, for for some reason, the nsupdate that ships with Fedora
doesn't seem to be linking to readline.)

On that note, buyer beware. A warning to all redistributors who
commercially repackage BIND with modifications (whether with blessing
from ISC or not):

* readline is GPL, and so you'll link your code to GPL if you link to it
  (which can be esp. bad for you if you modify libisc, libdns,
  etc. also). It's best to either remove readline from such build
  environments (libedit may be a suitable drop-in replacement), or
  configure without it, or patch out the code.

  There is some interesting GPL license enforcement history with readline:
  
  
https://en.wikipedia.org/wiki/GNU_Readline#Choice_of_the_GPL_as_GNU_Readline's_license
  https://gitlab.com/gnu-clisp/clisp/blob/master/doc/Why-CLISP-is-under-GPL

* libcap (POSIX capablities) is GPL similarly. An alternative is
  libcap-ng which is LGPLv2+, but it has a different API.

I think these are the only two libraries that are copyleft vs. BIND's
ISC (before) and MPL2 (now) licenses, and because they're GPL, your work
will be covered by GPL if you link against them.

This is usually not bad for the general public (and good for free
software), but if you're a commercial re-distributor of BIND and are
linking to GPL, good luck. I'm sure you'll even miss seeing this
thread. :)

Mukund
___
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: What is maximum size BIND can accept in A Record?>

[Mukund Sivaraman]

On Wed, Jun 05, 2019 at 02:57:41PM +0100, Tony Finch wrote:
> Mukund Sivaraman  wrote:
> 
> > On Wed, Jun 05, 2019 at 12:07:56PM +0100, Tony Finch wrote:
> > > The maximum length is 254 including the terminating dot. The maximum
> >
> > 254 excluding the terminating dot or 255 including the terminating dot.
> 
> 255 is the wire format limit not the presentation format limit :-)

Ah, I see what you meant.. :)

Mukund
___
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: What is maximum size BIND can accept in A Record?>

[Mukund Sivaraman]

On Wed, Jun 05, 2019 at 12:07:56PM +0100, Tony Finch wrote:
> The maximum length is 254 including the terminating dot. The maximum

254 excluding the terminating dot or 255 including the terminating dot.

Mukund
___
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: A little baffled by bind 9.14.2 wanting some special python?

[Mukund Sivaraman]

On Wed, May 29, 2019 at 11:09:45AM -0400, Dennis Clarke wrote:
> On 5/29/19 2:22 AM, Michał Kępień wrote:
> > > For reasons unknown the configure process blows up even if I specify
> > > the option --disable-python and in the config.log I see :
> > 
> > The option is actually called --without-python; the fix for that mistake
> > is already committed:
> > 
> >  https://gitlab.isc.org/isc-projects/bind9/merge_requests/1964
> > 
> > Apologies about the confusion.
> > 
> 
> Thanks but won't matter much anyways. Time to shutdown all the Solaris
> systems and move to FreeBSD or similar.  Sadly there is nothing that can
> run on these Fujitsu sparc boxes I have.  Nothing that I know of.

From: https://www.isc.org/downloads/software-support-policy/

> BIND 9.11 is an Extended upport version, and will be supported until
> December, 2021

which is more than 2 years from now. Unless you need a feature from 9.12
and above, 9.11 is still a good choice if you were able to build it on
your Solaris platform. ISC maintains its older non-EOL BIND versions
well (and 9.11 is likely more stable too from the years of public's
usage it has got).

+1 on deciding to move from Solaris to a BSD or Linux though. ;)

Mukund
___
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 max socket/query per IP

[Mukund Sivaraman]

On Wed, May 22, 2019 at 11:39:04PM +0200, Ict Security wrote:
> Dear Klaus,
> 
> >>btw - how high is the "extremely load"?
> Without old DLZ module, Bind 9.12 scales to thousands and thousands of 
> queries.
> If i include old DLZ module, with postgres, over about 1000 Qps Bind
> start to slow down visibly,
> 
> Do you think the old DLZ-Postgreqsl module might the bottleneck?
> Any possible replacement, continuing using Postgresql (i made an
> implementation to activate some custom filtering with a database).

It might be.

The dns_db API (which DLZ is an implementation of) is a synchronous
API. When a named thread asks dns_db to find an answer for it, it will
block until the dns_db API returns. This has almost no effect when using
the in-memory zones/cache which is typical, but when you start using a
database backend within dns_db which can block waiting for an answer,
this can tie up all the worker threads, depending on the rate of
response from the database. This would also cause queries to queue up on
the listening socket.

Use pstack  when it appears to be stuck to see
if the threads are stuck within the DLZ implementation. If that is the
case, perhaps you can try increasing the number of worker threads
greatly (named -n ###) to see if that helps mitigating the issue.

In answer to your other question about why a query to another alias
interface appears to work, it is a different queue that by your
description has nothing waiting in it.

Mukund
___
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: High load on BIND DNS and query timeouts after RPZ XFR retrieve

[Mukund Sivaraman]

On Sun, May 19, 2019 at 10:55:53PM +0200, Peter V wrote:
> Hi all,
> 
> I would like to get opinion on issue I was involved over weekend.
> Customer utilizes RPZ feed from spamhaus and worked pretty OK for some
> months after initial deployment.
> They reported issue with wrong performance of BIND DNS; 
> BIND version: 9.10.8-P1 

BIND 9.11 and below can't sometimes keep up with Spamhaus's feeds (their
rate of change) without significant tuning. RPZ in BIND 9.11
(non-subscription open source version) and below updates its summary
datastructures synchronously along with policy zone updates that causes
severe lock contention with the query path. With Spamhaus feeds, updates
can be almost continuous with no relief.

BIND 9.12+ mitigates this somewhat by refactoring the RPZ summary
datastructure update path so it doesn't happen synchronously with the
RPZ zone updates, albeit with some differences (esp. for the typical
Spamhaus feeds' users - changes from RPZ feeds are visible every 60s in
the default configuration). You may want to try BIND 9.12+ to see if it
helps your case.

(An alternative on BIND 9.10 is to try if forcing AXFR by using
"request-ixfr no;" helps. This uses different codepaths within named
that could reduce some lock contention - however, it would behave poorly
with Spamhaus's feeds which are quite large. At least the transfer rate
would have to be limited somehow, and I know that it hasn't helped for
some users.)

This is an elaborate topic more than just RPZ.

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

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

Re: BIND 9.10 fast only on alias IP

[Mukund Sivaraman]

On Mon, May 20, 2019 at 10:06:09AM +0200, Ict Security wrote:
> Dear guys,
> 
> i am experiencing a very strange beahviour of Bind under busy peak time.
> 
> With a quite important number of incoming DNS queries, response are
> really, really slow;
> sometimes they even stuck.
> 
> If i try to query, in those busy moments, an alias secondary IP
> address of the same machine, the response is really immediate!
> 
> I have disabled connection tracking and raised up nf_conntrack_max.
> In system logs, i do not see any limitations or buffer full.
> 
> Do i need to balance incoming connection on more alias IP?
> Or shall i change some other parameters which i am not aware at the moment?

It's not possible to say exactly what's going on without more detailed
info. It's possible that named has reached its query performance limit
and so the recv queue is at its max capacity for that listening
socket. Possibly queries are getting dropped due to this. In that case,
increasing the recv queue is unlikely to help and possibly just cause
bloat. See what "netstat -lu" or "ss -lu" tells you, and load of the
system.

Possibly you can attempt to mitigate this by tuning various knobs, e.g.,
disable excessive logging and query logging, increase the number of UDP
listeners and worker threads to match your CPU count, etc. There isn't
much that can be improved on 9.10 I'm afraid.

You may want to try BIND 9.12+ that has performance optimizations.

Mukund
___
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 resolver zone delegation

[Mukund Sivaraman]

On Wed, May 15, 2019 at 03:27:14PM +0200, Frank Patzig wrote:
> In my log
> 
> DNS format error from 64.7.11.138#53 resolving vpn.smiths.com/MX for client
> 127.0.0.1#47512: Name smiths.com (SOA) not subdomain of zone vpn.smiths.com
> -- invalid response
> 
> What is the problem.

> ;; AUTHORITY SECTION:
> smiths.com. 59  IN  SOA resolve01.sslvpndemo.com.
> hostmaster.resolve01.sslvpndemo.com. 5 10800 3600 604800 60

SOA belongs to smiths.com, whereas the resolver is expecting an answer
from zone vpn.smiths.com following the delegation for it. Instead, from
your own paste, vpn.smiths.com/A looks to be an address record in zone
smiths.com (in any case, vpn.smiths.com/MX is missing and the resolver
will reject the negative answer because it has an unexpected SOA owner
name from the smiths.com zone).

Have you setup the "vpn.smiths.com" zone on resolve01.sslra.com and
resolve02.sslra.com?

Mukund
___
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: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"

[Mukund Sivaraman]

On Fri, Apr 26, 2019 at 10:08:43PM +0200, Havard Eidnes via bind-users wrote:
> > (2) We'll look at tweaking this log message, but if you want to just not
> > see this log message, just recompile after removing the offending CTRACE
> > statement from bin/named/query.c. In fact, this code is normally enabled
> > when configured with --enable-querytrace. Do you have query tracing
> > configured? Is seeing this additional log message so inconvenient then?
> 
> I think there must be something wrong with the log message.  It
> seems excessive to log this message about once per query,
> especially since it seems to (misleadingly?) indicate an error
> condition?  I'm not intimate enough with the code to suggest what
> the exact problem is, though.
> 
> And ... as stated, configuring without --enable-querytrace
> removes the log message.

I can't speak for ISC BIND 9 (you seem to have mailed my old email
address), but --enable-querytrace was not meant to be used in
production. One should expect to observe excessive logging when it is
configured so, because that's what the configure argument implies
("perform abundant logging about query processing even if it hurts
performance").

To summarize, the log message is that the code has observed something
unexpected (the carpet has been pulled from under it) but it copes with
it. Perhaps the logging call can be removed from the code.

In more detail, BIND uses a per-view RPZ summary data structure from the
contents of response policy zones configured within that view. The
summary datastructure is a singular combination of the contents of all
the RPZ zones from that view, so that queried names can be efficiently
matched against RPZ triggers in the query path. The summary
datastructure is built and updated when the RPZ zones it is dependent on
are updated. The logged message complains that the RPZ summary
datastructure is out-of-sync with the RPZ zones, and so named was not
able to lookup the action for a trigger from the RPZ zone it was looking
at. In this case, named tries to continue from the next matching zone in
precedence.

Mukund
___
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: max-cache-size

[Mukund Sivaraman]

On Thu, Apr 18, 2019 at 04:02:27PM +0200, Jakob Dhondt wrote:
> Hi everyone,
> 
> just a quick question about the max-cache-size option in bind. I
> couldn't find any details online.
>
> 
> I was wondering if this option only includes DNS queries/responses
> getting cached or anything else as well, e.g. RPZ zones being kept in
> memory.

The max-cache-size setting is a guide to the in-memory cache database
code used by BIND to try to keep the size of its cache within a certain
limit.

RPZ zones are not part of the cache - they are ordinary individual
zones. On resolvers, there is additionally a per-view RPZ summary
datastructure that's built using the RPZ zones' contents, which provides
a way to match a query against RPZ triggers optimally. None of this is
affected by the max-cache-size setting.

Mukund
___
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: Fwd: SSHFP observation

[Mukund Sivaraman]

On Thu, Jan 31, 2019 at 10:30:30AM -0500, Jim Popovitch via bind-users wrote:
> On Thu, 2019-01-31 at 19:14 +0530, rams wrote:
> > Hi,
> > I have setup sshfp records as follows in bind zone file:
> > 
> > test1.ramesh-sshfp.com. 86400   IN  SSHFP 1 1 aa
> > test2.ramesh-sshfp.com. 86400   IN  SSHFP 1 1 00
> > 
> > Successfully started bind but when queried for domain test1 and test2
> > , returning malformed error and no answer. If fingerprint value wrong
> > then bind should validate and should not start. Is it expected
> > behavior? Kindly confirm.
> 
> Bind will restart cleanly unless you muck up something in the config
> file(s).  In this case you have something wrong in a zone file, and we
> can't see what it is because the domain you specified is invalid.  So,
> until you show us some data my best guess is that you have a formatting
> error in a zone file(s).
> 
> Help us help you by specifying the actual domain.

The original poster is right. Something is broken in SSHFP
processing. He's configured a zone with the above records, and querying
against that zone is causing dig to print that the reply is malformed.
BIND should never return a malformed message, so there is a bug
somewhere.

Mukund
___
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: 0-TTL when querying "invalid" soa

[Mukund Sivaraman]

On Tue, Jan 29, 2019 at 04:23:56PM +0100, Tom wrote:
> We're running BIND-9.12.3-P1 on our authoritative servers and we have the
> same behavior with 0-ttl with a invalid soa-query. Is this bind-specific?
> Why does an invalid soa-record responds with 0-ttl in the authority-section?

It appears to have been added so that a client that tries to find the
containing zone of an arbitrary name by making SOA queries doesn't
pollute a resolver's cache (and other intermediate caches if any) with
NXDOMAIN entries that are likely only going to be useful for that
client.  It is a BIND implementation detail though it could be
implemented similarly by other nameservers too.

In this age of random subdomain attacks where NX cache entries due to
such attacks pollute the cache and are cleared up more aggressively,
perhaps this sort of handling is no longer needed.

Mukund
___
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: dig empty question section

[Mukund Sivaraman]

On Mon, Jan 21, 2019 at 04:55:54PM +0100, Egon Kocjan wrote:
> Hello
> 
> Is it possible to send a DNS request packet with zero QDCOUNT using dig?

See dig +header-only in its manpage.

Mukund
___
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: rbtdb.c:1497: fatal error

[Mukund Sivaraman]

On Tue, Dec 04, 2018 at 08:21:26AM +1100, Mark Andrews wrote:
> Add ‘database “rbt64”;’ to the dynamic zone configurations.  It looks like 
> you are
> overflowing the 32 bit serial number.

This was thought of as highly improbable when rbt64 was removed and
uint32_t was settled on for the type of serial.

Is this going to bring back the rbtdb64 in master or typedef uint64_t
rbtdb_serial_t ?

Mukund
___
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: showzone/modzone with catalog zone

[Mukund Sivaraman]

On Wed, Nov 21, 2018 at 04:48:03PM +0530, Mukund Sivaraman wrote:
> > Then I wanted  to modify the zone config:
> > rndc modzone  '{ type slave; file 
> > “__catz___default_catalog_.db"; masters { ; }; allow-transfer { 
> > ; }; also-notify {  }; };'
> > zone ‘' reconfigured.
> 
> This seems like a bug, if named allowed an existing catalog zone to be
> modzone'd.

I meant member zone of catalog zone.

Mukund
___
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: showzone/modzone with catalog zone

[Mukund Sivaraman]

On Wed, Nov 21, 2018 at 10:08:23AM +, BÖSCH Christian wrote:
> Hi,
> 
> I have bind9.12.2 running.
> I populate zones with a catalog zone, which is fine.
> 
> But if I do a ‘rndc showzone ’ on a slave server, I get:
> rndc: 'showzone' failed: failure

rndc showzone works only for NZF/NZD (dynamically added zones using rndc
addzone).

> In the log nothing strange:
> Nov 21 10:53:46 ns1 named[59161]: general: received control channel command 
> 'showzone '
> Nov 21 10:53:46 ns1 named[59161]: general: loading NZD config from 
> '_default.nzd' for zone ‘'
> 
> Then I wanted  to modify the zone config:
> rndc modzone  '{ type slave; file “__catz___default_catalog_.db"; 
> masters { ; }; allow-transfer { ; }; also-notify {  }; };'
> zone ‘' reconfigured.

This seems like a bug, if named allowed an existing catalog zone to be
modzone'd.

> After that the showzone from above displays the new config, BUT ‘rndc reload’ 
> doesn’t work anymore:
> 
> rndc reload
> rndc: 'reload' failed: already exists
> 
> Log:
> Nov 21 10:56:12 ns1 named[59161]: config: 
> /usr/local/etc/namedb/options.include:32: catz: catalog zone 'catalog' will 
> not be reconfigured
> Nov 21 10:56:12 ns1 named[59161]: general: loading NZD configs from 
> '_default.nzd' for view '_default'
> Nov 21 10:56:12 ns1 named[59161]: config: none:1: zone ‘' already exists
> Nov 21 10:56:12 ns1 named[59161]: general: reloading configuration failed: 
> already exists
> 
> 
> If I do a ‘rndc reload’ once more, the named process crashed and is gone:
> 
> rndc: connection to remote host closed
> This may indicate that
> * the remote server is using an older version of the command protocol,
> * this host is not authorized to connect,
> * the clocks are not synchronized, or
> * the key is invalid.
> 
> Is this a bug, or am I doing something wrong?

Ouch. If named crashed (and it is understandable given the unexpected
behavior above), it is clearly a bug. You may want to open a bug ticket
on the ISC gitlab.

Mukund
___
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: RSASHA3 in DNSSEC

[Mukund Sivaraman]

On Tue, Nov 13, 2018 at 02:06:24PM +0700, Mukund Sivaraman wrote:
> There is a draft and BIND 9 implementation of SHA-3 in DNSSEC:
> 
> https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01

The draft is currently expired. I'll update it before the next IETF
meeting to scale down what it proposes, by limiting introduction of
SHA-3 in just a couple of new DNSKEY algorithms.

Mukund
___
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: RSASHA3 in DNSSEC

[Mukund Sivaraman]

On Tue, Nov 13, 2018 at 12:48:04PM +0600, Hasibuzzaman Gazi wrote:
> hello there,
> i am a student and currently working on a class project where i am using
> DNSSEC to secure the DNS records. i want to use RSASHA3 encryption method.
> i have haveged installed and latest bind package, the problem is i dont
> know what is the code to use to implement the cryptography method. is there
> anyone who can help me in this regard? my zone name is "example.com"
> 
> thanks in advance, hopefully waiting for your reply very soon. please i
> need help with this.

There is a draft and BIND 9 implementation of SHA-3 in DNSSEC:

https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01

https://github.com/muks/bind9/tree/sha3

There is also an ldns branch here:

https://github.com/tjeb/ldns/tree/sha3_and_pss

including introduction of RSASSA-PSS (instead of PKCS1 v1.5). Although
RSA is a workhorse algorithm that has been largely reliable, the focus
in DNS working groups going forward is to use ECC with smaller key and
signature sizes.

I suggest that you attempt to implement SHA-3 with ECDSA and EDDSA, and
for DS records (however, even this is implemented in the trees above; I
don't know if it would be the best exercise for a class project, but you
could reimplement it independently).

Mukund
___
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: odd failures from 9.12.2-P2

[Mukund Sivaraman]

On Thu, Oct 18, 2018 at 07:21:49PM -0400, Dennis Clarke wrote:
> I see these results :
> 
> I:System test result summary:
> I:   7 FAIL
> I:  69 PASS
> I:   4 SKIPPED
> I:  12 UNTESTED
> I:The following system tests failed:
> I:  autosign
> I:  catz
> I:  dnssec
> I:  filter-
> I:  legacy
> I:  mkeys
> I:  staticstub
> 
> This is on Solaris 10 sparc and using the Oracle Studio 12.6 tools as
>  well as OpenSSL 1.1.1 which passes all tests.
> 
> Is there a way to dig out more information from these failures?

Each of the above are sub-directories in bin/tests/system, one per
system test. Within these, you'll have sub-directories named "ns"
(where N is a digit). Within these, you'll typically have files with the
name "named.run" which is the debug logging output of a named process
that was run during the system test.

Looking into these log files will reveal why the tests failed (other
than the messages logged by the test script itself). It's not for the
faint-of-heart and you have to be well-versed with BIND to understand
and debug issues if the system tests themselves are failing for anything
but trivial failures.

Mukund
___
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 and UDP tuning

[Mukund Sivaraman]

On Thu, Sep 27, 2018 at 10:53:25AM -0400, Alex wrote:
> Many of these values I've already tweaked and have had no effect on my
> SERVFAIL issues :-(

If you are getting SERVFAILs from a BIND resolver you administer, then
it has responded to your query. If you turn up the log level to
something like -d 99, it'll print the steps that led to that SERVFAIL.
Usually you'll find something there that directs you to next steps.

On this topic, my home resolver is also a stock packaged BIND version as
you, and I too see spurious SERVFAILs sometimes. I used to think this
was due to too much indirection, e.g., when named starts up and you run:

dig -x 176.9.81.50

on a cold cache. However it seems to be returning SERVFAIL sometimes for
what should be a cached answer. I'll also turn up the debug logging and
watch it.

Mukund
___
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: NTP through DNS?

[Mukund Sivaraman]

Hi Danny

On Fri, Sep 21, 2018 at 07:47:46AM -0400, Danny Mayer wrote:
> You can create a DNS A or  or even a CNAME in your local DNS that
> the NTP server can use and it all works.

The original poster asked "can I publish/query the NTP server through
DNS the same way I can ask who is doing LDAP?"

That implied service discovery / config provisioning, not just
publishing address records of the NTP service in the DNS.

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

[Mukund Sivaraman]

On Thu, Sep 20, 2018 at 09:48:08AM +0100, 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.

Some functions in the reply handling in the resolver, e.g.,
answer_response() before refactoring were responsible for multiple CVEs
and IIRC even regressions introduced by fixes. Note that the bug now is
not a CVE severity one.  Such refactoring, though risky to do for
evolved code, was necessary.

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

[Mukund Sivaraman]

On Thu, Sep 20, 2018 at 11:28:46AM +0100, Tony Finch wrote:
> G.W. Haywood via bind-users  wrote:
> > On Wed, 19 Sep 2018, Michael McNally wrote:
> >
> > >   ... code refactoring ...
> >
> > That phrase always sends shudders through my corpus.
> 
> I recommend having a read through query_find() from before 9.12. Be
> warned it'll take a while, because the function is 2500 lines long.

tis but a scratch ;-)

Mukund
___
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: NTP through DNS?

[Mukund Sivaraman]

On Wed, Sep 19, 2018 at 10:08:34AM -0400, Mauricio Tavares wrote:
> Stupid question: can I publish/query the NTP server through DNS the
> same way I can ask who is doing LDAP?

An NTP serice doesn't belong to a domain, so maybe not (I don't know of
one off my mind).

For provisioning, there are DHCP options to do this. E.g., with ISC-DHCP
and 10.98.0.5 as the NTP server:

subnet 10.98.0.0 netmask 255.255.0.0 {
   ...
   option ntp-servers 10.98.0.5;
}

and perhaps also use "tcode" and "time-offset" options to set the
timezone.

But a real bummer is that some DHCP clients (e.g., Android phones) do
not make use of this option, and don't even provide a config setting to
do so. IIRC they synchronize time via the cell phone signal.

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

[Mukund Sivaraman]

On Sun, Jun 24, 2018 at 04:30:08PM -0400, Alex wrote:
> Hi,
> We had a former customer who parked about 300 domains with his
> registry on our server but is no longer a customer and hasn't moved
> his domains. There aren't any hosts behind the domains.
> 
> Is there anything more I can do to block/prevent them from continually
> querying my system outside of just redirecting them to localhost or
> something?
> 
> It's not a terrible amount of traffic, but it's pretty substantial.
> 
> Unfortunately asking him nicely didn't work.

Serve the customer an invoice. They're his domains after all, and he's
using up your resources. You can identify him and show that your
resources are being used because he has not moved the delegations.

Mukund
___
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 implement DNS RPZ with Domain Based Reputation Data

[Mukund Sivaraman]

On Sun, Apr 29, 2018 at 08:27:34AM +0530, Blason R wrote:
>  Hi Team,
> Can someone please confirm if below stuff I found pertaining to BIND can be
> implemented with DNS RPZ? If yes can someone please point me to the
> appropriate document?
> Domain Based Reputational Data
> 
> With the release of BIND 9.8.1 a *new* reputational mechanism is available,
> this time for use by DNS resolvers. An organisation is able to receive a
> reputational data feed describing internet domains that have a 'poor'
> reputation. A poor reputation is usually based on the delivery of malware,
> or other forms of nefarious internet activity.
> 
> The ISC have provided an efficient standardised mechanism for the use of
> reputational data by recursive DNS resolvers and have left the provision of
> the reputational data itself to professional organisations that specialize
> in this type of information. Additionally, the response that shall be given
> to a client attempting to resolve a domain which is listed amongst those
> with a 'poor' reputation is left to the local organisation to decide.

This is basically RPZ. "reputational data feed" is basically a response
policy zone. There are feed providers such as Spamhaus, Farsight
Security, etc. E.g., see this:

https://www.spamhaus.org/news/article/669

Mukund
___
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: Fwd: Facing weird issue with DNS-RPZ

[Mukund Sivaraman]

On Tue, Apr 24, 2018 at 07:25:45PM -0700, Ray Van Dolson wrote:
> On Tue, Apr 24, 2018 at 07:21:34PM -0700, Mukund Sivaraman wrote:
> > On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> > > I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> > > (Extended Support Version).
> > 
> > RPZ in BIND 9.9 is experimental and unsupported (except for the
> > subscription branch). Please use at least BIND 9.10 for RPZ.
> > 
> 
> We've been using RPZ in RHEL6-provided BIND (based on BIND 9.8.2)
> (based on BIND 9.8.2).
> 
> No issues.  Unsure if Red Hat backports the "more stable" code?

I doubt it. But speaking for ISC BIND, 9.10+ is the only RPZ code we
bugfix and there have been a lot of bugs fixed.

Mukund
___
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: Fwd: Facing weird issue with DNS-RPZ

[Mukund Sivaraman]

On Tue, Apr 24, 2018 at 06:03:43PM +0530, Blason R wrote:
> I am building DNS RPZ on named BIND 9.9.4-RedHat-9.9.4-51.el7_4.2
> (Extended Support Version).

RPZ in BIND 9.9 is experimental and unsupported (except for the
subscription branch). Please use at least BIND 9.10 for RPZ.

Mukund
___
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: v9.12.1 RPZ 'map' format returns fatal error: incompatible masterfile-format or database for a response policy zone

[Mukund Sivaraman]

On Sun, Apr 22, 2018 at 05:26:13PM -0700, acl...@yepmail.net wrote:
> When I restart my server, for each of the 2 rpz 'map' zones, I see in log
> 
>   Apr 22 16:45:06 katana named[42520]: 22-Apr-2018 16:45:06.504 general: 
> error: zone 'rpz.blacklist.perm.local': incompatible masterfile-format or 
> database for a response policy zone
>   Apr 22 16:45:06 katana named[42520]: 22-Apr-2018 16:45:06.505 general: 
> error: reloading configuration failed: not implemented
> 
> which is, apparently, fatal to server start.
> 
> Switch back to 'text' file & format, and all's good.
> 
> Searching, I'm finding nothing on the error.
> 
> Any help with figuring out the problem and a fix would be appreciated!

map format is unsupported for RPZ, because until 9.12, RPZ was
intertwined with the RBTDB code. We may revise this restriction in the
future, but for now, RPZ zones cannot be of format map.

Mukund
___
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: dig warns that some TSIG could not be validated

[Mukund Sivaraman]

On Fri, Apr 06, 2018 at 02:05:39PM +0200, Anand Buddhdev wrote:
> On 06/04/2018 12:38, Tony Finch wrote:
> 
> Hi Tony,
> 
> > There is a weird bit in the TSIG spec, RFC 2845:
> > 
> >4.4. TSIG on TCP connection
> > 
> >A DNS TCP session can include multiple DNS envelopes.  This is, for
> >example, commonly used by zone transfer.  Using TSIG on such a
> >connection can protect the connection from hijacking and provide data
> >integrity.  The TSIG MUST be included on the first and last DNS
> >envelopes.  It can be optionally placed on any intermediary
> >envelopes.  It is expensive to include it on every envelopes, but it
> >MUST be placed on at least every 100'th envelope.
> > 
> > I haven't looked at BIND's handling of TSIG for AXFR in detail, so I
> > don't know how it handles this case, but it is the kind of tricky area
> > where interop bugs lurk. I haven't looked at Secure64 at all so who knows
> > what it does :-)
> 
> I think this is exactly it. Secure64's signer is based on NSD, and it
> doesn't sign every message in a TCP AXFR.

That is valid and BIND (dig included) doesn't warn about it.

The fact that you're seeing a warning from dig means that something is
BAD.  It should be investigated. It basically means that signature
verification for a sequence of messages failed.

Please check if your BIND has change 4643 which, when fixing a TSIG
vulnerability, introduced a short-lived bug that was fixed by change
4647.

Mukund
___
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: dig warns that some TSIG could not be validated

[Mukund Sivaraman]

Hi Anand

On Fri, Apr 06, 2018 at 12:21:49PM +0200, Anand Buddhdev wrote:
> Hello folks,
> 
> I'm on CentOS 7, which has an older version of dig from this package:
> 
> # rpm -qf /usr/bin/dig
> bind-utils-9.9.4-51.el7_4.2.x86_64
> 
> When I use this dig to AXFR a zone from a Secure64 DNSSEC signer
> appliance, I'm seeing this at the end of the AXFR:
> 
> ;; Query time: 32899 msec
> ;; SERVER: 193.0.7.194#53(193.0.7.194)
> ;; WHEN: Fri Apr 06 09:36:38 UTC 2018
> ;; XFR size: 73829 records (messages 295, bytes 4801484)
> ;; WARNING -- Some TSIG could not be validated
> 
> While I've seen TSIG failures caused by key mismatch, or mismatched time
> between servers, I've never seen a warning like this before, about TSIG
> validation, and I don't know what it means.
> 
> I can't see anything strange with the AXFR. I would appreciate it if one
> of the BIND developers could explain what this warning means, and
> whether it is something to be worried about.

I am wondering if you have a badly ported patch. Is the AXFR server of
an NSD flavour, or more specifically, doesn't sign every DNS message in
a TCP continuation (a sequence of DNS messages used during AXFR and
IXFR)?

An AXFR can use multiple DNS messages for the transfer. The dig warning
above means that some of those messages could not be validated.

It may be due to a short-lived BIND bug. Check if the version of BIND
you're using has this change:

4647.   [bug]   Change 4643 broke verification of TSIG signed TCP
message sequences where not all the messages contain
TSIG records.  These may be used in AXFR and IXFR
responses. [RT #45509]

Mukund
___
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: Suggestions for a distributed DNS zone hosting solution I'm designing

[Mukund Sivaraman]

Hi

On Tue, Mar 06, 2018 at 11:10:35PM -0700, Latitude wrote:
> I would like to solicit constructive feedback in regards to a distributed DNS
> zone hosting proof of concept I'd like to design and establish. 
> 
> I must deploy a DNS system with the following requirements:
> - single master server, multiple slave servers
> - minimal time for name resolving for Americas, Europe and Asia
> - up to millions records in a domain zone
> - changes propagate in real time (master -> slaves), 2 sec max delay
> - automatic slave data re-syncing on master link restore after disconnect
> - API for zone records manipulation (insert, update, delete)
> 
> So far I am considering using (free) DC/OS on Amazon Web Services with the
> latest version of BIND containerized using docker on a Linux or Unix OS. Dyn
> and Infoblox are also on my list of items to research but I have never used
> either and I enjoy working with BIND on Linux. After all this is the BIND
> Users group, but I would be interested to know if someone can make a case
> for using Dyn or Infoblox in this case. 
> 
> Considerations/questions I have about this deployment for this Bind-Users
> forum are:
> 
> 1. How can I examine DNS resolution times using this platform (or other
> platforms to compare with) in different geographic areas of the world
> without first deploying it? I will need to have benchmark data to test
> against to verify I am getting the fastest speeds possible on name
> resolutions. 

Changing conditions on the internet affect nameserver selection and
there are several factors involved in what is 'fastest'. When talking
about 'resolution', it also depends on resolvers' and their clients'
connectivity. Short of empirically measuring response times, I don't
have a better answer.

> 2. How to handle millions of records in a DNS zone, and how common is it to
> have millions of records in a DNS zone?

It is uncommon to have millions of records in a DNS zone, but it is
possible and there are some operators who run such large zones. We
routinely test million+ RR zones with BIND.

> 3. What API solutions for DNS zone edits currently exist or should I be
> lookin into?

DNS UPDATE (RFC 2136) is the protocol for modifying zone data.

You may also be interested in web APIs such as: https://dnsimple.com/api

> I will research more in the next day but so far I know I can manually
> configure named.conf to propagate zone changes to slave servers rapidly
> (aiming for 2 seconds or less) using NOTIFY messages and zone transfers, and
> also configure slave servers to automatically re-synch zone data with the
> master server upon reestablishing a connection. That should satisfy two of
> my requirements above. 

There is no guarantee that any nameserver will synchronize zones updates
from primary within 2 seconds max. If the public internet is involved,
the cumulative roundtrip times involved in notifying a secondary and for
the secondary to start a transfer alone may take more than 2 seconds
depending on network conditions and topology, especially if you're
talking about Americas, Europe and Asia together.

Mukund
___
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: Minimum TTL?

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 05:05:51PM +0100, Reindl Harald wrote:
> > I doubt the zone owner is forcing you to use their zone. You can nix
> > fetches to it. If you want the zone data, then follow what the zone
> > owner requires.
> 
> does not matter

It matters to us.

Mukund
___
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: Minimum TTL?

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 04:39:36PM +0100, Reindl Harald wrote:
> 
> 
> Am 08.02.2018 um 16:34 schrieb Mukund Sivaraman:
> > On Thu, Feb 08, 2018 at 01:30:04PM +0200, Michelle Konzack wrote:
> > > Hello Harald,
> > > Am 2018-02-08 hackte Reindl Harald in die Tasten:
> > > > you miss the topic
> > > > 
> > > > many DNSBL's have a very short TTL and at the same time a limit of
> > > > queries froma single IP until you need to pay for the service
> > > > 
> > > > so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> > > > is trying to deliver spam to you override the 2 scodn TTL with 90
> > > > seconds or whatever makes sense reduces the total amount of DNS requests
> > > > dramatically
> > > 
> > > Sounds logic.
> > > 
> > > And this feature was rejected by the Bind Developers?
> > 
> > If the RRset wants a TTL of N seconds, then that is the authoritative
> > instruction from the owner of the zone about how the data should be
> > used. We have to follow that. The RFCs so far do not allow increasing
> > TTL, though they allow decreasing it.
> > 
> > If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
> > about why it is so. There ought to be a reason from their perspective
> > why it is set to 2s
> 
> so what - nobody can force me to ask him the same question every 2 seconds
> and as long it's a local resolver for my own services the one i have to ask
> about any why in doubt is the person i face in the mirror every morning

I doubt the zone owner is forcing you to use their zone. You can nix
fetches to it. If you want the zone data, then follow what the zone
owner requires.

> yes, you are free to decide that named don't need to support the users
> wish of such a feature. but the result is that the user stops to use
> named at all on a inbound-mailserver and is done

Also, just for argument's sake, one user wants to extend TTLs to
5s. Another wants 60s TTLs. What is OK and what is going too far?

It really is something for the zone owner to consider.

Mukund
___
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: Minimum TTL?

[Mukund Sivaraman]

On Thu, Feb 08, 2018 at 01:30:04PM +0200, Michelle Konzack wrote:
> Hello Harald,
> Am 2018-02-08 hackte Reindl Harald in die Tasten:
> > you miss the topic
> >
> > many DNSBL's have a very short TTL and at the same time a limit of
> > queries froma single IP until you need to pay for the service
> >
> > so if you have a inbound MX and the RBL has 2 seconds TTL and a botnet
> > is trying to deliver spam to you override the 2 scodn TTL with 90
> > seconds or whatever makes sense reduces the total amount of DNS requests
> > dramatically
> 
> Sounds logic.
> 
> And this feature was rejected by the Bind Developers?

If the RRset wants a TTL of N seconds, then that is the authoritative
instruction from the owner of the zone about how the data should be
used. We have to follow that. The RFCs so far do not allow increasing
TTL, though they allow decreasing it.

If a DNSBL zone has a TTL of 2 seconds, then talk to the zone owner
about why it is so. There ought to be a reason from their perspective
why it is set to 2s.

Mukund
___
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: option 'lmdb-mapsize' was not enabled at compile time

[Mukund Sivaraman]

On Sun, Jan 14, 2018 at 07:43:27AM -0700, russellb...@gmail.com wrote:
>   Beginning with bind-9.11.2-i586-1 I've gotten this message on
> boot:
> 
>   named[1094]: ./config.c: option 'lmdb-mapsize' was not enabled at 
> compile time (ignored)
> 
>   named works - this is just noise in my system logs.

Ought to be fixed by this change in 9.11.3:

4659.   [bug]   Remove spurious log message about lmdb-mapsize
not being supported when parsing builtin
configuration file. [RT #45618]

Mukund
___
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: DDNS - limitation and excluding updates from certain networks

[Mukund Sivaraman]

On Wed, Dec 20, 2017 at 10:40:31AM -0700, Grant Taylor via bind-users wrote:
> On 12/20/2017 06:27 AM, MAYER Hans wrote:
> > And I don’t wont that this static names can by changed by someone out of
> > an IP range, where it is allowed.  I didn’t find any hint to block
> > certain IP ranges to be updated within a dynamic zone.
> 
> I don't remember the specifics, but there is a way built into BIND to do
> what you are wanting.
> 
> I think there's an ACL configuration where you can configure that DDNS
> clients are only able to update the records that they own.  -  I think
> ownership is related to the connecting IP.
> 
> I do remember that when I tested this, it was trivial to set up and one
> configuration entry seemed to apply multiple DDNS clients.
> 
> I'm sorry, but I don't remember any more specifics.

I beg your pardon, my original answer was incorrect. The option to do
this (for more access control over what updates to perform) is
"update-policy" as you have correctly pointed out.

The original poster may want to read about this option in the manual,
under "Dynamic Update Policies" in Chapter 6.

Mukund
___
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: DDNS - limitation and excluding updates from certain networks

[Mukund Sivaraman]

On Wed, Dec 20, 2017 at 01:27:17PM +, MAYER Hans wrote:
> 
> Dear Mukund, 
> 
> Many thanks for coming back. 
> 
> > You'll have to explain what you mean better for a more specific answer,
> > but see the manual for the "allow-update" ACL config option
> 
> In my zone configuration I have an “allow-update” statement. 
> Here I define all networks which are allowed to dynamically update the DNS 
> entries. 
> 
> But my zone contains other IP addresses too. Not only those of the PCs.
> These are static names/addresses which are seldom changed. 
> 
> And of course the complete zone is a dynamic zone. 
> 
> And I don’t wont that this static names can by changed by someone out of an 
> IP range, where it is allowed.
> I didn’t find any hint to block certain IP ranges to be updated within a 
> dynamic zone. 
> 
> Hopefully this explains my question a little bit better.

The allow-update ACL applies to the whole zone. The ACL code doesn't
discriminate using the contents of the update.

You could put the names requiring update into a child zone (but
obviously it'll add another label) or another zone altogether (but
obviously it'll have a different name).

Mukund
___
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: DDNS - limitation and excluding updates from certain networks

[Mukund Sivaraman]

On Wed, Dec 20, 2017 at 12:39:33PM +, MAYER Hans wrote:
> 
> 
> Dear All,
> 
> My environment: We are using the latest version of BIND and DHCP from ISC. 
> Our workstations ( mostly Windows and some Mac ) are in certain networks. 
> Only these networks are allowed to do dynamic DNS updates. So when a PC is 
> switched on its IPv4, IPv4 reverse, IPv6 and reverse is registered. 
> 
> So far everything works well. 
> 
> Is there a way to configure, that names which are registered in other 
> networks, are not allowed to be updated ? 

You'll have to explain what you mean better for a more specific answer,
but see the manual for the "allow-update" ACL config option
(per-zone). You can set access control on who can update the zone by
configuring this option (preferably using TSIG key, but also network
ACL). Adjust your zones, ACLs and services appropriately.

Mukund
___
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 validation without current time

[Mukund Sivaraman]

On Fri, Dec 15, 2017 at 12:45:11PM +0100, Petr Menšík wrote:
> Hi folks.
> 
> I am looking for a way to validate name also on systems, where current
> time is not available or can be inaccurate.

I use a Garmin 18x LVC 1pps GPS receiver device connected to RS-232
serial port. The device plus cables cost me $70 altogether, and ntpd
works natively with it using the NMEA refclock driver (there's no need
of gpsd). It has a 1s PPS signal accurate to 1us. It is accurate to
within +/- 100us on Fedora where due to no hardpps kernel support
because of tickless kernel, the PPS signal is timestamped and available
on /dev/pps0 but the kernel doesn't use it to directly maintain the
clock and it has to be done from userland which is affected by the
system load.  If you were to recompile a kernel that's configured
appropriately, I feel the clock can be synchronized to about 1us
accuracy.

It is more or less reliable and value for $70 if one wants UTC on their
computer without accessing the internet. This is more than sufficient
for DNSSEC validation and many other network services, and certainly
more accurate than using the ntp.org pools.

Mukund
___
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: EDNS0 client subnet in BIND 9.10

[Mukund Sivaraman]

I'm not sure how ECS would be useful for load-balancing, as in the best
case scenario it would require one to control every client side to send
the client-subnet option.

On Fri, Nov 10, 2017 at 04:44:10PM +, Tony Finch wrote:
> Ben Croswell  wrote:
> >
> > I have looked through the ARM and found references to setting the option in
> > a dig. However I was not able locate options for sourcing that option on
> > the DNS server.
> 
> BIND currently supports ECS on authoritative servers in ACLs for selecting
> views.

This is broken and not recommended for production use.

Mukund
___
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: Differences Between Recursion Desired and Recursion Available

[Mukund Sivaraman]

On Fri, Oct 06, 2017 at 08:11:56AM +, Harshith Mulky wrote:
> What I am not able to understand is, What would happen when resolver
> does not set Recursion Desired bit in the query it sends?
> 
> If Recursion is supported on the server, Would the server do the
> Referral Queries and set the RA bit while sending Response?
> 
> If Recursion is not supported on the server, Would the Referral Query
> fail from the resolver?
> 
> Please can anybody give any pointers in this case?

These can be found in RFC 1034. See 4.3.2 on the nameserver algorithm,
that'll take you to 5.3.3 when RD=1 and the nameserver provides
recursion.

Mukund
___
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 serial increment when we update SOA RR

[Mukund Sivaraman]

On Wed, Oct 04, 2017 at 11:43:18AM +0100, Tony Finch wrote:
> rams  wrote:
> >
> > When we change any resource record like A or , then SOA serial number
> > gets incremented. But If we update only SOA record ,Is serial number of SOA
> > remain same as before or serial number of SOA will increment?.
> 
> It needs to increment, yes, because that's how the secondaries know they
> need to update their copies of the zone.
> 
> > Do we have any RFC for this?
> 
> I don't know if this particular case is mentioned explicitly, but you can
> look at RFC 1995 (IXFR) and RFC 5936 (AXFR).

Also please read RFC 1982, specifically section 7 (The DNS SOA serial
number) on what to keep in mind when updating the serial number.

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

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

Re: Logging resolved IP

[Mukund Sivaraman]

On Tue, Sep 19, 2017 at 05:16:36PM +0200, Job wrote:
> Hi guys,
> 
> is there a way to log resolved IP in Bind log files?
> Example:
> www.google.com 4.3.2.1
> 
> I am able to do it with tcpdump, but i do not like a "sniffering" solution!

Turn up logging level to over 10, such as named -d 11. It will then log
messages exchanged on the wire in 'dig output format'.

Mukund
___
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: What is wrong with my second $ORIGIN

[Mukund Sivaraman]

On Thu, Sep 14, 2017 at 07:02:52AM +, Harshith Mulky wrote:
> Whats wrong with my second $ORIGIN here:
> 
> 
> $ORIGIN lab.example.com.
> $TTL 1d
> @ IN  SOA colombo root.lab.example.com.  (
>   2003022720 ; Serial
>   56800  ; Refresh
>   14400  ; Retry
>   360; Expire
>   2h ); Min
> 
> ;NS Records
> @  IN  NS  ns1.lab.example.com.
> @  IN  NS  ns2.lab.example.com.
> mail   IN  NS  ns1.mail.lab.example.com

Missing a trailing period(.)

"ns1.mail.lab.example.com" is not an absolute
name. "ns1.mail.lab.example.com." is absolute.

Mukund
___
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 validation issue

[Mukund Sivaraman]

Hi Ganga

On Thu, Aug 24, 2017 at 09:33:32AM +0600, Ganga R. Dhungyel wrote:
> With dnssec-validation turned on, resolving sites like www.icann.org
>  fails. The alternative is to remove validation
> which of course is not the desired solution.

Are you able to reproduce the bug with the latest stock version of BIND
9.9?  9.9.4 is very old and that branch has had numerous bugfixes since.

I'm not able to reproduce such a validation failure with 9.9.11:

[muks@jurassic bind9]$ bin/dig @127.0.0.1 -p 53000 www.icann.org

; <<>> DiG 9.9.11 <<>> @127.0.0.1 -p 53000 www.icann.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28837
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.icann.org. IN  A

;; ANSWER SECTION:
www.icann.org.  3497IN  CNAME   www.vip.icann.org.
www.vip.icann.org.  30  IN  A   192.0.32.7

;; Query time: 464 msec
;; SERVER: 127.0.0.1#53000(127.0.0.1)
;; WHEN: Wed Aug 30 18:59:51 IST 2017
;; MSG SIZE  rcvd: 80

[muks@jurassic bind9]$

Both dig and named are from BIND 9.9.11. AD bit is set indicating
validation was performed.

Mukund
___
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.11.1-P3 revives expired zones briefly during reconfig

[Mukund Sivaraman]

On Sun, Aug 06, 2017 at 08:07:51PM +0200, Anand Buddhdev wrote:
> On 06/08/2017 13:49, Mukund Sivaraman wrote:
> 
> Hi Mukund,
> 
> > Which exact version of 9.11 is this? Is their master NSD or some 3rd
> > party signer? Can you create a bug ticket with your named config
> > (named-checkconf -px) ?
> 
> As I wrote in the subject, it's BIND 9.11.1-P3. The masters of these

Sorry Anand, I missed that :)

> name servers are unknown, but I can attempt to probe them with
> ch/txt/version.bind queries to try and find out.

I wonder if the zones on the slaves expired because the slave was not
able to XFR them. After the recent TSIG CVE, for about a week, we had a
(non-security) bug in BIND due to which named didn't correctly validate
a kind of TSIG signed AXFR/IXFR (specifically BIND as slave receiving
from NSD as master was affected by the bug - due to BIND's fault). It
was fixed soon after in another patch release.

9.11.1-P3 has the fix for this, but I wonder if the older 9.10 release
that you were running had this bug that prevented successful transfers
of the slave zones that caused them to expire, which cause them to be
unloaded on startup.

Or there could be some other reason. :)

> Will the bug report be publicly viewable?

You can send it to bind9-confident...@isc.org.

Mukund
___
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.11.1-P3 revives expired zones briefly during reconfig

[Mukund Sivaraman]

Hi Anand

On Sun, Aug 06, 2017 at 09:30:01AM +0200, Anand Buddhdev wrote:
> Hello BIND developers,
> 
> I've updated from BIND 9.10 to 9.11, and noticed the following happening
> whenever "rndc reconfig" is run:
> 
> 05-Aug-2017 11:11:42.066 general: received control channel command
> 'reconfig'
> 05-Aug-2017 11:11:42.066 general: loading configuration from
> '/etc/named/named.conf'
> ...
> ...
> 05-Aug-2017 11:11:42.525 general: zone 116.195.in-addr.arpa/IN/main:
> loaded serial 2017020301
> 05-Aug-2017 11:11:42.525 general: zone 116.195.in-addr.arpa/IN/main: expired
> 05-Aug-2017 11:11:42.533 general: zone egouv.ci/IN/main: loaded serial
> 2017062009
> 05-Aug-2017 11:11:42.606 general: zone 232.128.in-addr.arpa/IN/main:
> loaded serial 2017071557 (DNSSEC signed)
> 05-Aug-2017 11:11:42.638 general: zone 43.137.in-addr.arpa/IN/main:
> loaded serial 2017071100
> 05-Aug-2017 11:11:42.638 general: zone 43.137.in-addr.arpa/IN/main: expired
> 05-Aug-2017 11:11:42.639 general: any newly configured zones are now loaded
> 05-Aug-2017 11:11:42.639 general: zone egouv.ci/IN/main: expired
> 05-Aug-2017 11:11:42.646 general: zone 232.128.in-addr.arpa/IN/main: expired
> 05-Aug-2017 11:11:42.659 general: running
> 
> For a moment, BIND loads expired zones, and even answers queries for
> them, and then sets their state back to expired. This didn't happen on
> 9.10, but has been happening on 9.11. Is there a reason this behaviour
> has changed?

Which exact version of 9.11 is this? Is their master NSD or some 3rd
party signer? Can you create a bug ticket with your named config
(named-checkconf -px) ?

Mukund
___
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 - Domain resolution failed

[Mukund Sivaraman]

> root@recursivo-a:~# dig icap-to.com.br
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> icap-to.com.br
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32316
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;icap-to.com.br.IN  A
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Tue Jul 18 10:41:59 BRT 2017
> ;; MSG SIZE  rcvd: 43

> root@recursivo-a:~# /etc/init.d/bind9 restart
> [ ok ] Restarting bind9 (via systemctl): bind9.service.
> 
> 
> root@recursivo-a:~# dig icap-to.com.br
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> icap-to.com.br
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65065
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;icap-to.com.br.IN  A
> 
> ;; ANSWER SECTION:
> icap-to.com.br. 14400   IN  A   192.185.216.81

Notice that the TTL of the address record is 14400, which is 4 hours.

> ;; AUTHORITY SECTION:
> icap-to.com.br. 86400   IN  NS  ns2.desenvolvesistemas.com.
> icap-to.com.br. 86400   IN  NS  ns1.desenvolvesistemas.com.

The nameservers in the NS records in the zone do not exist, so when BIND
goes to refetch the answer after TTL expiry, it doesn't find the
nameservers and fails.

For the original resolution, the parent nameserver returns:

[muks@jurassic bind9]$ bin/dig @d.dns.br icap-to.com.br.

; <<>> DiG 9.12.0-pre-alpha <<>> @d.dns.br icap-to.com.br.
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33669
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;icap-to.com.br.IN  A

;; AUTHORITY SECTION:
icap-to.com.br. 86400   IN  NS  ns84.prodns.com.br.
icap-to.com.br. 86400   IN  NS  ns85.prodns.com.br.

;; Query time: 312 msec
;; SERVER: 200.219.154.10#53(200.219.154.10)
;; WHEN: Tue Jul 18 20:04:24 IST 2017
;; MSG SIZE  rcvd: 88

[muks@jurassic bind9]$ 

Tip: When you have failures with resolution, turn up named logging level
and check the logged messages.

Mukund
___
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: RPZ zone name label length limit

[Mukund Sivaraman]

Hi Jim

On Thu, Jun 29, 2017 at 01:57:16PM +, Jim Yang wrote:
> Hi,
> 
> What is the DNS name label length limit? As per RFC 1035, it is 63
> characters.  I tested a few DNS names that contains a label that is
> longer than 63 characters, and found that these records were
> successfully loaded in RPZ zone. I wonder if this is a BIND RPZ
> feature or bug (it allows DNS name label that is longer than 63
> characters)?
> 
> When I dig these DNS records using 8.8.8.8, which reports them as
> ‘NXDOMAIN’.

Can you send us a bug report with a sample RPZ zone that contains such a
name?

Mukund
___
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: Can a NAPTR query over TCP contain OPT section in Additional Records

[Mukund Sivaraman]

Hi Harshith

On Thu, Jun 22, 2017 at 05:36:12AM -0700, Harshith Mulky wrote:
> Client
> DNS
> EDNS query, buffer size=4096
>  --->
> 
>DNS Response, Truncation bit set (TC=1)
> <---
> 
>   DNS Query over TCP
> --->
> 
>  DNS Response over TCP
> <--
> 
> In the above Call Scenario, I have the Client supporting, edns Buffer
> Size=4096. and on the server, I have enabled this: to limit the server
> sending > 512 bytes in Response
> 
> server 0.0.0.0/0  {
> edns yes;
> edns-udp-size 512; //max size query sever can receive is upto 4096
> bytes(default value=4096 )
> max-udp-size 512; //max size server can transfer is upto 4096
> bytes(default value =4096)
> };

It is not clear what it is you're trying to achieve from the config
block above, but it isn't a good idea to limit to 512 for /0.

> The EDNS query is OK, the response is also OK
> 
> The question is regarding the DNS Query over TCP,
> Can the DNS Query over TCP include the OPT RR section, is this not
> Applicable to only UDP? is there any RFC which supports OPT RR section for
> query over TCP

Yes, the OPT RR carries other information and EDNS options between
client<->nameserver. E.g., without the OPT RR, how will a client tell
the nameserver that DNSSEC is OK (DO=1) ?

> Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)

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

[Mukund Sivaraman]

On Thu, Apr 20, 2017 at 04:03:21PM +0100, Chris Thompson wrote:
> On Apr 20 2017, Tony Finch wrote:
> 
> > Mark Andrews  wrote:
> > > 
> > > DSA requires random values as part of the signing process.
> > 
> > Traditionally, yes, but it isn't actually required -
> > https://tools.ietf.org/html/rfc6979
> 
> There is a great deal to be said for using deterministic DSA even if
> your random number source is both trustworthy and fast.
> 
> The EdDSA standards (RFCs 8032 & 8080) mandate deterministic signatures
> and this is certainly intentional. Of course, there are also many other
> ways in which they are improvements on the earlier NIST-based ECDSA
> standards, and we should all be looking forward to the time when BIND,
> inter alia, supports them...

As there's some discussion on use of entropy during signing, allow me to
talk about other draft RRSIG algorithms.

When preparing support for SHA-3 algorithms, the RSASSA-PSS signature
scheme was chosen for RSA RRSIGs as it is a more robust scheme than
RSASSA-PKCS1-v1_5:

https://tools.ietf.org/html/draft-muks-dnsop-dnssec-sha3-01

Unlike the existing RSA DNSKEY/RRSIG algorithms, RSASSA-PSS uses a
"salt" input (per signature), but we made its randomness requirement a
"SHOULD" in the draft. This allows signing in environments where an
entropy source is not available, however, where one is available, a PRNG
ought to be sufficient for signing purposes. The non-randomness of the
salt is not crucial (see full domain hash vs. RSA PSS in "The Exact
Security of Digital Signatures - How to Sign with RSA and Rabin",
Bellare and Rogaway.) However, with a random salt, the scheme has exact
security and a similar security guarantee is achieved with a smaller RSA
modulus size.

The draft also covers ECDSA(SHA-3()).

Mukund


signature.asc
Description: PGP signature
___
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: Latest BIND on Debian 8.7 (jessie) crashed due to assertion failure

[Mukund Sivaraman]

Hi Carlos

On Thu, Apr 20, 2017 at 12:54:47AM -0300, Carlos Pizarro wrote:
> Today the bind9 service crashed and this were the last few log lines when
> it happened:
> 
> Apr 19 20:46:23 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN':
> 2400:cb00:2049:1::c629:defe#53
> Apr 19 20:46:23 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN': 64.68.192.10#53
> Apr 19 20:46:23 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN': 198.41.222.254#53
> Apr 19 20:46:23 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN': 64.68.196.10#53
> Apr 19 20:46:24 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN':
> 2400:cb00:2049:1::a29f:1835#53
> Apr 19 20:46:24 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN':
> 2400:cb00:2049:1::c629:defe#53
> Apr 19 20:46:24 host named[32115]: error (unexpected RCODE REFUSED)
> resolving 'heroditus.touchtype-systems.com/A/IN': 198.41.222.254#53
> Apr 19 20:46:24 host named[32115]: resolver.c:4350: INSIST(fctx->type ==
> ((dns_rdatatype_t)dns_rdatatype_any) || fctx->type ==
> ((dns_rdatatype_t)dns_rdatatype_rrsig) || fctx->type ==
> ((dns_rdatatype_t)dns_rdatatype_sig)) failed, back trace
> Apr 19 20:46:24 host named[32115]: #0 0x7f4aebd27a00 in ??
> Apr 19 20:46:24 host named[32115]: #1 0x7f4ae9f038ea in ??
> Apr 19 20:46:24 host named[32115]: #2 0x7f4aeb5e914e in ??
> Apr 19 20:46:24 host named[32115]: #3 0x7f4ae9f25d5b in ??
> Apr 19 20:46:24 host named[32115]: #4 0x7f4ae98d6064 in ??
> Apr 19 20:46:24 host named[32115]: #5 0x7f4ae92a462d in ??
> Apr 19 20:46:24 host named[32115]: exiting (due to assertion failure)
> 
> ( Same log on Pastebin https://pastebin.com/a1K0L3wJ )
> 
> 
> Looking at the code line where it crashed I thought that it was related
> to CVE-2016-9131 but it was patched already on this Debian build:
> 
> http://metadata.ftp-master.debian.org/changelogs/main/b/bind9/bind9_9.9.5.dfsg-9+deb8u10_changelog
> 
> 
> Does anyone has any insight on what may be happening? I'm trying to avoid
> backporting the newest BIND from Stretch but I would if this won't happen
> on that version but I'm unsure as changelog seems to be quite similar to
> the changelog of my version:
> 
> http://metadata.ftp-master.debian.org/changelogs/main/b/bind9/bind9_9.10.3.dfsg.P4-12.1_changelog

This should be covered by the fix for CVE-2017-3137. See the following link:

https://security-tracker.debian.org/tracker/CVE-2017-3137

Mukund


signature.asc
Description: PGP signature
___
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: NTA (Negative Trust Anchor) lifetime

[Mukund Sivaraman]

Hi Miguel

On Tue, Feb 14, 2017 at 01:17:00PM -0200, Miguel Mucio Santos Moreira wrote:
> Hi folks
> 
> 
> I'd like to know if it's possible to use NTA (Negative Trust Anchor) in a way 
> I can set it's lifetime as unlimited for a specific domain.
> I have a situation that will be necessary to keep this kind of configuration 
> at least for 3 months.

RFC 7646 caps NTA lifetime to a maximum of 1 week.

You can always patch the source code if you have a need and want to
break RFC.

Mukund


signature.asc
Description: PGP signature
___
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 goes rogue and revert zone information

[Mukund Sivaraman]

Hi Raul

On Tue, Feb 07, 2017 at 12:03:40PM -0200, Raul Dias wrote:
> Hello,
> 
> I have a very strange behavior that I am failing to understand.
> 
> 2 to 5 times a week, a named server revert back to a previous version os a
> master zone.
> This happens during the night, usually around 20h EST.
> 
> This zone has a serial of 3017020401 (yes, I typo the 3 somewhere in the
> past).
> When it reverts its zone information, it goes back to 3016060101.
> 
> I have updated, restarted the host, clean all cache and journal files, grep
> all files in the host for 3016060101 (just shows up in the logs).
> 
> So, I have no clue why, or how it is happening. Where does it get the old
> information.
> 
> I thought first about the serial, but it would have happened in the past
> too, right?  As it should be a 32bit unsigned integer, it shouldn't be a
> problem, IMHO.
> 
> Yet, when "dig domain -t SOA @server", it is there again.
> 
> The host is a debian Jessie and bind is 9.9.5, 1:9.9.5.dfsg-9+deb8u8 more
> specifically.

When you say "When it reverts its zone information", how are you
observing it? Are you reading the master file from disk to check what's
in it, or are you doing a dig for the SOA record to check the serial?
By this, I'm asking if your master file is in sync with the journal if
you're reading it directly (rndc sync).

After the zone has a serial of 3017020401, is it updated in any way?  Do
you run any rndc commands against the nameserver during this time?

Is the serial value 3016060101 of any significance? You say it "reverts
back to a previous version". Was 3016060101 a previously observed
serial? What happens to the contents of the zone? Are the contents the
same, or do they appear to have older data?

When you clean journal files, have they been sync'd into the master
file?

You mention again "get the old information".. does it mean that you
noticed that the zone contains old data? How are you checking the
contents? Directly by reading the master file or via query?

Can you send the output of named-checkconf -px for your named config?
If you want details to be private, you can create a bug ticket by
mailing it to .

Mukund


signature.asc
Description: PGP signature
___
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

[Mukund Sivaraman]

On Fri, Feb 03, 2017 at 08:51:01AM -0600, Alan Clegg wrote:
> On 2/3/17 8:01 AM, Mukund Sivaraman wrote:
> 
> > We have the debug log level, but consider the case when an operator has
> > a non-deterministic or rare crash that isn't reproducible because the
> > operator has no information about what caused it. All we have is the
> > config, log that was already generated before the crash and perhaps a
> > backtrace and core to deduce the steps leading to the crash. It's not
> > possible to re-run that scenario with debug logging.
> > 
> > I'll create a ticket to put the client pointer at the end if that'll
> > help, but note that the syntax in 9.10 was not consistent either. 9.10
> > would log the client pointer when the client object didn't have a valid
> > peer.
> 
> Adding code to allow enabling or disabling this output on the fly would
> work MUCH better (as an example, see "rndc querylog"/ options "querylog
> [on | off ]").
> 
> Adding a "well, we needed this one time" value to the middle of a
> long-standardized log file does no customer any good and inconveniences
> everyone.
> 
> You own the code and can do whatever you want to, but I'd recommend
> making the default log message what it was prior to 9.10 and adding
> additional fields via pre-configuration and "rndc".

We may move it to the end of the log message (bugs ticket #44606 has
been created for looking at it). Maybe its location was poor.. please
can everyone who participated in this thread say whether having it at
the end will be ok?

The query log is getting more fields at the end of it such as
CLIENT-SUBNET logging.

Making it a configurable option misses the reason it is the way it is -
please see the first paragraph quoted above.

This seems to be a case where having it is inconvenient, and not having
it is inconvenient.

Mukund


signature.asc
Description: PGP signature
___
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

[Mukund Sivaraman]

Hi John

On Fri, Feb 03, 2017 at 01:43:50PM +, MURTARI, JOHN wrote:
> Folks at ISC,
> 
> > I agree, there are an awful lot of systems and SIEM products that
> > process querylogs. This one change will require a huge amount > of
> > re-engineering work in customer environments.
> 
>   You know we love you and the work you do!  But changing that log
>   format was really a bad idea.  I saw your original response that
>   we should report it as a 'bug' and it was added so you could
>   help us debugging problems.
> 
>   IMHO -- it's not a bug (in the classic sense), it was an
>   intentional change.  Regarding needing more info for debug, I'd
>   encourage the approach a lot of tools take: add a debug option
>   to the config, start params, etc... to activate the feature.

We have the debug log level, but consider the case when an operator has
a non-deterministic or rare crash that isn't reproducible because the
operator has no information about what caused it. All we have is the
config, log that was already generated before the crash and perhaps a
backtrace and core to deduce the steps leading to the crash. It's not
possible to re-run that scenario with debug logging.

I'll create a ticket to put the client pointer at the end if that'll
help, but note that the syntax in 9.10 was not consistent either. 9.10
would log the client pointer when the client object didn't have a valid
peer.

Mukund


signature.asc
Description: PGP signature
___
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 RPZ triggers

[Mukund Sivaraman]

Hi ard

On Fri, Jan 27, 2017 at 08:51:14PM +, der...@mskcc.org wrote:
> Hi All,
> 
> Back in December 2016, I worked on a problem in which a particular hostname 
> (a website) would not resolve from our DNS servers, but Level3, Google DNS, 
> and OpenDNS resolved it.  It was clear that somewhere outside our network 
> there was policy (security or otherwise) that prevented us from getting the 
> resolution.  It was not easy to get the website owners to work on this from 
> their side, but eventually the problem was corrected.  How this case is 
> relevant to bind-users is that we implement RPZs and I had hoped that I could 
> add the hostname to the RPZ zone and return to clients the IP that I knew was 
> correct (from Level3, OpenDNS).  However, I was told by our vendor that that 
> was no possible because RPZs only trigger when there is an actual resolution 
> for the queried A record.
> 
> Doing some reading today, I came across Paul Vixie's (creator of DNS RPZ) 
> article "What are the features of the DNS RPZ firewall?" on the ISC.org site 
> (https://deepthought.isc.org/article/AA-00516/0).  There he lists the 
> triggers that a DNS RPZ honors.  Here is the section:
> 
> In a DNS firewall based on DNS RPZ, each rule can use one of four policy 
> triggers and specify one of four policy actions.
> 
> A response policy in DNS RPZ can be triggered as follows:
> 
>   1.  by the query name.
>   2.  by an address which would be present in a truthful response.
>   3.  by the name or address of an authoritative name server 
> responsible for publishing the original response.
> 
> So, there it is: trigger 1 is what I was looking for.
> 
> Our DNS platform is BIND based, and I don't understand why the vendor's 
> implementation (mostly ISC code from my understanding) does not comport 
> itself according to Paul Vixie's specs above.  Instead it has added a 
> dependency in which the server must receive a response in order for a 
> response policy action to be triggered.

It is not clear which "vendor's implementation" you're talking about,
but in this case you ought to contact the vendor if it is not ISC, and
not this list. This list is about vanilla BIND.

In vanilla BIND, see the "qname-wait-recurse" option.

Mukund


signature.asc
Description: PGP signature
___
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

[Mukund Sivaraman]

Hi Michael

On Wed, Jan 25, 2017 at 09:11:41AM -0500, Michael Dahlberg wrote:
> Mukund:
> 
> Yea, I can respect that.  However, I'm not confident that dropping it right
> in the middle of the log entry was the best place for it.  I have a number
> of processes that monitor the query logs (it seems like everybody wants to
> know where everybody else is going), and these logs can get BIG.  To
> ameliorate the amount of data that needs to be parsed, I throw out  the
> queries from systems that are not relevant.  With that single entry,
> everything became relevant according to my regex.  Making this addition to
> the beginning or the end of the log entry would have provided the
> developers the necessary data, and preserved my regex.

If you don't mind, can you send an email to  with
the format you'd like it to be in?

The only feedback we got for this change was this: By mistake, we had
introduced this change within an existing stable branch which broke
scripts for some users who understandably didn't expect such a change
within a stable release, whereas the change should have appeared only in
a new release branch made off master (in this case, master -> 9.11
only). If there's a feeling that some change is not up to the mark or
can be done differently, please file a bug and let us know.

(IIRC, the previous format was not consistent too.)

Mukund


signature.asc
Description: PGP signature
___
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

[Mukund Sivaraman]

On Wed, Jan 25, 2017 at 08:37:45AM -0500, Alan Clegg wrote:
> On 1/25/17 7:44 AM, Steven Carr wrote:
> > On 25 January 2017 at 10:59, Tony Finch  wrote:
> >> It's the address in memory of the data structure representing the client.
> >> It is mentioned in the CHANGES file (#4471) and in the release notes - see
> >> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c4b7db49326be650fa95a7ede6e066bbe1268561
> >>
> >> though the pointer field first turned up in
> >> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=a26a62cef2adba0520c5955d740fc75fa7f2c7f5
> > 
> > Question back to the BIND team... why? what is the purpose of having
> > this value exposed in query logs? what exactly is it adding? If it was
> > a debug log then I can understand the need to have the memory address
> > exposed, but for the "regular" user what is the use case?
> 
> BIND is always in debug mode, even when it's not in debug mode.
> 
> I find this addition to the log to be annoying and useless in 99% of
> actual end-user use cases.

Rememeber that not only users, but even us developers have to look at
your logs when you send them to us.

When things are fine, the sun is shining, hay is growing.. all's fine,
and the fields in the log format that a user wants are sufficient.

When one out of numerous deployments of BIND reports a crash, and we're
not able to reproduce it, all we have is the effects that the reporter
can provide us. named is asynchronous software with numerous concurrent
wheels chugging, with some shared datastructures and non-shared request
specific structures.  When things go bad, they show up as bad sometimes
a long time after the fact. If we are not able to reproduce it, looking
at logs and attempting to reconstruct what happened is like looking for
a needle in a haystack.  In such cases, we find these bits of extra
information useful. Users may not like an extra field, but please bear
with us because it is helpful when things go bad.

This specific client pointer was useful in debugging such an issue and
that's why it was permanently added to the log.

Mukund


signature.asc
Description: PGP signature
___
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

[Mukund Sivaraman]

On Wed, Jan 25, 2017 at 12:44:21PM +, Steven Carr wrote:
> On 25 January 2017 at 10:59, Tony Finch  wrote:
> > It's the address in memory of the data structure representing the client.
> > It is mentioned in the CHANGES file (#4471) and in the release notes - see
> > https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=c4b7db49326be650fa95a7ede6e066bbe1268561
> >
> > though the pointer field first turned up in
> > https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=a26a62cef2adba0520c5955d740fc75fa7f2c7f5
> 
> Question back to the BIND team... why? what is the purpose of having
> this value exposed in query logs? what exactly is it adding? If it was
> a debug log then I can understand the need to have the memory address
> exposed, but for the "regular" user what is the use case?

When debugging problems, we look at logs. The pointer value is like a
tag or label that uniquely identifies the client object. Client objects
are recycled (reused) in named, and we look for their "identity" to
separate them from others.

Mukund


signature.asc
Description: PGP signature
___
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: Reasons to upgrade?

[Mukund Sivaraman]

On Wed, Jan 18, 2017 at 08:02:04AM -0700, lbutlr wrote:
> It looks like there are three version of Bindcurrently supported,
> 9.9.9, 9.10, and 9.11.
> 
> Are there specific reasons to move from 9.9 to 9.10 or 9.11 other than
> the usual "it's newer and you're going to have to move at some point
> anyway"?

See:

https://kb.isc.org/article/AA-01432/0/BIND-9.11.0-Release-Notes.html

Mukund


signature.asc
Description: PGP signature
___
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.11.0 RPZ performance issue

[Mukund Sivaraman]

Hi Bob

On Tue, Oct 18, 2016 at 03:26:00PM -0400, Bob Harold wrote:
> On Tue, Oct 18, 2016 at 3:26 AM, Mukund Sivaraman <m...@isc.org> wrote:
> 
> >
> > Firstly, RPZ in BIND 9.9 (vanilla) is broken, unmaintained and should
> > not be used by anyone. If you know people using BIND 9.9 (vanilla) for
> > RPZ, please ask them to upgrade to 9.10 at least. RPZ in 9.9
> > subscription branch is OK.
> >
> >
> Is RPZ in BIND 9.8 ok to use?  (Using RedHat 9.8.2 plus they backport
> security patches.)

BIND 9.8 is not OK to use according to us for any purpose. It has
reached end-of-life.

Some distros insist on continuing to ship obsolete versions of BIND with
maintenance patches that include mainly publicly known security
bugfixes, but still containing security and other bugs that have long
been fixed in current BIND versions. These distributions have their
reasons to do so, but the point remains that such obsolete versions of
BIND are buggy and unsupported by us.

(What's worse is that such bug reports are sent to us and waste our
developer time which is quite limited as-is, because we have to look at
crash reports and such to ensure that current versions of BIND don't
suffer from it.)

If you are using a non-current version of BIND (currently maintained
public versions are the latest versions in the 9.9, 9.10 and 9.11
series), then:

(a) contact whoever's providing/supporting that package for support.

(b) switch to a current version of BIND (preferred).

Mukund


signature.asc
Description: PGP signature
___
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.11.0 RPZ performance issue

[Mukund Sivaraman]

Hi Phil

On Tue, Oct 18, 2016 at 09:15:45AM +0100, Phil Mayers wrote:
> On 18/10/16 08:26, Mukund Sivaraman wrote:
> 
> > We know that IXFR with RPZ policy zones (esp. this DBL zone) causes some
> > trouble due to a less than desirable design / implementation of RPZ in
> > BIND. We have a plan to refactor the RPZ implementation for 9.12 to
> > remove these inefficiencies.
> 
> Can you share some details on that? Because I've reported issues triggered
> by an XFR of a large RPZ, specifically the Spamhaus DBL, and I've been
> variously pooh-poohed and/or told "no-one else has ever reported that".

That should not happen (the pooh-poohing). Please let me know the
details of this. Every report is looked at esp. when it is accompanied
by details (logs, config summary, technical description of the problem,
etc.).

> I'm particularly interested if you're aware of a failure mode where
> CPU usage can spike MASSIVELY during a large-ish IXFR and cause named
> to start dropping queries.

I can't quantify "MASSIVELY" or "failure mode", but in general, yes
there is a known regression in query and transfer performance specific
to a configuration where RPZ is used and its policy zone is involved in
an IXFR, during the transfer. (This problem was discovered a few months
ago due to a customer's report.) Specifically, the Spamhaus DBL is one
such zone which we have heard problem reports for.

Please provide details of the problems you've faced, even if this is not
related to RPZ.

Mukund


signature.asc
Description: PGP signature
___
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.11.0 RPZ performance issue

[Mukund Sivaraman]

Hi Daniel

On Tue, Oct 18, 2016 at 09:08:37AM +0200, Daniel Stirnimann wrote:
> It currently looks like that only having the spamhaus rpz zones active
> causes the occasional timeouts. Maybe it's related to the zone size as
> dbl.rpz.spamhaus.org is quite large. If i/o performance on the virtual
> hosts turn out to be a problem then masterfile-format map; looks not
> like a good solution as this increases the zone file on disk by a factor
> of about 4.

Firstly, RPZ in BIND 9.9 (vanilla) is broken, unmaintained and should
not be used by anyone. If you know people using BIND 9.9 (vanilla) for
RPZ, please ask them to upgrade to 9.10 at least. RPZ in 9.9
subscription branch is OK.

We know that IXFR with RPZ policy zones (esp. this DBL zone) causes some
trouble due to a less than desirable design / implementation of RPZ in
BIND. We have a plan to refactor the RPZ implementation for 9.12 to
remove these inefficiencies.

As a workaround, may I suggest using AXFR for policy zone transfers to
see if that helps you, also ratelimiting the transfers to occur less
frequently than the rate of notifies you get for the policy zone. AXFR
transfer is actually more expensive than IXFR, but under the hood, it
avoids some contention that occurs with IXFR (updates) vs. queries to
the same zone in the query path. AXFR will not be able to keep up with
the rapid churn in the dbl.rpz.spamhaus.org, so you'll have to ratelimit
it too.

If this doesn't help, please contact me off this list and we'll follow
up.

Mukund


signature.asc
Description: PGP signature
___
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: Master/Slave communication not working if I use HMAC-SHA* algorithms when views are implemented

[Mukund Sivaraman]

Hi Nagesh

On Fri, Oct 14, 2016 at 11:00:24AM +0530, Nagesh Thati wrote:
> Hi,
>
> Can anybody implemented master/slave communication with views and algorithm
> HMAC-SHA* algorithms. I tried with all the HMAC-SHA* algorithms it didn't
> work for me, only HMAC-MD5 algorithm worked for communication. If anybody
> has any idea please help me.
> Thanks.

TCPWave seems to:

(1) Integrate BIND in product/service and benefit commercially from it

(2) Doesn't support upstream BIND's development by purchasing a support
subscription, even though TCPWave seems reliant on BIND being developed
actively

(3) Paints BIND poorly on its webpages, even though your product/service
uses BIND: http://www.tcpwave.com/tcpwave-managed-dns/

(4) Comes to us for help when it is not able to figure out something

The last time this happened, we were reported a memory leak bug in ISC
BIND by TCPWave that we were pushed by TCPWave to prioritize because you
couldn't keep up a server for more than a day. After we spent
considerable engineering time and helped you find the cause, the
reporter admitted that the bug was due to changes that you had made to
BIND. Our engineering team's time was wasted by it.

Ask your management to contact ISC's sales team to buy a support
subscription as it would be better for both organizations:

https://www.isc.org/bind-subscription-2/

(The work we do costs money too. We are programmers, support and QA
engineers who need salaries too.)

Mukund


signature.asc
Description: PGP signature
___
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: replicate a whole master

[Mukund Sivaraman]

On Mon, Sep 19, 2016 at 04:40:17PM +0100, Tony Finch wrote:
> /dev/rob0  wrote:
> >
> > If you're thinking that you can do this replication to improve DNS
> > performance, you're right, it will do that.  But it certainly will
> > not scale (if it's even possible to get axfr/ixfr), and it won't
> > handle modern CDN systems properly.
> 
> BIND 9.10 and later will keep popular domains in the cache by prefetching
> them if they are looked up shortly before they will expire. So trying to
> keep local copies of popular zones is less helpful than it used to be.
> 
> (Unfortunately the prefetch option isn't mentioned in the HISTORY file so
> I had to dig through the CHANGES to remind myself when it was introduced!)

There's an attempt to make it go one step further by refreshing whole
zones in the cache:

https://github.com/muks/dnsrefresh

It needs another section to be completed before upload, possibly in time
for IETF-97.

Mukund


signature.asc
Description: PGP signature
___
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: Organization IP address is getting redirected to a website which does not belong to the organization.

[Mukund Sivaraman]

On Sat, Sep 17, 2016 at 03:51:00PM +, Bhangui, Sandeep - BLS CTR wrote:
> Hi
> 
> Not exactly sure whether this is a DNS issue but hoping someone here on this 
> forum can provide some advice/suggestion as I am trying to figure out what is 
> going on.
> 
> Our organization BLS owns ( registered with the registrar )  the network 
> address 146.142.xxx.xxx.
> 
> But if someone  from the Internet [ outside of BLS network )  tries to go to 
> "http://146.142.7.113;   it gets redirected to a site in UK called 
> "us.watcheezy.com" 
> 
> I have checked the DNS from the BLS  side and we do not have any entry of  
> any kind for  the record  146.142.7.113 on our DNS. 
> 
> I have also done DNS lookups for watcheezy.com and those seem to be good too 
> with respect to IP and the NS and as to what those NS are reporting.
> 
> Can anyone throw some light on as to what is going on here.does not look 
> like a DNS issue to me but I could be wrong.


[muks@jurassic ~]$ wget --debug http://146.142.7.113
DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /home/muks/.wget-hsts
URI encoding = ‘UTF-8’
Converted file name 'index.html' (UTF-8) -> 'index.html' (UTF-8)
--2016-09-17 21:28:13--  http://146.142.7.113/
Connecting to 146.142.7.113:80... connected.
Created socket 3.
Releasing 0x564b513bd220 (new refcount 0).
Deleting unused 0x564b513bd220.

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: 146.142.7.113
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response... 
---response begin---
HTTP/1.1 302 Found
Date: Sat, 17 Sep 2016 16:26:06 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.4.9-4ubuntu2.3
location: http://www.watcheezy.com/
Vary: Accept-Encoding
Content-Length: 0
Connection: close
Content-Type: text/html


It is a HTTP redirect (see the location: header above). Check the
configuration of the HTTP server (webserver) that's serving for this IP
address.

Mukund


signature.asc
Description: PGP signature
___
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: Latest BIND: Error "rpz_rewrite_name: mismatched summary data; continuing"

[Mukund Sivaraman]

Hi Tom

On Tue, Sep 06, 2016 at 07:37:50AM +0200, Tom wrote:
> Is there a workaround/configuration-directive not to log every request with
> this "error"? One way would be using BIND 9.9.9-P2 (because this code was
> added in 9.10.x...), but I would prefer 9.10.x.

(1) Don't use regular BIND 9.9 for RPZ. For using RPZ, please use 9.10
and higher (or 9.9 subscription branch that's available to ISC
customers). RPZ in vanilla 9.9 is unmaintained and unsupported (it was
experimental there).

(2) We'll look at tweaking this log message, but if you want to just not
see this log message, just recompile after removing the offending CTRACE
statement from bin/named/query.c. In fact, this code is normally enabled
when configured with --enable-querytrace. Do you have query tracing
configured? Is seeing this additional log message so inconvenient then?

Mukund


signature.asc
Description: PGP signature
___
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: Error running Configure with OpenSSL 1.1.0 and BIND 9.11.0rc1

[Mukund Sivaraman]

On Wed, Aug 31, 2016 at 02:02:45PM +1000, James Brown via bind-users wrote:
> System is a Mac mini (late-2009) running a new install of Mac OS X 10.11.6.
> 
> Installed OpenSSL 1.1.0 using:
> ./Configure --prefix=/usr/local shared darwin64-x86_64-cc 
> enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3
> make depend
> make test
> sudo make install
> 
> No problems encountered. Then I tried to install BIND 9.11.0rc1 with:
> 
> ./configure --with-atf
> 
> It failed with:
> 
> checking for sched_yield... yes
> checking for pthread_yield... no
> checking for pthread_yield_np... yes
> checking for sysconf... yes
> checking for libtool... no
> checking for OpenSSL library... using OpenSSL from /usr/local/lib and 
> /usr/local/include
> checking whether linking with OpenSSL works... yes
> checking whether linking with OpenSSL requires -ldl… unknown

Due to changes in OpenSSL 1.1.0, BIND doesn't support it
currently. We're in the process of adding support for it. For now, you
may use a version from the OpenSSL 1.0.2 Long Term Support series with
BIND.

Mukund


signature.asc
Description: PGP signature
___
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: Need of caching on bind server

[Mukund Sivaraman]

Hi Harshith

On Thu, Aug 25, 2016 at 04:47:03AM +, Harshith Mulky wrote:
> Hello,
> 
> 
> I am trying to understand why caching is required on the bind server,
> when the client receiving the responses would be caching based on TTL
> values.
> 
> 
> So,
> 
> Is caching required on the server, if the client is not able to cache
> such responses? Isn't it a overhead on both the client and server
> systems to cache the same responses at respective ends

Applications usually do not cache DNS records. They usually *use* DNS
data such as addresses immediately and discard the data afterwards. Of
course, there are exceptions where applications do cache DNS data but
this is not the norm.

A DNS resolver is also a DNS client that resolves answers to questions
and caches them. It is a server to a different kind of DNS client called
a stub resolver that an application uses.

> What are the possible Use cases of caching the responses at the
> Server?
> 
> What if there is a dynamic updates of Records on Server and Server
> still sends the cached Responses?

DNS resolution is a time-consuming operation. Local resolver caches help
improve performance and also reduce load on remote nameservers. Caches
also build resiliency into DNS against short disruptive conditions.

The TTL field (and some other fields) influence how long a DNS record is
valid in the cache before it expires. DNS data is weakly coherent and
data in a cache may be out of sync with changes to the corresponding
zone on an authoritative server until this data's TTL expires. This is a
normal condition.

(Similarly, DNS data on secondary nameservers may be out of sync with
changes to a zone on a primary nameserver for a period of time.)

For answers to these questions, I suggest reading RFC 1034 which
explains concepts of DNS.

Mukund


signature.asc
Description: PGP signature
___
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: creating IPv6 interface eth0 failed; interface ignored

[Mukund Sivaraman]

On Fri, Aug 19, 2016 at 11:46:36AM +0200, Wolfgang Riedel wrote:
> Hi Mukund,
> 
> yes this had been my fist assumption also but WHY should/would the
> statement "empty-zones-enable” within named.conf change the bring
> process of the network interface process?
> 
> It’s courios, right?

I suspect there's no relation. This behavior is likely
non-deterministic.

Mukund


signature.asc
Description: PGP signature
___
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: creating IPv6 interface eth0 failed; interface ignored

[Mukund Sivaraman]

On Fri, Aug 19, 2016 at 11:32:43AM +0200, Wolfgang Riedel wrote:
> ### bootup with: empty-zones-enable no;
> 
> [root@ns1 ~]# systemctl status named-chroot.service
> ● named-chroot.service - Berkeley Internet Name Domain (DNS)
>Loaded: loaded (/usr/lib/systemd/system/named-chroot.service; enabled; 
> vendor preset: disabled)
>Active: active (running) since Sat 2016-08-06 11:08:22 CEST; 16s ago
>   Process: 1084 ExecStart=/usr/sbin/named -u named -t /var/named/chroot 
> $OPTIONS (code=exited, status=0/SUCCESS)
>   Process: 1080 ExecStartPre=/bin/bash -c if [ ! "$DISABLE_ZONE_CHECKING" == 
> "yes" ]; then /usr/sbin/named-checkconf -t /var/named/chroot -z 
> /etc/named.conf; else echo "Checking of zone files is disabled"; fi (c
>  Main PID: 1086 (named)
> Tasks: 5 (limit: 512)
>CGroup: /system.slice/named-chroot.service
>└─1086 /usr/sbin/named -u named -t /var/named/chroot
> 
> Aug 06 11:08:22 ns1.f1-online.net named[1086]: listening on IPv6 interface 
> lo, ::1#53
> Aug 06 11:08:22 ns1.f1-online.net named[1086]: listening on IPv6 interface 
> eth0, 2001:67c:21b0:4029:193:34:29:244#53
> Aug 06 11:08:22 ns1.f1-online.net named[1086]: could not listen on UDP 
> socket: address not available
> Aug 06 11:08:22 ns1.f1-online.net named[1086]: creating IPv6 interface eth0 
> failed; interface ignored

Assuming this the broken state you're describing (as you've attached
before and after log copies), from the log messages above it seems the
interface is not available when named is being started.

I have seen this behavior with several other services on Fedora that
need manual restart after boot (e.g., postfix, nginx and sshd) to make
them listen on all configured interfaces because the interface was not
configured when the service was being started.

Mukund


signature.asc
Description: PGP signature
___
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 used as resolver: matching the source ip

[Mukund Sivaraman]

On Thu, Aug 18, 2016 at 11:27:01AM +0200, pm8...@t-online.de wrote:
> Dear all,
>  
> As far as I understand, BIND is not only used for authoritative name 
> servers, but is also often used as a (recursive) resolver.
> When receiving a response to a DNS query, does BIND match the source ip of 
> the response to the destination ip of the query and discard the response if 
> they do not match? Does it match the ports?
> I.e. apart from checking
> query.transactionID == response.transactionID
> does BIND check for
> query.destinationIP == response.sourceIP
> and
> query.destinationPort == response.sourcePort?
> Can you point me to the function in the source code where this check does 
> or does not happen?

Yes, otherwise offpath cache poisoning would be possible. BIND as
resolver not only matches source port, but also the question and DNS
cookie among other things.

You should be able to find the address and port matching code somewhere
within lib/dns/dispatch.c. Question and cookie matching code should be
found in lib/dns/resolver.c.

Mukund


signature.asc
Description: PGP signature
___
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 looking up domain dryfire.com

[Mukund Sivaraman]

On Tue, Aug 16, 2016 at 11:04:14AM +0200, Eivind Olsen wrote:
> Hello.
> 
> I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
> getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
> RHEL/CentOS/Fedora.
> 
> I can do manual lookups of the domain with "dig" and point it to their
> servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if I go
> through my BIND installation.
> 
> The named.run log contains lines like this:
> 
> 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE resolving
> 'dryfire.com/NS/IN': 213.162.97.178#53
> 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE resolving
> 'dryfire.com/NS/IN': 213.162.97.177#53
> 
> A search for "17 unexpected RCODE" seems to indicate this might be caused by
> incompatibility between SIT/DNS cookies and older versions of NSD. Is this
> also what's happening in my case here?

Possibly:

[muks@jurassic bind9]$ bin/dig +cookie @dns0.getsurfed.com. getsurfed.com.

; <<>> DiG 9.11.0a3 <<>> +cookie @dns0.getsurfed.com. getsurfed.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 39495
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 189 msec
;; SERVER: 213.162.97.177#53(213.162.97.177)
;; WHEN: Tue Aug 16 15:50:50 IST 2016
;; MSG SIZE  rcvd: 23

[muks@jurassic bind9]$ bin/dig +nocookie @dns0.getsurfed.com. getsurfed.com.

; <<>> DiG 9.11.0a3 <<>> +nocookie @dns0.getsurfed.com. getsurfed.com.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38178
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;getsurfed.com. IN  A

;; ANSWER SECTION:
getsurfed.com.  21600   IN  A   213.162.97.82

;; AUTHORITY SECTION:
getsurfed.com.  21600   IN  NS  dns0.getsurfed.com.
getsurfed.com.  21600   IN  NS  dns1.getsurfed.com.

;; ADDITIONAL SECTION:
dns0.getsurfed.com. 3600IN  A   213.162.97.177
dns1.getsurfed.com. 3600IN  A   213.162.97.178

;; Query time: 189 msec
;; SERVER: 213.162.97.177#53(213.162.97.177)
;; WHEN: Tue Aug 16 15:50:52 IST 2016
;; MSG SIZE  rcvd: 128

[muks@jurassic bind9]$ 

Mukund


signature.asc
Description: PGP signature
___
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: Sending extra info in bind dns query packet

[Mukund Sivaraman]

On Thu, Jul 14, 2016 at 11:15:03PM +1000, Karl Auer wrote:
> On Thu, 2016-07-14 at 11:19 +0530, Sachin Patil wrote:
> > I am just looking into bind and want to send extra information while
> > querying dns bind server. This information will be used at the bind 
> > server side to return the resolved ip.
> 
> I've had an off-list discussion with Sachin Patel, asking him what he
> was actually trying to achieve. It turns out that it is this:
> 
> "I am just trying to fiddle with dns server to block certain users to
> certain resources."

Perhaps an existing mechanism such as RPZ would be suitable.

Mukund


signature.asc
Description: PGP signature
___
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-users Digest, Vol 2427, Issue 1

[Mukund Sivaraman]

On Mon, Jul 04, 2016 at 05:18:27PM +0530, Amit Kumar Gupta wrote:
> Dear All,
> Please find the desired o/ps.
> 
> bash-3.2# dig dropbox.com @203.94.243.70
> 
> ; <<>> DiG 9.6-ESV-R4-P2 <<>> dropbox.com @203.94.243.70
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> bash-3.2#

Your client (the machine you are running dig on) probably does not have
a route to 203.94.243.70. Maybe something on the path is filtering
packets.

> bash-3.2# dig +trace dropbox.com  
> 
> ; <<>> DiG 9.6-ESV-R4-P2 <<>> +trace dropbox.com
> ;; global options: +cmd
> .   495997  IN  NS  b.root-servers.net.
> .   495997  IN  NS  e.root-servers.net.
> .   495997  IN  NS  a.root-servers.net.
> .   495997  IN  NS  i.root-servers.net.
> .   495997  IN  NS  j.root-servers.net.
> .   495997  IN  NS  m.root-servers.net.
> .   495997  IN  NS  l.root-servers.net.
> .   495997  IN  NS  k.root-servers.net.
> .   495997  IN  NS  c.root-servers.net.
> .   495997  IN  NS  h.root-servers.net.
> .   495997  IN  NS  d.root-servers.net.
> .   495997  IN  NS  g.root-servers.net.
> .   495997  IN  NS  f.root-servers.net.
> .   496015  IN  RRSIG   NS 8 0 518400 2016071405
> 2016070404 46551 .
> Gjt4qXWy+cQjMelzL3gB+H6uUsg8RTjo11j4Qa8AMlxKGwziBsTUAhm+
> b9kgxwMTUUozV9Q2OS5La2V6ISyXDITTOGEQ1fKH7hwgboWJKSXmKD7Z
> WNKv2CipQm3kktswMfRXC4Q8XQPtkvSwiR8/OyGk1OCNOY2WdOMgUdcS dM8=
> ;; Received 501 bytes from 203.94.243.70#53(203.94.243.70) in 2 ms
> 
> com.172800  IN  NS  j.gtld-servers.net.
> com.172800  IN  NS  a.gtld-servers.net.
> com.172800  IN  NS  m.gtld-servers.net.
> com.172800  IN  NS  c.gtld-servers.net.
> com.172800  IN  NS  i.gtld-servers.net.
> com.172800  IN  NS  l.gtld-servers.net.
> com.172800  IN  NS  b.gtld-servers.net.
> com.172800  IN  NS  f.gtld-servers.net.
> com.172800  IN  NS  h.gtld-servers.net.
> com.172800  IN  NS  e.gtld-servers.net.
> com.172800  IN  NS  k.gtld-servers.net.
> com.172800  IN  NS  g.gtld-servers.net.
> com.172800  IN  NS  d.gtld-servers.net.
> ;; Received 501 bytes from 192.5.5.241#53(f.root-servers.net) in 10851 ms
> 
> dropbox.com.172800  IN  NS  ns-564.awsdns-06.net.
> dropbox.com.172800  IN  NS  ns-315.awsdns-39.com.
> dropbox.com.172800  IN  NS  ns-1162.awsdns-17.org.
> dropbox.com.172800  IN  NS  ns-1949.awsdns-51.co.uk.
> ;; Received 198 bytes from 192.26.92.30#53(c.gtld-servers.net) in 10002 ms
> 
> dropbox.com.60  IN  A   108.160.172.206
> dropbox.com.60  IN  A   108.160.172.238
> dropbox.com.172800  IN  NS  ns-1162.awsdns-17.org.
> dropbox.com.172800  IN  NS  ns-1949.awsdns-51.co.uk.
> dropbox.com.172800  IN  NS  ns-315.awsdns-39.com.
> dropbox.com.172800  IN  NS  ns-564.awsdns-06.net.
> ;; Received 198 bytes from 205.251.193.59#53(ns-315.awsdns-39.com) in 10002
> ms

On the other hand, the client has routes to the nameservers listed in
this trace and seems to be able to resolve dropbox.com directly.

Mukund


signature.asc
Description: PGP signature
___
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-users Digest, Vol 1727, Issue 1

[Mukund Sivaraman]

Hi Amit

On Mon, Jul 04, 2016 at 04:32:07PM +0530, Amit Kumar Gupta wrote:
> Dear All,
> 
> We are Tier 2 ISP in Delhi. Our subscribers are not able to open dropbox.com 
> using our DNS IPs.
> BIND version is 9.8.0.
> 
> Regards
> Manager(Internet-Systems)
> MTNL Delhi

As an internet user, I'd expect my ISP to be using current versions of
software that are not vulnerable or buggy. BIND 9.8.0 is an ancient
version of BIND. BIND 9.8.x release branch reached its end of life in
September 2014. BIND 9.8.0 is much older than that (released in February
2011).

https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html

As you appear to be the manager of internet systems at your organization
from your signature, is it not your responsiblity to use recent versions
of software that have not reached their end of life?

For your resolution problem, I'd recommend that you start by:

1. Upgrading to a current version of BIND.

2. Looking at named log output to see what happens when you're trying to
resolve the domain.

> bash-3.2# dig  dropbox.com 203.94.243.70

I assume 203.94.243.70 is the IP of the resolver that you're trying to
use. In this case, this is not the correct syntax. Use:

dig dropbox.com @203.94.243.70

> ; <<>> DiG 9.6-ESV-R4-P2 <<>> dropbox.com 203.94.243.70
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached

This error means that a nameserver(/resolver) could not be reached.

> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40790
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;203.94.243.70. IN  A

As you can see, due to the incorrect syntax, it's attempting to resolve
the address record of the name "203.94.243.70." which is probably not
what you want.

Please start by upgrading your systems (resolvers) to use a current
version of BIND.  Check that the client has a working route to the
resolver. Check the log output of named for information on whether it is
receiving client queries and any messages it logs about why the
resolution is failing.

As manager of internet systems at your organization, check and see if
any other software that you are using is way past its end of life.

Mukund


signature.asc
Description: PGP signature
___
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: Adding rdataset to a List

[Mukund Sivaraman]

Hi Jun

On Fri, Jul 01, 2016 at 02:56:48AM +, Jun Xiang X Tee wrote:
> Dear all,
> 
> 
>   I set up named server, and my dig client can connect to the server
>   successfully. For a UDP packet, I wish to add an artificial rdataset
>   to name list of Additional Section. Note that this question may look
>   similar to my previous posts, but it is a total different question
>   (I have solved the old questions):

It is not clear what you are attempting to do from a high level, but
what you are describing in great detail seems weird to a person familiar
with DNS.

I strongly recommend taking a different poster's advice on an earlier
email posting of yours, and read some books on DNS first to get a basic
understanding.

In an earlier email, you say you want to modify a UDP reply datagram to
add RRs in the additional section that can be seen in Wireshark. A UDP
reply is sent by a DNS nameserver, not "dig". dig is a DNS client. It
sends out query messages and _prints_ replies after receiving them. You
will not be able to see any replies modified inside dig in a Wireshark
packet capture - they do not go out on the network again. They will only
show up in the dig output, but nothing else on the network will be
affected by it.

It is not clear what you're attempting to do. Based on your questions
from earlier emails, I suggest reading this book before you proceed to
modifying BIND code:

http://www.zytrax.com/books/dns/

Mukund


signature.asc
Description: PGP signature
___
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: ISC considering a change to the BIND open source license

[Mukund Sivaraman]

On Tue, Jun 14, 2016 at 08:06:55PM +, Evan Hunt wrote:
> On Tue, Jun 14, 2016 at 12:38:14PM -0700, Ted Mittelstaedt wrote:
> > In reality, there IS no "middle ground"   If you truly believe a
> > piece of software SHOULD be freely licensed, then that includes the
> > idea that commercial entities can use it as they see fit.
> 
> Thank you for the explanation.
> 
> As I undesrtand it, commercial entities *will* be able to use BIND as they
> see fit, even if the relicensing goes ahead.  Share bug fixes back, or get
> a support contract, and we're good.  We really just want everybody to be a
> mensch about it.
> 
> On a personal level, I actually agree with you, and I find the idea of
> relicensing somewhat regrettable.  It's not that I'm against the GPL, I
> think software creators should be able to share their work on whatever
> terms they like, but *personally* I like giving my stuff away with as few
> encumbrances as possible.  It's disappointing to me to add any burden to
> it at all.  I do like eating, though, and I won't be able to fix as many
> bugs if I have to stop doing that. :/

This last sentence sums it up well.

There's been quite some internal discussion about the license change,
which is not a lightly attempted and achieved endeavour, and the
discussion is still continuing. There seems to be some public anger at
such a license change, but it is misdirected. Be angry for us, not at
us. We care deeply about BIND's users, the DNS and DNS users in general
(if you have any doubt about that, look at communication with ISC staff,
even if it is with a member of staff from a company that's shipping a
closed fork of BIND, or even another DNS implementation).

In reality, the world is not perfect as we expect it to be, or we would
not have to attempt this license change. It is a means to an end, for
the goal that we most care about which is to make BIND and the DNS
better and have BIND available to everyone to use, modify.

Your anger is misdirected when you say things like "kicking all BSD
distributions in the teeth". That's not what we're thinking of.

(also speaking for myself, not ISC.)

Mukund


signature.asc
Description: PGP signature
___
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: ISC considering a change to the BIND open source license

[Mukund Sivaraman]

Hi Evan

On Tue, Jun 14, 2016 at 05:45:59PM +, Evan Hunt wrote:
> May I ask you to expand on why the MPL is a problem?  So far the distros
> have all been supportive.

The BSD camp dislikes copyleft because copyleft prevents exactly what
we're trying to stop: the ability to ship a closed-source forked version
of BIND. They think that software is more free if that is allowed,
although they'd like all software to be free.

The GNU/FSF camp's view is different. In its view, a software is more
free if its freedom is protected and cannot be lost; hence the copyleft
clauses.

To a user of BIND, it makes no difference. To a restributor of BIND who
keeps the modified code free, it makes no difference. Those who are hurt
by it are those who are shipping closed-source modified versions, or
those who'd like to let others continue to do so.

Mukund


signature.asc
Description: PGP signature
___
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: Assertion failure when RPZ zone returns NS records?

[Mukund Sivaraman]

On Sat, Jun 11, 2016 at 11:40:17PM +0530, Mukund Sivaraman wrote:
> On Sat, Jun 11, 2016 at 05:19:41PM +, McDonald, Daniel (Dan) wrote:
> > Apparently it’s not the way to do what I needed, but I created an RPZ 
> > record like this:
> > foo.example.com IN  NS  ns1.example.org
> > IN  NS  ns2.example.org
> > 
> > 
> > My goal was to redirect queries to a load balancer serving
> > foo.example.com A records.  I should have created the glue in
> > example.org and then used RPZ to create a CNAME for foo.example.com
> > pointing to foo.example.org
> > 
> > 
> > Anyway, with the NS records, I got an assertion failure:
> > 10-Jun-2016 15:49:58.584 client 10.10.207.244#49952 (foo.example.com 
> > <http://sts.austinenergy.com/>): query: foo.example.com 
> > <http://sts.austinenergy.com/> IN A + (10.2.123.132)
> > Jun 10 15:49:58 ns11 named[2248]: query.c:3908: REQUIRE(dbp != ((void *)0) 
> > && *dbp != ((void *)0)) failed
> > Jun 10 15:49:58 ns11 named[2248]: exiting (due to assertion failure)
> > 
> > I’m running the supplied version of Bind from SLES 11 SP4:
> > someone@ns11:/var/lib/named/var/log> rpm -qi bind
> > Name: bind Relocations: (not relocatable)
> > Version : 9.9.6P1   Vendor: SUSE LINUX Products 
> > GmbH, Nuernberg, Germany
> > Release : 0.25.1Build Date: Wed 09 Mar 2016 
> > 10:22:09 AM CST
> > Install Date: Mon 21 Mar 2016 09:31:21 AM CDT  Build Host: sheep02
> > Group   : Productivity/Networking/DNS/Servers   Source RPM: 
> > bind-9.9.6P1-0.25.1.src.rpm
> > Size: 1187259  License: BSD 3-Clause; 
> > X11/MIT
> > Signature   : RSA/8, Wed 09 Mar 2016 10:23:01 AM CST, Key ID 
> > e3a5c360307e3d54
> > Packager: https://www.suse.com/
> > URL : http://isc.org/sw/bind/
> > 
> > 
> > Is this a known error?
> 
> This is a crash in rpz_clean() in query.c in the 9.9 branch.
> 
> (1) Use 9.10 if you want to use RPZ feature in a public BIND
> release. Only 9.10 and above's RPZ is maintained and deployable among
> BIND public releases.
> 
> (2) Use the latest version of BIND for the release branch you're
> using. So today, you'd use 9.10.4-P1 (the latest version of BIND in the
> 9.10 branch) if you want to deploy the RPZ feature.

This last point may not be clear: distributions ship a version of BIND
as a package and maintain the same version of the BIND throughout that
distribution version's life by releasing update packages that
incorporate security bugfixes. But security bugs are not the only kind
of bugs that we fix in maintenance releases, and many bugfixes end up
not getting backported to distribution packages. So, distribution
packages that are older (because a new version of BIND has shipped in
that release branch, or that BIND branch may itself have become EOL'd)
may have bugs and we have no control/influence over this situation.

We usually check up bugs reported against older versions to rule out
that they exist in the current versions, but when we know that the bug
is reported against a reasonably old version of BIND with known issues
in that area (that have since been fixed), we recommend that you use the
latest version and report it if you observe it there.

Some users run very old versions of (what they assume are supported)
packaged BIND in older Linux distributions that have still not reached
their end-of-life, and have bad experience due to crashes that have long
been fixed in upstream ISC BIND.

It's best to run the latest public upstream version of BIND and we react
quickly to crash reports against it.

Mukund


signature.asc
Description: PGP signature
___
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: Assertion failure when RPZ zone returns NS records?

[Mukund Sivaraman]

On Sat, Jun 11, 2016 at 05:19:41PM +, McDonald, Daniel (Dan) wrote:
> Apparently it’s not the way to do what I needed, but I created an RPZ record 
> like this:
> foo.example.com   IN  NS  ns1.example.org
>   IN  NS  ns2.example.org
> 
> 
> My goal was to redirect queries to a load balancer serving
> foo.example.com A records.  I should have created the glue in
> example.org and then used RPZ to create a CNAME for foo.example.com
> pointing to foo.example.org
> 
> 
> Anyway, with the NS records, I got an assertion failure:
> 10-Jun-2016 15:49:58.584 client 10.10.207.244#49952 (foo.example.com 
> ): query: foo.example.com 
>  IN A + (10.2.123.132)
> Jun 10 15:49:58 ns11 named[2248]: query.c:3908: REQUIRE(dbp != ((void *)0) && 
> *dbp != ((void *)0)) failed
> Jun 10 15:49:58 ns11 named[2248]: exiting (due to assertion failure)
> 
> I’m running the supplied version of Bind from SLES 11 SP4:
> someone@ns11:/var/lib/named/var/log> rpm -qi bind
> Name: bind Relocations: (not relocatable)
> Version : 9.9.6P1   Vendor: SUSE LINUX Products 
> GmbH, Nuernberg, Germany
> Release : 0.25.1Build Date: Wed 09 Mar 2016 
> 10:22:09 AM CST
> Install Date: Mon 21 Mar 2016 09:31:21 AM CDT  Build Host: sheep02
> Group   : Productivity/Networking/DNS/Servers   Source RPM: 
> bind-9.9.6P1-0.25.1.src.rpm
> Size: 1187259  License: BSD 3-Clause; X11/MIT
> Signature   : RSA/8, Wed 09 Mar 2016 10:23:01 AM CST, Key ID e3a5c360307e3d54
> Packager: https://www.suse.com/
> URL : http://isc.org/sw/bind/
> 
> 
> Is this a known error?

This is a crash in rpz_clean() in query.c in the 9.9 branch.

(1) Use 9.10 if you want to use RPZ feature in a public BIND
release. Only 9.10 and above's RPZ is maintained and deployable among
BIND public releases.

(2) Use the latest version of BIND for the release branch you're
using. So today, you'd use 9.10.4-P1 (the latest version of BIND in the
9.10 branch) if you want to deploy the RPZ feature.

Mukund


signature.asc
Description: PGP signature
___
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: RPZ logging

[Mukund Sivaraman]

On Fri, May 20, 2016 at 01:36:42PM +0200, Job wrote:
> Hello,
> 
> is it possible to log, regarding the RPZ responce policy, everything
> EXPECT the CLIENT PASS THROUGH events?  I would like to log only what
> is matched.

9.11 (alpha release) has a "log" clause to enable/disable logging per
individual policy zones. This is all that's configurable currently for
RPZ logging.

Mukund


signature.asc
Description: PGP signature
___
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: Problems after upgrade to 9.10.4

[Mukund Sivaraman]

Hi Michael

On Fri, May 06, 2016 at 02:57:59PM +0200, Michael Brunnbauer wrote:
> I tried running bind with dnssec-enable no and still the exchanges with
> tld nameservers involved many packets and TCP sessions. Why?

See below:

> > 07:25:08.157974 IP (tos 0x0, ttl 64, id 22351, offset 0, flags [none], 
> > proto UDP (17), length 75)
> > 81.209.177.155.40611 > 192.12.94.30.53: [bad udp cksum 0x21e0 -> 
> > 0xcab7!] 48603 [1au] A? ts.foaf-search.net. ar: . OPT UDPsize=512 OK (47)
> > 07:25:08.158034 IP (tos 0x0, ttl 64, id 22352, offset 0, flags [none], 
> > proto UDP (17), length 75)
> > 81.209.177.155.63722 > 192.12.94.30.53: [bad udp cksum 0x21e0 -> 
> > 0xd69b!] 22421 [1au] ? ts.foaf-search.net. ar: . OPT UDPsize=512 OK (47)

These queries are sent by 81.209.177.155 to 192.12.94.30 with UDP
payload size set to 512. This caused the reply to be truncated:

[muks@jurassic ~]$ dig +bufsize=512 +dnssec @192.12.94.30 -t A foaf-search.net.
;; Truncated, retrying in TCP mode.

Why is the UDP payload size advertised as 512? Some previous timeout or
configuration caused it to be so. Check earlier logs. Try querying the
TLD NS directly with +bufsize=4096 to see if there are any issues in
getting replies to your network.

Mukund


signature.asc
Description: PGP signature
___
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: REG: configuring BIND to respond with EDNS client subnet option

[Mukund Sivaraman]

Hi Ramachandra

On Tue, Mar 29, 2016 at 02:32:28PM -0700, Ramachandra Kasyap Marmavula wrote:
> Request for some help with configuring a BIND DNS server to respond with
> EDNS0 client subnet option. I am using the enhanced 'dig' utility available
> with the BIND distribution to generate DNS queries with the EDNS0 client
> subnet option. I compiled bind with GeoIP and I am trying to use views to
> to define the list of IP subnets. Sample configuration from named.conf:
> 
> acl "IN" {
> 1.6.0.0/15;
> 1.22.0.0/15;
> 1.38.0.0/15;
> 103.24.201.0/24;
> };
> 
> view "EDNS" {
>  match-clients { IN; };
> zone "ecs.test" {
> type master;
> file "/etc/named/zones/myzone.tld.conf";
> };
> }
> 
> When I send a DNS query with EDNS client subnet option, the server returns
> a response without the ECS option (indicating that it doesn't support this
> option). Is there some other configuration that I have to enable in
> named.conf to get this to work?

Which version of BIND are you using? Authoritative side support for
client-subnet is only available in the master branch (and the 9.11 alpha
release so far). It has not been released in any stable releases and is
not a part of BIND 9.10 or 9.9.

Mukund


signature.asc
Description: PGP signature
___
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: pre heat cache

[Mukund Sivaraman]

On Wed, Feb 17, 2016 at 11:31:54AM -0800, William Taylor wrote:
> Is there anyway to pre-heat the cache in bind on startup besides having
> a custom script that did a bunch of queries on top hosts?
> I know you can dump it with rndc but can you load it back ?

It used to be possible to load the cache. I'm not sure if we still
support that. I think at least one system test uses it somewhere.

Mukund


signature.asc
Description: PGP signature
___
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: Complete DNS fake root setup example

[Mukund Sivaraman]

Hi John

On Wed, Jan 20, 2016 at 05:12:44PM +, MURTARI, JOHN wrote:
> Folks,
> Had to do some testing where we wanted our own
> insulated fake root environment. We wanted to start
> from simulated root name servers.  I was surprised I
> couldn't find a complete example even after some
> extensive searches.
> 
> The concepts are easy, but the devil is in the
> details.  We had done this before, but no one ever
> kept notes so I figured by posting it on the list it
> will eventually find its way into Google.  Here are
> the setup instructions below, name & ip address have
> been changed to protect the innocent!  Your
> comments/suggestions are welcome!

The key parts are the root hints and the trust anchors. You can see
several such fake root configurations in the BIND 9 system tests (look
in bin/tests/system), e.g., the resolver system test.

Mukund


signature.asc
Description: PGP signature
___
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: Mitigation of server's load by queries for non-existing domains

[Mukund Sivaraman]

Hi Tomas

On Tue, Jan 12, 2016 at 05:53:20PM +0100, Tomas Hozza wrote:
> Hello all.
> 
> Recently I was trying to find a mechanism in BIND that could prevent
> the server from processing a recursive query for non-existing
> domains. The issue I was trying to solve was that when server was
> getting too many queries for such domains it was not able to handle
> other relevant queries. The non-exiting domains have just few common
> non-existing parent domains, so one can match most of them by wildcard
> RR.

The attack you are describing is probably the well-known-by-now attack
called "water torture" or "random subdomain" attack. If you search for
these phrases, you'll see several presentations made on the topic.

> I was thinking about using RPZ with QNAME policy trigger, but this
> applies only to the responses to queries and still makes the server to
> try to resolve it. As far as I'm familiar with RRL, it will also not
> help, since it also applies to the response to a query.
> 
> One possible solution that came to my mind was to define a zone for
> each of the "parent" domains and then just return localhost address or
> something similar to any query to that domain. I know this is kind of
> dummy, but this was the first thing that came to my mind. I know the
> server will still process the query, but will at least not do any
> recursion.
> 
> Is there any better mechanism to solve such problem?

This is an on-going problem for DNS and several measures are being
considered:

Making aggressive use of NSEC/NSEC3:
https://tools.ietf.org/html/draft-fujiwara-dnsop-nsec-aggressiveuse-01

Bloom filtering from queries:
https://github.com/hdais/unbound-bloomfilter

Evan Hunt is considering proposing another bloom filtering method by
using a bloom bitfield RR. We are thinking of what else could help,
including tagging of malware clients via RPZ zones provided by relevant
feed providers.

There are some measures in 9.10.3 (read about "fetches-per-server" and
"fetches-per-zone" in the ARM).

Mukund


signature.asc
Description: PGP signature
___
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: Does EDNS0 work with bind-9.10.3-P2?

[Mukund Sivaraman]

Hi Sury

On Tue, Jan 05, 2016 at 10:50:39PM +0800, Sury Bu wrote:
> I installed the latest version of bind-9.10.3-P2 but when I using dig
> EDNS feature with +subnet, I found my local DNS can not carry client
> subnet, does this version support EDNS0 now?

9.10 branch as no support for ECS except dig allowing +subnet to be
specified. There is no support in named.

master branch has prelimnary support for authoritative side of ECS, but
the draft is still not finalized and there are some differences from the
current draft.

There is no support currently for ECS in the resolver, either in the
cache or even to handle that option.

Mukund


signature.asc
Description: PGP signature
___
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: Does EDNS0 work with bind-9.10.3-P2?

[Mukund Sivaraman]

Hi Sury

On Wed, Jan 06, 2016 at 02:35:37PM +0800, Sury Bu wrote:
> Hi Mukund,
> 
> Thanks for your reply, and do you know what bind version will support
> ECS option?

BIND 9.11 will introduce authoritative support for ECS.

Mukund


signature.asc
Description: PGP signature
___
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 is a $ORIGIN directive used inside a DNS Zone File

[Mukund Sivaraman]

On Mon, Dec 14, 2015 at 11:18:08AM +, Tony Finch wrote:
> Mukund Sivaraman <m...@isc.org> wrote:
> >
> > Zone files do not require use of $ORIGIN. It is in fact an extension to
> > the master format in RFC 1035.
> 
> No, it is specified in RFC 1035 section 5.1:

I'm getting old.

Mukund


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

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

Re: Bind 9.10.3 on CentOS 7.1 - Recv-q on vmware

[Mukund Sivaraman]

Hi Rasmus

On Tue, Dec 15, 2015 at 03:20:05PM +0100, Rasmus Edgar wrote:
> We started noticing 1s+ latency problems on clients resolving using the
> vmware guest at a load around 6000 qps.
> 
> Test setup:
> 
> 1 x x86_64 vmware guest on Esx 5.5
> 8xVCPU
> 8G RAM
> vmxnet3 10Gb virtual interface
> CentOS 7.1
> Bind 9.10.3 resolver
> 
> 1xIBM x86_64 physical machine
> 24xCPU cores
> 16G ram
> 1Gb interface
> CentOS 7.1
> Bind 9.10.3 resolver

Generally VMs are not a proper place to test query performance, but
anyway let's see.  When named starts, it logs messages like this:

15-Dec-2015 20:08:00.245 found 8 CPUs, using 8 worker threads
15-Dec-2015 20:08:00.245 using 7 UDP listeners per interface
15-Dec-2015 20:08:00.245 using up to 4096 sockets

Please will you paste what you get in your configuration?

> ./dnsperf -f inet -s  -d queryfile-example-10million-201202 -l
> 30 -q 15000

Why are you passing the -q argument to dnsperf?

A high receive queue means your named process is not able to read off
the socket fast enough. Try to find out where it's busy, using a
profiler such as perf. Is it query logging or doing some other highly
verbose logging that keeps it blocked in disk IO?

Mukund


signature.asc
Description: PGP signature
___
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 is a $ORIGIN directive used inside a DNS Zone File

[Mukund Sivaraman]

Hi Harshith

On Mon, Dec 14, 2015 at 07:36:15AM +, Harshith Mulky wrote:
> Why is a $ORIGIN directive used in DNS Zone Files?

$ORIGIN directive sets a name to be appended to relative names in the
zone file so that they can be made into absolute names. The current
origin is appended to such relatives names.

See the BIND ARM for syntax and an explanation.

It is also explained here: http://www.zytrax.com/books/dns/ch8/origin.html

> Would my Zone Files not work if I do not have $ORIGIN directive?

Zone files do not require use of $ORIGIN. It is in fact an extension to
the master format in RFC 1035.

See the pointers above for more details.

Mukund


signature.asc
Description: PGP signature
___
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: RPZ - override TXT records

[Mukund Sivaraman]

Hi Wolfgang

On Thu, Oct 08, 2015 at 11:25:14PM +0200, Wolfgang Riedel [CISCO] wrote:
> Hi Folks,
> 
> I am currently struggling with using RPZ for inserting or overriding TXT
> resource records.
> 
> This is my goal:
> 
>; do not rewrite www.cisco.com (so, PASSTHRU) and add or override
>missing metadata
>www.cisco.com CNAME rpz-passthru.
>www.cisco.com TXT "CISCO-CLS=app-name:HTTP|app-class:TD"
> 
> What work's is that I can do one or the other but not both at the same time
> if I need to use a CNAME.
> 
> This works:
> 
>wolfgang.dns-as.org A   193.34.28.108
>wolfgang.dns-as.org TXT "CISCO-CLS=app-name:RPZ|app-class:TD"
> 
> but in reality this will not work for CDN or load-balanced sites which don't
> have fixed IP address.
> 
> Any hint's what I am doing wrong?

You aren't doing anything wrong. Yours is a corner case.

I hope I understood what you're trying to do correctly: From the zone
comment, perhaps you want the TXT query type to return the TXT RDATA
you've supplied and everything else passthru to regular processing. It
can't be done as triggers don't use the question's TYPE field.

An alternative is to include all the RRs for that QNAME in the answer
(your second example). Yours is a weird case, because you can't use the
following in the policy zone which named wouldn't allow loading (it
won't allow CNAME to coexist):

www.cisco.com  CNAME www.cisco.com.akadns.net.
www.cisco.com  TXT   "CISCO-CLS=app-name:HTTP|app-class:TD"

So using the A record (your second example) or adding triggers for the
target of the CNAME record chain are your best bet. As the latter
varies, perhaps the former for your region would be best.

Mukund


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

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

Re: logging bug for rpz at load-time?

[Mukund Sivaraman]

Hi Phil

On Thu, Sep 03, 2015 at 01:22:48PM +0100, Phil Mayers wrote:
> Minor cosmetic bug, but we're seeing logs like:
> 
> 03-Sep-2015 12:18:50.751 (re)loading policy zone 'rpz.' changed from
> 0 to 77406 qname, 0 to 0 nsdname, 769 to 771 IP, 0 to 0 NSIP, 0 to 0
> CLIENTIP entries
> 
> 03-Sep-2015 12:18:58.029 (re)loading policy zone 'rpz.' changed
> from 77406 to 1213943 qname, 0 to 0 nsdname, 771 to 771 IP, 0 to 0 NSIP, 0
> to 0 CLIENTIP entries
> 
> Couple of problems here - the "local" RPZ (first log line) only has a few
> hundred entries in it, definitely not 77406.
> 
> Second, the next log line seems to claim the "upstream" RPZ goes from
> exactly the same number (eh?) to some other number equally unrelated to the
> contents of the zone.
> 
> Or do the numbers here mean something different?

The numbers are overall counts for that view, after the contents of that
policy zone have been loaded. Cumulatively, they should match the number
of records in your policy zones (named starts with empty RPZ state).

> This is on 9.10.2-P4

If these numbers (for the view) don't match up, can you try reproducing
this with 9.10.3-rc1 and let us know what you get? There have been some
bugfixes since 9.10.2.

How many policy zones do you have? If you can, please send us your named
configuration and the expected number of RRs that you intend to see.

Mukund


pgpTyOsBlZUr7.pgp
Description: PGP signature
___
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: ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure

[Mukund Sivaraman]

Hi Prakash

On Mon, Aug 03, 2015 at 10:14:50AM +0530, prakash wrote:
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15424: 
 writeable file 'data/udalgurijudiciarygov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15424
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15431: 
 writeable file 'data/bodolandgov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15431
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15445: 
 writeable file 'data/cexhyd2gov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15445
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15452: 
 writeable file 'data/bmcsagaredu.hosts': already in use: 
 /etc/nicnet2007.govdomain:15452
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15459: 
 writeable file 'data/crckozhikodegov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15459
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15466: 
 writeable file 'data/wblcgov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15466
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15473: 
 writeable file 'data/precursorsncbgov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15473
 Aug  3 09:59:34 govindnsvm named[7436]: /etc/nicnet2007.govdomain:15480: 
 writeable file 'data/icggov.hosts': already in use: 
 /etc/nicnet2007.govdomain:15480
 Aug  3 09:59:34 govindnsvm named[7436]: loading configuration: failure
 Aug  3 09:59:34 govindnsvm named[7436]: exiting (due to fatal error)

See if you have used these data/*.host as values with the file
option multiple times in your named configuration. It may be that you
have included a config snippet multiple times.

Mukund


pgpROt9HComlc.pgp
Description: PGP signature
___
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: Order and Preference Priority in DNS Responses

[Mukund Sivaraman]

Hi Harshith

On Mon, Aug 03, 2015 at 05:08:50PM +0530, Harshith Mulky wrote:
 I wanted to understand how Order and Preference Values have an impact on the 
 answers Received from the DNS Server
 
 I am asking because, I have 4 records for NAPTR Query, as below
 
 carrier1.com 86400 IN NAPTR   50 50“s”   “SIPS+D2T”  ““
 “_sips._tcp.carrier1.com.”
 carrier1.com 86400 IN NAPTR   90 50“s”   “SIP+D2T”““  
 “_sip._tcp.carrier1.com.”
 carrier1.com 86400 IN NAPTR 100   100   “s”  “SIP+D2U”  ““ 
 “_sip._udp.carrier1.com.”
 carrier1.com 86400 IN NAPTR 120100   “s”  “SIPS+D2U”   ““
 “_sip._tcp.carrier1.com.”
 
 
 I am expecting to receive the answer as _sip._udp.carrier1.com but i receive 
 _sip._tcp.carrier1.com

A client application querying for this record type (NAPTR) will receive
all these RRs. It is upto the client application to use these records
and use them in the sequence of the ORDER field.

Mukund


pgp7lLBeup5wQ.pgp
Description: PGP signature
___
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 format error

[Mukund Sivaraman]

On Wed, Jul 29, 2015 at 08:13:38AM +0200, Matus UHLAR - fantomas wrote:
 On 29.07.15 03:06, Yang Yu wrote:
 I configured bind to forward queries to 8.8.8.8
 
 do you have any reason to do this?
 BIND can resolve properly itself, it does not need to forward queries to
 anyone unless you are firewalled (in such case, do you really need BIND?)
 without forwarding you apparently won't get this error...

The formerr occurs during message processing during normal resolution
because of the peculiar reply in this case from the nameserver for
www.vip.icann.org. We will look into it.

Mukund


pgpjof_aPPrq2.pgp
Description: PGP signature
___
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