Can't get BIND to use GSSAPI from /usr/local

2010-06-11 Thread John Marshall
  BIND 9.7.1rc1
  FreeBSD 8.1-PRERELEASE

I've just stepped into the world of nsupdate (instead of doing the
freeze/edit/thaw dance).  I have had success using TSIG (nsupdate -k)
but I would like to use TKEY-GSS (nsupdate -g).  When I try to do that,
nsupdate dumps core.

  $ /usr/bin/nsupdate -g -d
   prereq nxdomain rwpc12.mby.riverwillow.net.au.
  
  Reply from SOA query:
   snip 
  Found zone name: mby.riverwillow.net.au
  The master is: ns1.mby.riverwillow.net.au
  start_gssrequest
  nsupdate: Failed to generate random block
  Abort trap (core dumped)

I suspect the operating system at this point but want to build BIND
against separate gssapi_krb5 and OpenSSL libraries in order to isolate
the problem.

Telling configure --with-openssl=/usr/local does the trick for OpenSSL.
Telling configure --with-gssapi=/usr/local makes all the right kind of
impressions on config.log, but the linker still ends up using the
operating system's gssapi libraries under /usr/lib.  Is there something
else I need to do to nudge BIND in the direction of libgssapi_krb5 in
/usr/local ?

Until now I've never built BIND with gssapi, so I'm prepared to be told
I've missed something basic.

Thank you.

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


bind problems, 9.7.0 p1

2010-06-11 Thread David Ford
A snippet of the log to start with

11-Jun-2010 06:35:08.959 Postgres driver unable to find available
connection after searching 30 times
11-Jun-2010 06:35:08.959 Postgres driver unable to return result set for
findzone query

/*%
 * Loops through the list of DB instances, attempting to lock
 * on the mutex.  If successful, the DBI is reserved for use
 * and the thread can perform queries against the database.
 * If the lock fails, the next one in the list is tried.
 * looping continues until a lock is obtained, or until
 * the list has been searched dbc_search_limit times.
 * This function is only used when the driver is compiled for
 * multithreaded operation.
 */

static dbinstance_t *
postgres_find_avail_conn(db_list_t *dblist)
{
dbinstance_t *dbi = NULL;
dbinstance_t *head;
int count = 0;

/* get top of list */
head = dbi = ISC_LIST_HEAD(*dblist);

/* loop through list */
while (count  dbc_search_limit) {
/* try to lock on the mutex */
if (isc_mutex_trylock(dbi-instance_lock) ==
ISC_R_SUCCESS)
return dbi; /* success, return the DBI for
use. */

/* not successful, keep trying */
dbi = ISC_LIST_NEXT(dbi, link);

/* check to see if we have gone to the top of the
list. */
if (dbi == NULL) {
count++;  
dbi = head;
}
}
isc_log_write(dns_lctx, DNS_LOGCATEGORY_DATABASE,
  DNS_LOGMODULE_DLZ, ISC_LOG_INFO,
  Postgres driver unable to find available
connection 
  after searching %d times,
  count);
return NULL;
}



11-Jun-2010 06:35:09.080 name.c:2091: REQUIRE(suffixlabels  0) failed
11-Jun-2010 06:35:09.081 exiting (due to assertion failure)

void
dns_name_split(dns_name_t *name, unsigned int suffixlabels,
   dns_name_t *prefix, dns_name_t *suffix)
{
unsigned int splitlabel;

REQUIRE(VALID_NAME(name));
REQUIRE(suffixlabels  0);
REQUIRE(suffixlabels  name-labels);
REQUIRE(prefix != NULL || suffix != NULL);
REQUIRE(prefix == NULL ||
(VALID_NAME(prefix) 
 prefix-buffer != NULL 
 BINDABLE(prefix)));
REQUIRE(suffix == NULL ||
(VALID_NAME(suffix) 
 suffix-buffer != NULL 
 BINDABLE(suffix)));

splitlabel = name-labels - suffixlabels;

if (prefix != NULL)
dns_name_getlabelsequence(name, 0, splitlabel, prefix);

if (suffix != NULL)
dns_name_getlabelsequence(name, splitlabel,
  suffixlabels, suffix);

return;
}




There are two issues here.  a) why is bind rapid firing, and i mean
RAPID, the logs are overflowing with these messages.  bind attempts to
find a free mutex connection and failing?  14 of these pairs in 3ms with
80 seconds of silence prior to this and a minute of silence after this. 
420 attempts in 3ms.

my postgresql logs aren't indicating anything is going on and the
machine is almost a blank slate for activity.  it's entirely idle. 
there's no hangup on resources for the DB so i have to presume that bind
itself has somehow gotten into a full-up state without good reason. 
postgresql is indicating 4 idle connections normally.  i have maybe one
or two queries per second averaged out of small 4-12 queries in an ~8
second interval. maybe a microsleep pause would be beneficial.  better
would be a dump showing which threads were doing what to figure out why
a supposedly idle system is all tied up.

Next, b) named keeps dying with this entirely ambiguous assertion
failure.  i'm sure it's a fault of my own but without any indication
where the issue lies, this like asking to find a leaf in a forest
without knowing what type of leaf you're looking for ^_^.

Why is bind so prone to falling over and dying from typos?  don't get me
wrong please, i love bind which is why i've been using it for ~15 years
now.  i've noted that bind has a strong tendancy to simply flat out
abort if it encounters zone data it doesn't like rather than report it
and drop the bad data.  that's not really very reliable.  it's ok for
testing in the lab but really bad manners for production. :

A bit of help on these please :)

-david

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

why dig +trace does not working?

2010-06-11 Thread ShanyiWan


[r...@flyinweb ~]# dig @ns1.dns-diy.com 35.com +trace

;  DiG 9.7.0-P2  @ns1.dns-diy.com 35.com +trace
; (1 server found)
;; global options: +cmd
;; Received 17 bytes from 218.85.139.33#53(218.85.139.33) in 2 ms

[r...@flyinweb ~]# dig @ns1.dns-diy.com 35.com

;  DiG 9.7.0-P2  @ns1.dns-diy.com 35.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 17492
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;35.com.IN  A

;; ANSWER SECTION:
35.com. 100 IN  A   210.75.241.83

;; Query time: 2 msec
;; SERVER: 218.85.139.33#53(218.85.139.33)
;; WHEN: Sat Jun 12 11:34:14 2010
;; MSG SIZE  rcvd: 40


[r...@flyinweb ~]# dig @8.8.8.8 35.com +trace  

;  DiG 9.7.0-P2  @8.8.8.8 35.com +trace
; (1 server found)
;; global options: +cmd
.   55672   IN  NS  m.root-servers.net.
.   55672   IN  NS  k.root-servers.net.
.   55672   IN  NS  g.root-servers.net.
.   55672   IN  NS  c.root-servers.net.
.   55672   IN  NS  d.root-servers.net.
.   55672   IN  NS  a.root-servers.net.
.   55672   IN  NS  i.root-servers.net.
.   55672   IN  NS  h.root-servers.net.
.   55672   IN  NS  j.root-servers.net.
.   55672   IN  NS  l.root-servers.net.
.   55672   IN  NS  b.root-servers.net.
.   55672   IN  NS  e.root-servers.net.
.   55672   IN  NS  f.root-servers.net.
;; Received 228 bytes from 8.8.8.8#53(8.8.8. in 97 ms

com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
;; Received 512 bytes from 192.228.79.201#53(b.root-servers.net) in 194 ms

35.com. 172800  IN  NS  ns1.dns-diy.com.
35.com. 172800  IN  NS  ns2.dns-diy.com.
;; Received 164 bytes from 192.35.51.30#53(f.gtld-servers.net) in 196 ms

35.com. 100 IN  A   210.75.241.83
;; Received 40 bytes from 218.107.207.23#53(ns2.dns-diy.com) in 208 ms

2010-06-12 



ShanyiWan 

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