Re: ARPA entries for a host with multiple IPs

[Barry Margolin]

In article , shulkae  
wrote:

> Question on BIND 9 running on FreeBSD.
> 
> My customer requested to add multiple IPs to a single name so that he
> can use the round-robin feature of BIND to load-balance the service.
> 
> The entry we added looks something as below:
> 
> # more db.myzone
> ..
> ..
> ws   
> ..
> ..
> 
> So when my customer query the ws, he gets one of ipX any any given
> time. They never requested anything
> for updating ARPA entries for the above.
> 
> What would be the ARPA  entries for each of these? ip1, ip2 and ip3?

FYI, appropriate term would be "PTR record" or "reverse entry".  I've 
never heard them called "ARPA entries", although some call them 
"in-addrs".

> Can I add 'ws' for each of these?
> I haven't seen any references to do this either in BIND ARM or DNS/
> Bind Book.
> 
> Any tips from experienced folks?

A common practice is to create unique names for each machine, in 
addition to the round-robin entry.  This way, if you need to perform 
maintenance on a specific machine, you can go to it by its unique name.  
Then you should make the PTR record point to this name.  E.g. the 
forward zone for myzone.com would contain:

ws IN A 1.2.3.1
   IN A 1.2.3.2
   IN A 1.2.3.3

ws-1 IN A 1.2.3.1
ws-2 IN A 1.2.3.2
ws-3 IN A 1.2.3.3

and the reverse zone 3.2.1.in-addr.arpa would contain:

1 IN PTR ws-1.myzone.com.
2 IN PTR ws-2.myzone.com.
3 IN PTR ws-3.myzone.com.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Mark Andrews]

In message <6.2.5.6.2.20090225140635.02c02...@resistor.net>, SM writes:
> At 13:46 25-02-2009, Mike Bernhardt wrote:
> >I've been looking into the RFCs regarding whether or not single-character
> >(alpha) host names are allowed or not. RFC 952 says no, but 2181 says that
> >host names must between 1 and 63 octets in length, which would appear to say
> >"yes."
>
> Section 2.1 of RFC 1123 discusses the syntax for host names and 
> clarifies RFC 952.  Host names can be up to 63 octets and the FQDNs 
> up to 255 octets (RFC 2181).  You can have a single-character host 
> name as long as it follows the syntax.

RFC 1123 does not say that.  It says:

  Host software MUST handle host names of up to 63 characters and
  SHOULD handle host names of up to 255 characters.

RFC 952 was written during the transition from a flat namespace to a
heirachical namespace.  It handled both forms of names.

"m" as a hostname or alias is illegal.
"m.example.net" is not illegal as a hostname or alias.

RFC 1034 does not define what is or is not legal in a host names.  It
deals with domain names which are not the same thing.

RFC 2181 does not define what is or is not legal in a host names.  It
deals with domain names which are not the same thing.

> Regards,
> -sm 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: how to clear resolver cache?

[Kevin Darcy]

online-reg wrote:

Hi All:

Bind 9.5.0-p1 on Fedora...how do I clear the cache?

I updated a FUBAR MX record at godaddy.com's NS, with a TTL of 3600. 
My local BIND seems to be caching the record after I updated at 
godaddy. When I query the upstream NS that the local server uses, it 
returns the updated MX record, but when I query localhost, I still get 
the old record.


I tried all of these:

rndc flush

That should do it.

rndc reload
/etc/rc.d/init.d/nscd restart

Does nscd cache MX records? On Solaris, at least, it only caches lookups 
made through the standard resolver-library calls (gethostbyname() etc.), 
which don't include MX records. Also, if you're using dig or nslookup to 
query the MX, those utilities probably aren't going through any 
mechanism that would use nscd's cache anyway.


First thing I'd do is see if the flush is actually working. Do an rndc 
dumpdb right after the flush. Is the MX record still in there? If not, 
then flush isn't flushing properly. You might have to actually restart 
to get rid of it.


Curiosity question; do you use views? If so, are you flushing a 
particular view, or just doing a generic flush? I can't say with 100% 
certainty that BIND's default is to flush *all* views. Something to keep 
in mind.


If the record is gone from the cache (as verified above) before you 
query, but the stale record is showing up, then I'd double-check that 
your nameserver is getting this data from where you think it's getting 
it from. If your system isn't too busy, try to catch the queries on a 
tcpdump. Or, turn on debugging.


- Kevin

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

Re: Hostname Naming Compliance

[Mark Andrews]

In message <49a55a7f.8010...@ou.edu>, Peter Laws writes:
> Mark Andrews wrote:
> > When does it stop?  What will be the next character you
> > "just have to have"?  At the moment you have 1 inter label
> > seperator and 1 intra label seperator.  That should be
> > enough for anyone.
> 
> Like 640k of memory.
> 
> 
> Unicode is coming (as fast as IPv6, maybe faster :), so maybe it /is/ time 
> to update the naming standards.

Underscore is also illegal in idn.
 
> -- 
> Peter Laws / N5UWY
> National Weather Center / Network Operations Center
> University of Oklahoma Information Technology
> pl...@ou.edu
> ---
> Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

how to clear resolver cache?

[online-reg]

Hi All:

Bind 9.5.0-p1 on Fedora...how do I clear the cache?

I updated a FUBAR MX record at godaddy.com's NS, with a TTL of 3600. My 
local BIND seems to be caching the record after I updated at godaddy. When I 
query the upstream NS that the local server uses, it returns the updated MX 
record, but when I query localhost, I still get the old record.


I tried all of these:

rndc flush
rndc reload
/etc/rc.d/init.d/nscd restart

Where else would the old MX be cached? 


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

Re: File descriptors

[JINMEI Tatuya / 神明達哉]

At Wed, 25 Feb 2009 09:20:52 -0500,
Todd  wrote:

> My apologies again, you are correct.  I ran a named -v on the boxes,
> forgetting that we were directly calling bind in a non-path.  We are
> in fact using 9.4.2-P2 on everything, patched to protect against
> kaminsky.  We will look at an upgrade program to get these boxes
> (about 80 servers, unfortunately the majority of our infastructure)
> upgraded to protect against this.
> 
> Are there any suggestions that anyone can provide to mitigate against
> this coming up until such a time that we can upgrade?

- make sure the 'files' named.conf option is set to a small value (the
  default value should be fine)
- unless you need many number of TCP connections (which is unlikely if
  named is caching-only server) decrease the value for
  reserved-sockets (allowable minimum is 128 if I remember it
  correctly, which should be fine)

In addition, if your OS is Linux, the following two *MUST* also be
done:

- make sure named is built with some large number for
  ISC_SOCKET_FDSETSIZE.
- if your named is built with threads, make sure the allowable number
  of open files ('ulimit -n') is sufficiently large before starting
  named.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[SM]

At 13:46 25-02-2009, Mike Bernhardt wrote:

I've been looking into the RFCs regarding whether or not single-character
(alpha) host names are allowed or not. RFC 952 says no, but 2181 says that
host names must between 1 and 63 octets in length, which would appear to say
"yes."


Section 2.1 of RFC 1123 discusses the syntax for host names and 
clarifies RFC 952.  Host names can be up to 63 octets and the FQDNs 
up to 255 octets (RFC 2181).  You can have a single-character host 
name as long as it follows the syntax.


Regards,
-sm 


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

Re: single-character host names

[Matthew Pounsett]

On 25-Feb-2009, at 17:14, Evan Hunt wrote:


Actually, to be lawyerly about it, while RFC952 says you can't have
a single-character name, it also defines names as including periods
to delimit domain-name components.  So, "m.google.com." is really a
13-character name, with a single-character component at the beginning,
not a single-character name.


Serves me right to try to respond off the top of my head without  
checking the reference. :)


You're right, 952 talks about the DOD Host Table, and predates period- 
separated labels forming a FQDN becoming ubiquitous.  Most of what it  
dealt with are single-label names in that host table.


The OP should be looking to RFC1035 section 2.3.1 for the  
specification for modern host names.






PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Matthew Pounsett]

On 25-Feb-2009, at 16:46, Mike Bernhardt wrote:

So what is the accepted view on this currently? Is there another RFC  
that

has made it OK now?


I'm not going to say this definitively, because I'm not certain, but I  
think 952 may have been updated by a later RFC.  Certainly there are  
several examples of infrastructure, including the root name servers  
themselves, successfully using single-character host names.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: statschannel assertion failure

[JINMEI Tatuya / 神明達哉]

At Wed, 25 Feb 2009 14:17:27 -0600,
Timothy Holtzen  wrote:

> I applied the patch on my test system and ran my little test using wget
> and this is the output I got in the log
> 
> Feb 25 13:51:12 arthur named[17030]: libxml2 Error: Input is not proper
> UTF-8, indicate encoding !
> Feb 25 13:51:12 arthur named[17030]: libxml2 Error:
> xmlTextWriterWriteDocCallback : XML error 9 !
> Feb 25 13:51:12 arthur named[17030]: libxml2 Error: write error
> Feb 25 13:51:12 arthur named[17030]: statschannel.c:744: INSIST(xmlrc >=
> 0) failed
> Feb 25 13:51:12 arthur named[17030]: exiting (due to assertion failure)
> 
> Since it failed with the full patch I figured removing xmlInitParser()
> wouldn't make a difference.  I decided to try anyway and got the same
> result.

Okay, thanks for the confirmation.  Are you running named with
multiple threads on multiple processors?  If so, does the situation
change if you disable threads?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Evan Hunt]

> Certainly, several large organizations (Google, Yahoo and CNN, to name 3)
> are using at least 1: "m"

Not to mention all the root-server operators.  So the rule clearly
isn't being enforced very well. :)

Actually, to be lawyerly about it, while RFC952 says you can't have
a single-character name, it also defines names as including periods
to delimit domain-name components.  So, "m.google.com." is really a
13-character name, with a single-character component at the beginning,
not a single-character name.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

single-character host names

[Mike Bernhardt]

I've been looking into the RFCs regarding whether or not single-character
(alpha) host names are allowed or not. RFC 952 says no, but 2181 says that
host names must between 1 and 63 octets in length, which would appear to say
"yes."

Certainly, several large organizations (Google, Yahoo and CNN, to name 3)
are using at least 1: "m"

So what is the accepted view on this currently? Is there another RFC that
has made it OK now?

Mike


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

Re: File descriptors

[Todd]

I've done some more digging today - I have found a couple 9.2.4
servers that had the same file descriptors problem at the same time as
the 9.4.2-p2 servers.

Feb 24 13:28:48 dns01 named[29292]: socket: too many open file descriptors

Both servers named processes seem to have 2048 FD's available:

# grep FDSize /proc/29292/status
FDSize: 2048

So it would seem that 9.2.4 also has a problem.  We will still look to
upgrade these, but I wanted comment in case anyone else was having
problems and searching.

Cheers,

t.



On Tue, Feb 24, 2009 at 11:01 PM, JINMEI Tatuya / 神明達哉
 wrote:
> At Tue, 24 Feb 2009 15:10:36 -0500,
> Todd  wrote:
>
>> The servers in question are running a mix of BIND versions .. 9.2.3,
>> 9.2.4, 9.3.2, 9.3.4, 9.4.1, 9.4.2-p2, the majority are 9.3.4 and
>> 9.4.2-P2
>
> Then are confused somehow.  Among above, the only version that could
> cause the "too many open file descriptors" problem is 9.4.2-P2 (this
> doesn't mean you can safely use the others; they are vulnerable to the
> so-called 'Kaminsky' caching poisoning attacks).
>
> Regarding 9.4.2-P2, I'd strongly recommend to upgrade to 9.4.3-P1.
> 9.4.2-P2 has a fundamental performance problem due to the use of
> inefficient socket API, which has been solved in 9.4.3 and onward.
> If you still have the same problem with 9.4.3-P1, please report it
> again.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: No cache in a forward name server

[Kevin Darcy]

Luis Silva wrote:

Hi all!
I read in some previous posts that you don't agree of not having cache 
in a name server. The problem is that I wanted to have a bind server 
resolving external queries and doing cache but not for a specific zone 
that I use "forward".
 
client->ns#1(forward)->ns#2
 
That specific zone is private and authoritive and I didn't wanted to 
set up the ttl=0 because I want the clients to cache. Nameserver 2 
doesn't support zone transfer, so each time I chance the information 
in that server (the authoritive) the ns#1 will still continue to send 
incorrect data.
Can you help me? I read the manual and checked all the cache 
parameters with no success.
I find it odd that you want the clients to cache -- which means part of 
the time they'll be using "incorrect data" -- yet you object to the 
forwarder caching. I guess the data is dynamic but not _really_ dynamic 
(???)


In any case, BIND doesn't have a way to turn off the cache, so if you 
*really* need this functionality you'll need to use something else. It 
might be better to just come up with a reasonable TTL value and live 
with it. TTL=0 isn't the *only* choice for dynamic records. A 5-minute, 
or, if necessary, a 1-minute TTL might meet your requirements without 
forcing you to abandon using BIND for the forwarder.


The only other thing that comes to mind offhand is some kludge where you 
authomatically purge the cache entry on the forwarder (via rndc 
flushname) every time it's changed on the authoritative nameserver. But 
that's pretty gross.



- Kevin


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

Re: statschannel assertion failure

[Timothy Holtzen]

I applied the patch on my test system and ran my little test using wget
and this is the output I got in the log

Feb 25 13:51:12 arthur named[17030]: libxml2 Error: Input is not proper
UTF-8, indicate encoding !
Feb 25 13:51:12 arthur named[17030]: libxml2 Error:
xmlTextWriterWriteDocCallback : XML error 9 !
Feb 25 13:51:12 arthur named[17030]: libxml2 Error: write error
Feb 25 13:51:12 arthur named[17030]: statschannel.c:744: INSIST(xmlrc >=
0) failed
Feb 25 13:51:12 arthur named[17030]: exiting (due to assertion failure)

Since it failed with the full patch I figured removing xmlInitParser()
wouldn't make a difference.  I decided to try anyway and got the same
result.

JINMEI Tatuya / 神明達哉 wrote:
> At Tue, 24 Feb 2009 14:26:45 -0600,
> Timothy Holtzen  wrote:
>
>   
>> Hi guys I'm getting this assertion failure again under Bind 9.5.1-P1 on
>> RHEL 5.2.
>>
>> Feb 23 22:00:01 foo named[18476]: statschannel.c:696: INSIST(xmlrc >= 0)
>> failed
>> Feb 23 22:00:01 foo named[18476]: exiting (due to assertion failure)
>>
>> I posted about it once before.  I understand that this is caused by a
>> failure in xmlTextWriterEndElement() which should normally succeed.  It
>> was suggested last time that this could be caused by a memory allocation
>> failure and it was suggested that as a work around I suppress memory
>> usage using max-cache-size.  I went ahead and limited it to 130Meg and
>> have been monitoring since.  I've never seen the memory footprint for
>> bind go  up beyond a few hundred Meg on a system with 2Gig of ram so I'm
>> thinking that memory allocation may not be the problem.
>> 
>
> Can you try the patch copied below?  It will make allow named to log
> libxml internal errors.  Hopefully this will provide some hints about
> what happened.
>
> The patch also does libxml2 initialization at the named's own
> initialization step.  Most of our use of libxml2 should be
> thread-safe, but some of the initialization steps (which are currently
> triggered first time statistics is dump) could cause a race.
> If this is the case, it may fix the crash as well.  I actually doubt
> that, but if that is the case, please also try removing the following
> line in the patch:
>   xmlInitParser();
> to see whether you can reproduce it again.
>
> Thanks,
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
> Index: statschannel.c
> ===
> RCS file: /proj/cvs/prod/bind9/bin/named/statschannel.c,v
> retrieving revision 1.2.2.13.2.1
> diff -u -r1.2.2.13.2.1 statschannel.c
> --- statschannel.c18 Dec 2008 02:39:12 -  1.2.2.13.2.1
> +++ statschannel.c25 Feb 2009 04:14:21 -
> @@ -109,10 +109,58 @@
>  #endif
>  }
>  
> +#ifdef HAVE_LIBXML2
> +static void
> +error_libxml2(void *ctx, xmlErrorPtr error) {
> + xmlParserCtxtPtr pctx;
> + ns_server_t *server = ctx;
> + char *msg, *cp;
> +
> + REQUIRE(server != NULL);
> + REQUIRE(error != NULL);
> +
> + /*
> +  * Save the error code, if available, so that it can be used in the main
> +  * code.  No lock is necessary here.
> +  */
> + pctx = error->ctxt;
> + if (pctx != NULL && pctx->myDoc != NULL &&
> + pctx->myDoc->_private != NULL) {
> + *(int *)pctx->myDoc->_private = error->code;
> + }
> +
> + /*
> +  * Log the error message.  Since some libxml2 error messages are
> +  * terminated with a CR, we make a local copy to remove it.  This is
> +  * expensive, but should be okay as we don't expect to see libxml2
> +  * errors so often.
> +  */
> + if (error->message != NULL) {
> + msg = isc_mem_strdup(server->mctx, error->message);
> + if (msg == NULL)
> + return;
> + cp = strchr(msg, '\n');
> + if (cp != NULL)
> + *cp = '\0';
> +
> + isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
> +   NS_LOGMODULE_SERVER, ISC_LOG_INFO,
> +   "libxml2 Error: %s", msg);
> +
> + isc_mem_free(server->mctx, msg);
> + }
> +}
> +#endif
> +
>  static void
>  init_desc(void) {
>   int i;
>  
> +#ifdef HAVE_LIBXML2
> + xmlSetStructuredErrorFunc(ns_g_server, error_libxml2);
> + xmlInitParser();
> +#endif
> +
>   /* Initialize name server statistics */
>   memset(nsstats_desc, 0,
>  dns_nsstatscounter_max * sizeof(nsstats_desc[0]));
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>   

-- 
Timothy A. Holtzen
Campus Network Administrator
Nebraska Wesleyan University

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

No cache in a forward name server

[Luis Silva]

Hi all!
I read in some previous posts that you don't agree of not having cache in a
name server. The problem is that I wanted to have a bind server
resolving external queries and doing cache but not for a specific zone that
I use "forward".

 client->ns#1(forward)->ns#2

That specific zone is private and authoritive and I didn't wanted to set up
the ttl=0 because I want the clients to cache. Nameserver 2 doesn't support
zone transfer, so each time I chance the information in that server (the
authoritive) the ns#1 will still continue to send incorrect data.
Can you help me? I read the manual and checked all the cache parameters with
no success.
Thanks in advance,
Luis
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named reload does not reload correct

[Jeremy C. Reed]

On Wed, 25 Feb 2009, Martin Moerman wrote:

> Hello,
>  
> I have an issue with 9.5.3 on which I see that bind does a reload of the
> named.conf but does not reload the include files which are in named.conf

9.5.3 doesn't exist.

> Situation:
> I do an add or change of name / ip in Plesk, plesk nicely rsyncs the
> zone files to our two name servers.

So plesk transfers same content to multiple servers? (Wonder why it 
doesn't just update master and let BIND handle the secondaries.)

> nameserver 2 reloads correctly, nameserver 1 says it does a reload but
> if i test on this server the change it doesn't show up.

How does plesk tell the nameservers to reload?

Same version of BIND on both? What version(s)?

> if I do a stop / start then the change is done.
>  
> Any ideaas , brainwaves welcome ?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Finding and culling unused entries from zone files

[Keith Christian]

I'm looking for a method to cull out unused DNS entries from zone files.

Eventually, entries we add to zone files entries fall into disuse.
Usually the customers never report when this happens, so the zone
files grow and grow and grow with "cruft."

Can any of you share recommendations?  I'm running bind-9.5.1, are
there logging entries that are particularly useful for statistical
collection that could be analyzed to offer guidance?

Thanks.

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

Re: Hostname Naming Compliance

[Peter Laws]

Mark Andrews wrote:

When does it stop?  What will be the next character you
"just have to have"?  At the moment you have 1 inter label
seperator and 1 intra label seperator.  That should be
enough for anyone.


Like 640k of memory.


Unicode is coming (as fast as IPv6, maybe faster :), so maybe it /is/ time 
to update the naming standards.


--
Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
---
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Hostname Naming Compliance

[Peter Laws]

Jeff Lightner wrote:

And of course you can legitimately say it is a "Standard" even if it
isn't enforced by the software.   Your argument would be that people
implementing new servers or attempting to access the systems wouldn't be
able to do so because they wouldn't have added the "exception to
Standard" that your PHBs are requiring.


I've been telling folks that request _ in a name that they can no longer do 
that and change it to a -.  I tell them that it *works*, but it violates 
the standards.  No pushback yet.


--
Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
---
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Unexpected error question

[Stacey Jonathan Marshall]

Just following this question up.  The answer was that the user specified 
in the smf_method(5) property needs to have
solaris.smf.manage.bind authorization to be able to disable the 
service.  I've opened a bug to update the Sun manual page, CR 6809900 
Created, P4 manpage/section1m named(1M) should be updated to document 
solaris.smf.manage.bind authorization.


In the mean time I've updated my blog 
 with 
instructions.


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

named reload does not reload correct

[Martin Moerman]

Hello,
 
I have an issue with 9.5.3 on which I see that bind does a reload of the
named.conf but does not reload the include files which are in named.conf
 
Situation:
I do an add or change of name / ip in Plesk, plesk nicely rsyncs the
zone files to our two name servers.
nameserver 2 reloads correctly, nameserver 1 says it does a reload but
if i test on this server the change it doesn't show up.
 
if I do a stop / start then the change is done.
 
Any ideaas , brainwaves welcome ?
 
regards
martin
 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ARPA entries for a host with multiple IPs

[shulkae]

Question on BIND 9 running on FreeBSD.

My customer requested to add multiple IPs to a single name so that he
can use the round-robin feature of BIND to load-balance the service.

The entry we added looks something as below:

# more db.myzone
..
..
ws   
..
..

So when my customer query the ws, he gets one of ipX any any given
time. They never requested anything
for updating ARPA entries for the above.

What would be the ARPA  entries for each of these? ip1, ip2 and ip3?
Can I add 'ws' for each of these?
I haven't seen any references to do this either in BIND ARM or DNS/
Bind Book.

Any tips from experienced folks?

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

Re: File descriptors

[Todd]

My apologies again, you are correct.  I ran a named -v on the boxes,
forgetting that we were directly calling bind in a non-path.  We are
in fact using 9.4.2-P2 on everything, patched to protect against
kaminsky.  We will look at an upgrade program to get these boxes
(about 80 servers, unfortunately the majority of our infastructure)
upgraded to protect against this.

Are there any suggestions that anyone can provide to mitigate against
this coming up until such a time that we can upgrade?

Thank you,

Todd.

On Tue, Feb 24, 2009 at 11:01 PM, JINMEI Tatuya / 神明達哉
 wrote:
> At Tue, 24 Feb 2009 15:10:36 -0500,
> Todd  wrote:
>
>> The servers in question are running a mix of BIND versions .. 9.2.3,
>> 9.2.4, 9.3.2, 9.3.4, 9.4.1, 9.4.2-p2, the majority are 9.3.4 and
>> 9.4.2-P2
>
> Then are confused somehow.  Among above, the only version that could
> cause the "too many open file descriptors" problem is 9.4.2-P2 (this
> doesn't mean you can safely use the others; they are vulnerable to the
> so-called 'Kaminsky' caching poisoning attacks).
>
> Regarding 9.4.2-P2, I'd strongly recommend to upgrade to 9.4.3-P1.
> 9.4.2-P2 has a fundamental performance problem due to the use of
> inefficient socket API, which has been solved in 9.4.3 and onward.
> If you still have the same problem with 9.4.3-P1, please report it
> again.
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users