BIND 9.8.2rc2 is now available

[Michael McNally]

Introduction
 
  BIND 9.8.2rc2 is the second release candidate for BIND 9.8.2.

  This document summarizes changes from BIND 9.8.1 to BIND 9.8.2rc2.
  Please see the CHANGES file in the source code release for a complete
  list of all changes.

Download
   
  The latest versions of BIND 9 software can always be found on our
  web site at http://www.isc.org/downloads/all. There you will find
  additional information about each release, source code, and
  pre-compiled versions for Microsoft Windows operating systems.

Support

  Product support information is available on
  http://www.isc.org/services/support for paid support options. Free
  support is provided by our user community via a mailing list.
  Information on all public email lists is available at
  https://lists.isc.org/mailman/listinfo.

Security Fixes

 Previously included in 9.8.2rc1

  + BIND 9 nameservers performing recursive queries could cache an
invalid record and subsequent queries for that record could
crash the resolvers with an assertion failure. [RT #26590]
[CVE-2011-4313]

Feature Changes

 Newly added in 9.8.2rc2

  + RPZ implementation now conforms to version 3 of the specification.
[RT #27316] 

 Previously included in 9.8.2rc1

  + It is now possible to explicitly disable DLV in named.conf by
specifying "dnssec-lookaside no;". This is the default, but the
ability to configure it makes it clearly visible to administrators.
[RT #24858]

  + --enable-developer, a new composite argument to the configure
script, enables a set of build options normally disabled but
frequently selected in test or development builds, specifically:
enable_fixed_rrset, with_atf, enable_filter_, enable_rpz_nsip,
enable_rpz_nsdname, and with_dlz_filesystem (and on Linux and
Darwin, also enable_exportlib) [RT #27103]

Bug Fixes

 Newly added in 9.8.2rc2

  + Corrects a potential overflow problem in the computation of
RRSIG expiration times. [RT #23311]

  + The maximum number of NSEC3 iterations for a DNSKEY RRset was
not being properly computed.  [RT #26543]

  + Error reporting has been improved for failures encountered
when sending or receiving network packets.  In particular
some memory allocation failures were being logged as "unexpected
error" - these will now be reported accurately.  A new
ISC_R_UNSET result code has also been added to cover those
situations where there is no error code returned by the OS
sockets implementation.  [RT #27336]

  + Corrects an INSIST failure by addressing race conditions in
the handling of rbtnode.deadlink. [RT #27738]

  + SOA refresh queries could be treated as cancelled despite
succeeding over the loopback interface. [RT #27782]

  + When replacing an NS RRset, BIND now restricts the TTL of the
new NS RRset to no more than that of the NS RRset it replaces
to fix a timing problem that can arise when removing a delegation.
[RT #27792/27884]

  + Raw zones with with more than 512 records in a RRset previously
failed to load. [RT #27863]

  + Make sure automatic key maintenance is started when "rndc reconfig"
is issued if "auto-dnssec maintain" is turned on. [RT #26805]

  + Windows builds are now restricted to a single listener thread
until incompatibility with the multiple listeners code can be
addressed [RT #27696]

  +  responses could be returned in the additional section even
when filter--on-v4 was in use. [RT #27292]

  + An error handling an out of memory condition could cause a stored
rdataset to be freed twice using DNS64. [RT #27762]

 Previously included in 9.8.2rc1

  + Some query patterns could cause responses not to be returned
in cyclic order though "rrset-order cyclic" was set.  [RT
#27170/27185]

  + named-compilezone now longer emits "dump zone to " message
when writing to stdout.  [RT #27109]

  + Sets isc_socket_ipv6only() on the IPv6 control channels.  This
addresses IPv6 socket binding problems that can occur in some
configurations when bindv6only=1 is set globally.   [RT #22249]

  + named now reports a syntax error when a TXT record longer than
255 characters is configured.  [RT #26956]

  + Addresses race conditions in the resolver code that can cause
named to abort.   [RT #26889]

  + Fixed a bug that could cause named to crash while loading a
zone with invalid DNSKEY records.  [RT #26913]

  + Prevents  dig -6 +trace from terminating with an error when
encountering a root nameserver without an  record. RT #26906]

  + Prevents DNSKEY state change events from being missed by ensuring
that the timestamps used to determine which keys are in use are
set appropriately.  [RT #26874]

  + When processing a list of keys, named now consistently compares
them with the same timestamp. [RT #26883]

  + Fixed a corner case race condition in the validator that may
cause an assert in a multi-threaded build of

BIND 9.7.5rc2 is now available

[Michael McNally]

Introduction

  BIND 9.7.5rc2 is the second release candidate for BIND 9.7.5.

  This document summarizes changes from BIND 9.7.4 to BIND 9.7.5rc2.
  Please see the CHANGES file in the source code release for a
  complete list of all changes.

Download

  The latest versions of BIND 9 software can always be found on our
  web site at http://www.isc.org/downloads/all. There you will find
  additional information about each release, source code, and
  pre-compiled versions for Microsoft Windows operating systems.

Support

  Product support information is available on
  http://www.isc.org/services/support for paid support options.
  Free support is provided by our user community via a mailing list.
  Information on all public email lists is available at
  https://lists.isc.org/mailman/listinfo.

Security Fixes

 Previously included in 9.7.5rc1

  + BIND 9 nameservers performing recursive queries could cache an
invalid record and subsequent queries for that record could
crash the resolvers with an assertion failure. [RT #26590]
[CVE-2011-4313]

Feature Changes

 Previously included in 9.7.5rc1

  + It is now possible to explicitly disable DLV in named.conf by
specifying "dnssec-lookaside no;". This is the default, but the
ability to configure it makes it clearly visible to administrators.
[RT #24858]

  + --enable-developer, a new composite argument to the configure
script, enables a set of build options normally disabled but
frequently selected in test or development builds, specifically:
enable_fixed_rrset, with_atf, enable_filter_, enable_rpz_nsip,
enable_rpz_nsdname, and with_dlz_filesystem (and on Linux and
Darwin, also enable_exportlib) [RT #27103]

Bug Fixes

 Newly added in 9.7.5rc2

  + Corrects a potential overflow problem in the computation of
RRSIG expiration times. [RT #23311]

  + The maximum number of NSEC3 iterations for a DNSKEY RRset was
not being properly computed.  [RT #26543]

  + Error reporting has been improved for failures encountered
when sending or receiving network packets.  In particular
some memory allocation failures were being logged as "unexpected
error" - these will now be reported accurately.  A new
ISC_R_UNSET result code has also been added to cover those
situations where there is no error code returned by the OS
sockets implementation.  [RT #27336]

  + Corrects an INSIST failure by addressing race conditions in
the handling of rbtnode.deadlink. [RT #27738]

  + SOA refresh queries could be treated as cancelled despite
succeeding over the loopback interface. [RT #27782]

  + When replacing an NS RRset, BIND now restricts the TTL of the
new NS RRset to no more than that of the NS RRset it replaces
to fix a timing problem that can arise when removing a delegation.
[RT #27792/27884]

  + Raw zones with with more than 512 records in a RRset previously
failed to load. [RT #27863]

  + Make sure automatic key maintenance is started when "rndc reconfig" 
is issued if "auto-dnssec maintain" is turned on. [RT #26805]

  + Windows builds are now restricted to a single listener thread
until incompatibility with the multiple listeners code can be
addressed [RT #27696]

  +  responses could be returned in the additional section even
when filter--on-v4 was in use. [RT #27292]

 Previously included in 9.7.5rc1

  + Some query patterns could cause responses not to be returned
in cyclic order though "rrset-order cyclic" was set.  [RT
#27170/27185]

  + named-compilezone now longer emits "dump zone to " message
when writing to stdout.  [RT #27109]

  + Sets isc_socket_ipv6only() on the IPv6 control channels.  This
addresses IPv6 socket binding problems that can occur in some
configurations when bindv6only=1 is set globally.   [RT #22249]

  + named now reports a syntax error when a TXT record longer than
255 characters is configured.  [RT #26956]

  + Addresses race conditions in the resolver code that can cause
named to abort.   [RT #26889]

  + Fixed a bug that could cause named to crash while loading a
zone with invalid DNSKEY records.  [RT #26913]

  + Prevents  dig -6 +trace from terminating with an error when
encountering a root nameserver without an  record. RT #26906]

  + Prevents DNSKEY state change events from being missed by ensuring
that the timestamps used to determine which keys are in use are
set appropriately.  [RT #26874]

  + When processing a list of keys, named now consistently compares
them with the same timestamp. [RT #26883]

  + Fixed a corner case race condition in the validator that may
cause an assert in a multi-threaded build of BIND.  [RT #26478]

  + Poor error handling could cause named to hang during shutdown.
[RT #26372]

  + named now correctly validates DNSSEC positive wildcard responses
from NSEC3 signed zones. [RT #26200]

  + The order in which we process the rea

BIND 9.6-ESV-R6rc2 is now available

[Michael McNally]

Introduction

  BIND 9.6-ESV-R6rc2 is the second release candidate for BIND 9.6-ESV-R6.

  This document summarizes changes from BIND 9.6-ESV-R5 to BIND
  9.6-ESV-R6rc2.  Please see the CHANGES file in the source code
  release for a complete list of all changes.  Please see the CHANGES
  file in the source code release for a complete list of all changes.

Download

  The latest versions of BIND 9 software can always be found on our
  web site at http://www.isc.org/downloads/all. There you will find
  additional information about each release, source code, and
  pre-compiled versions for Microsoft Windows operating systems.

Support

  Product support information is available on
  http://www.isc.org/services/support for paid support options.
  Free support is provided by our user community via a mailing list.
  Information on all public email lists is available at
  https://lists.isc.org/mailman/listinfo.

Security Fixes

 Previously included in 9.6-ESV-R6rc1

  + BIND 9 nameservers performing recursive queries could cache an
invalid record and subsequent queries for that record could
crash the resolvers with an assertion failure. [RT #26590]
[CVE-2011-4313]

Feature Changes

 Previously included in 9.6-ESV-R6rc1

  + Improves initial start-up and server reload time by increasing
the default size of the hash table the configuration parser
uses to keep track of loaded zones and allowing it to grow
dynamically to better handle systems with large numbers of
zones.  [RT #26523]

  + --enable-developer, a new composite argument to the configure
script, enables a set of build options normally disabled but
frequently selected in test or development builds, specifically:
enable_fixed_rrset, with_atf, enable_filter_, enable_rpz_nsip,
enable_rpz_nsdname, and with_dlz_filesystem (and on Linux and
Darwin, also enable_exportlib) [RT #27103]

Bug Fixes

 Newly added in 9.6-ESV-R6rc2

  + Corrects a potential overflow problem in the computation of
RRSIG expiration times. [RT #23311]

  + The maximum number of NSEC3 iterations for a DNSKEY RRset was
not being properly computed.  [RT #26543]

  + Error reporting has been improved for failures encountered
when sending or receiving network packets.  In particular
some memory allocation failures were being logged as "unexpected
error" - these will now be reported accurately.  A new
ISC_R_UNSET result code has also been added to cover those
situations where there is no error code returned by the OS
sockets implementation.  [RT #27336]

  + Corrects an INSIST failure by addressing race conditions in
the handling of rbtnode.deadlink. [RT #27738]

  + SOA refresh queries could be treated as cancelled despite
succeeding over the loopback interface. [RT #27782]

  + When replacing an NS RRset, BIND now restricts the TTL of the
new NS RRset to no more than that of the NS RRset it replaces
to fix a timing problem that can arise when removing a delegation. 
[RT #27792/27884]

  + Raw zones with with more than 512 records in a RRset previously
failed to load. [RT #27863]

 Previously included in 9.6-ESV-R6rc1

  + Some query patterns could cause responses not to be returned
in cyclic order though "rrset-order cyclic" was set.  [RT
#27170/27185]

  + named-compilezone now longer emits "dump zone to " message
when writing to stdout.  [RT #27109]

  + Sets isc_socket_ipv6only() on the IPv6 control channels.  This
addresses IPv6 socket binding problems that can occur in some
configurations when bindv6only=1 is set globally.   [RT #22249]

  + named now reports a syntax error when a TXT record longer than
255 characters is configured.  [RT #26956]

  + Addresses race conditions in the resolver code that can cause
named to abort.   [RT #26889]

  + Fixed a bug that could cause named to crash while loading a
zone with invalid DNSKEY records.  [RT #26913]

  + Prevents  dig -6 +trace from terminating with an error when
encountering a root nameserver without an  record. RT #26906]

  + An unusual corner-case buffer handling issue in zone transfers
is corrected.  The symptom was that zones that contain record
types that do not compress when converted to wire format could
fail to transfer.  [RT #26796]

  + Addresses a selection of minor resource leaks (that were
identified via code checking tools but which have not been
reported from any production environments).  [RT #26624]

  + Fixed a corner case race condition in the validator that may
cause an assert in a multi-threaded build of BIND.  [RT #26478]

  + named now correctly validates DNSSEC positive wildcard responses
from NSEC3 signed zones. [RT #26200]

  + The order in which we process the reactivation of a dead node
in cache and the incrementing of its reference count created a
small timing window during which an inconsistency could be
detected and an a

max-cache-ttl usage and best-practices

[Fr34k]

Hi All,


I wanted some feedback on max-cache-ttl usage and best-practices, please.


The BIND 9 ARM says:
"max-cache-ttl Sets the maximum time for which the server will cache ordinary 
(positive) answers. The
default is one week (7 days). A value of zero may cause all queries to return 
SERVFAIL, because
of lost caches of intermediate RRsets (such as NS and glue /A records) in 
the resolution
process."

I was considering changing this setting to something less than the default of a 
week with the following potential positive outcomes in mind:

 1 - mitigating cache abuse (e.g., ghost domains),
 2 - reducing the caching of "bad" records (e.g., poor hostname migration 
planning on the part of external party turns into an emergency on our part to 
flush the "bad" record(s) from the cache),
 3- or something else for which others may be using this setting for (?)

Perhaps regardless of the above, anyone have some experiences to share?

Thank you.



ADDITIONAL INFO: 


http://dyn.com/dyn-tech-everything-you-ever-wanted-to-know-about-ttls/
 "A good rule of thumb is never have any TTL higher than 1 day as the 
benefits of DNS caching really diminish after that point and it makes 
propagation waits extremely long."


http://en.wikipedia.org/wiki/Time_to_live
 "An older common TTL value for DNS was 86400 seconds, which is 24 hours."  
and  "Newer DNS methods that are part of a DR (Disaster Recovery) system may 
have some records deliberately set extremely low on TTL. For example a 
300 second TTL..."


It would not be fair to exclude the negative aspects of some "too low" 
setting.  For example, contributing to cache misses and, thus, a decrease in 
performance (a la http://code.google.com/speed/public-dns/docs/performance.html 
and, to some extent, the data found in the research for 
http://lib.tkk.fi/Diss/2006/isbn9512282151/article2.pdf).
___
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: with subject: NS record for subzone definition

[Chris Buxton]

On Mar 13, 2012, at 6:23 AM, hugo hugoo wrote:
> I have zone "toto.be" with some records (not important)
>  
> In the same name server, I want to create the subzone "titi.toto.be" with 
> some records.
>  
>  
> ==> do I have to create in zone "toto.be" the following NS record:
>  
>  titi.toto.be.   TTL   IN   NSns1.xxx.be
>  
>  
> I have found cases where this situation is present and other when it is not 
> present...and both cases seems to work.
> What is the difference?

Yes, you should create the NS records. If you are using the exact same set of 
servers for the subzone as for the child, and are not using DNSSEC, you can get 
away without the NS records, but you shouldn't get into this bad habit.

Regards,
Chris Buxton
BlueCat Networks

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

[Mark Andrews]

In message , Daniel McDonald writ
es:
> 
> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> 
> > ==> do I have to create in zone "toto.be" the following NS record:
> >  
> >  titi.toto.be.   TTL   IN   NSns1.xxx.be
> >  
> >  
> > I have found cases where this situation is present and other when it is not
> > present...and both cases seems to work.
> > What is the difference?
> 
> The glue records aren't necessary when both the zone and subzone are on the
> same server, although it is good to have them for completeness.  When the
> zones are on different servers you need the glue records.

No, they *are* necessary.  Just because their lack does not cause
a resolution failure in all cases it doesn't mean they are not
necessary.

If the parent zone is signed but the child zone is unsigned then
the lack of NS records *will* cause validation failures unless
OPTOUT is in use even when both zones are only served by a common
set of servers.

DNSSEC catches out lots of bad practices that mostly pass unnoticed
with plain DNS.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: NS record outside of our name space

[Alan Clegg]

On 3/13/2012 1:35 PM, King, Harold Clyde (Hal) wrote:
> I tried adding the NS records but it looked like the entire example.com
> was now subject to the NS of wordpress.com. I just want the sub domain to
> get it's DNS from the wordpress.com NS servers. Not to give away my  whole
> example.com domain.

Not if you followed the example I gave.

The NS records at the zone apex (with nothing in the label field, thus
"example.com") define the zone.

The NS records at the "wordpress" label delegate that zone to the given
servers.

AlanC
-- 
a...@clegg.com | 1.919.355.8851



signature.asc
Description: OpenPGP digital 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: NS record outside of our name space

[King, Harold Clyde (Hal)]

I tried adding the NS records but it looked like the entire example.com
was now subject to the NS of wordpress.com. I just want the sub domain to
get it's DNS from the wordpress.com NS servers. Not to give away my  whole
example.com domain.
 

-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599





On 3/13/12 11:04 AM, "Alan Clegg"  wrote:

>On 3/13/2012 9:49 AM, King, Harold Clyde (Hal) wrote:
>> Here's an example of my zone record:
>> 
>> $ORIGIN .
>> $TTL 1800   ; 30 minutes
>> Wordpress.example.com. IN SOA  hiddenmaster.example.com.
>> ipmgr.example.com. (
>> 2012020601 ; serial
>> 10800  ; refresh (3 hours)
>> 1800   ; retry (30 minutes)
>> 604800 ; expire (1 week)
>> 900; minimum (15 minutes)
>> )
>> $TTL 28800  ; 8 hours
>> NS  NS1.WORDPRESS.COM.
>> NS  NS2.WORDPRESS.COM.
>> NS  NS3.WORDPRESS.COM.
>> $ORIGIN wordpress.example.com.
>> $TTL 900; 15 minutes
>> www CNAME   wordpress.example.com.
>
>What are you actually trying to do?  If all you are trying to do is
>"give away" the zone, you want these NS records to be in the
>example.com. zone .. ie:
>
>example.com.   IN SOA ( <...> )
>   IN NS  ns1.example.com.
>   IN NS  ns2.example.com.
>
>wordpress  IN NS  ns1.wordpress.com.
>   IN NS  ns2.wordpress.com.
>   IN NS  ns3.wordpress.com.
>
>AlanC
>-- 
>a...@clegg.com | 1.919.355.8851
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>unsubscribe from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users


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

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

Re: DNS requests error sending response: host unreachable

[Romgo]

All right.

this seems to correct the issue.
But that's the first time I had to open the firewall for a packet answer.

weird.

Thanks for the help.



On 13 March 2012 10:19,  wrote:

> Zitat von Romgo :
>
>
>  I see, but It should be statefull right ?
>>
>>
> If using stateful UPD filtering you might get hit by short timeout values
> for UDP state matching, so packets get dropped if the query is too slow.
>
> Regards
>
> Andreas
>
>
> __**_
> Please visit 
> https://lists.isc.org/mailman/**listinfo/bind-usersto
>  unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: NS record for subzone definition

[hugo hugoo]

Thanks for this interesting feedback.
Now I have the problem to detect this kind of bad configuration.
 
If I have:
 
Zone toto.be:
 
toto.be.
 
NS  ns1.xxx.be
 
+ some records
 
 
Zone titi.toto.be:
 
 
titi.toto.be.
 
 NS   ns1.xxx.be
 
  + some records.
 
 
What will be the command to detect that zone toto.be has no NS for titi.toto.be 
??
 
 
Regards,
 
Hugo,

 

> Date: Tue, 13 Mar 2012 15:03:38 +
> From: c...@cam.ac.uk
> To: hugo...@hotmail.com
> CC: ben.crosw...@gmail.com; bind-users@lists.isc.org
> Subject: Re: NS record for subzone definition
> 
> On Mar 13 2012, hugo hugoo wrote:
> 
> >Thanks for this clear feedback.
> >
> >I understand the problem if the subdomain is not on the same name servers
> >as the domain. The NS record is needed to could find the subdomain on the
> >other name server.
> > 
> >You said that the NS is not mandatory (it will work fine in the short term)
> >in case of the same name server for the domai nand the subdomain. But how
> >does it work then if no NS is found?
> 
> When asked about "tutu.titi.toto.be", the "be" nameservers give a referral
> to the nameservers for "toto.be". When *they* are asked, if they are already
> authoritative for the zone "titi.toto.be", they can answer the question
> without giving another referral.
> 
> But as has been pointed out, such a configuration is horribly fragile. The
> set of nameservers (official *and* unofficial) for the zones have to be
> the same, and it won't work anyway if the zones are signed, and so on.
> 
> One question to ask is: if the set of nameservers for "toto.be" and
> "titi.toto.be" are now and for evermore going to be the same, why would
> you want to make them separate zones at all? A single zone can have
> domain names nested as deep as you like[*] without you needing to make
> a zone cut.
> 
> [*] subject to the overall limit of 253 characters on the fully
> qualified name
> 
> -- 
> Chris Thompson
> Email: c...@cam.ac.uk
  ___
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: Recursive queries fail after bind has been running for a few hours

[Mr X]

On Mon, Mar 12, 2012 at 3:37 PM, Kevin Oberman  wrote:

> On Mon, Mar 12, 2012 at 12:05 PM, Mr X  wrote:
> > Hey there
> >
> > I'm having a bizarre issue with 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2 -
> > recursive queries stop functioning after bind has been running for a few
> > hours. It's a very low volume system (dev), maybe a few queries per hour
> at
> > most. It's not due to cache filling or anything like I've dealt with in
> the
> > past. I suspect it's related to DNSSEC and root-server validation but I
> > could use another set of eyes on my debug log. Sorry for posting from a
> > inconspicuous e-mail address. My employer asks that I'm careful about the
> > information I disclose on public mailing lists.
> >
> > You can see my debug log during a failed query
> > http://pastebin.com/5hh05WjM
> >
> > Successful query here
> > http://pastebin.com/H9qSQcyG
> >
> > If you would like to see my config, I can include portions, but it's
> huge so
> > please let me know exactly what parts you're looking for.
>
> You are getting timeouts for some reason. The obvious question is
> whether the queries are actually being sent or whether they and and
> responses are not coming back. Or,perhaps the response IS coming back,
> but named is not picking them up.
>
> Could you try getting a packet capture? As these are UDP and assuming
> Unix, something like 'tcpdump -w badquery.bpf -s0 -p port 53`. This
> will capture all DNS traffic to/from this system, but you say it is
> not all that much, so it should be tractable.
>
> Once you have captured the data, you can use a tool like wireshark to
> look at it.
>


I had to sanitize some data, so the -vvv output of the packet capture is
here:

http://pastebin.com/GKSspL2L

Unfortunately this server is both authoritative and recursive. I have an
upcoming project to segment these two functions, but for now getting this
host operational is my priority. It's also worth mentioning that I have IO
data center nameservers as a forwarder as seen in this packet capture. When
bind is in a failed state I can query against these nameservers directly -
so I had not considered this a potential cause.

I really appreciate everyones help.


> --
> R. Kevin Oberman, Network Engineer
> E-mail: kob6...@gmail.com
>
___
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: NS record outside of our name space

[Alan Clegg]

On 3/13/2012 9:49 AM, King, Harold Clyde (Hal) wrote:
> Here's an example of my zone record:
> 
> $ORIGIN .
> $TTL 1800   ; 30 minutes
> Wordpress.example.com. IN SOA  hiddenmaster.example.com.
> ipmgr.example.com. (
> 2012020601 ; serial
> 10800  ; refresh (3 hours)
> 1800   ; retry (30 minutes)
> 604800 ; expire (1 week)
> 900; minimum (15 minutes)
> )
> $TTL 28800  ; 8 hours
> NS  NS1.WORDPRESS.COM.
> NS  NS2.WORDPRESS.COM.
> NS  NS3.WORDPRESS.COM.
> $ORIGIN wordpress.example.com.
> $TTL 900; 15 minutes
> www CNAME   wordpress.example.com.

What are you actually trying to do?  If all you are trying to do is
"give away" the zone, you want these NS records to be in the
example.com. zone .. ie:

example.com.IN SOA ( <...> )
IN NS  ns1.example.com.
IN NS  ns2.example.com.

wordpress   IN NS  ns1.wordpress.com.
IN NS  ns2.wordpress.com.
IN NS  ns3.wordpress.com.

AlanC
-- 
a...@clegg.com | 1.919.355.8851



signature.asc
Description: OpenPGP digital 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: NS record for subzone definition

[Chris Thompson]

On Mar 13 2012, hugo hugoo wrote:


Thanks for this clear feedback.

I understand the problem if the subdomain is not on the same name servers
as the domain. The NS record is needed to could find the subdomain on the
other name server.

You said that the NS is not mandatory (it will work fine in the short term)
in case of the same name server for the domai nand the subdomain. But how
does it work then if no NS is found?


When asked about "tutu.titi.toto.be", the "be" nameservers give a referral
to the nameservers for "toto.be". When *they* are asked, if they are already
authoritative for the zone "titi.toto.be", they can answer the question
without giving another referral.

But as has been pointed out, such a configuration is horribly fragile. The
set of nameservers (official *and* unofficial) for the zones have to be
the same, and it won't work anyway if the zones are signed, and so on.

One question to ask is: if the set of nameservers for "toto.be" and
"titi.toto.be" are now and for evermore going to be the same, why would
you want to make them separate zones at all? A single zone can have
domain names nested as deep as you like[*] without you needing to make
a zone cut.

[*] subject to the overall limit of 253 characters on the fully
   qualified name

--
Chris Thompson
Email: c...@cam.ac.uk
___
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:

[hugo hugoo]

Thanks for this clear feedback.
I understand the problem if the subdomain is not on the same name servers as 
the domain.
The NS record is needed to could find the subdomain on the other name server.
 
You said that the NS is not mandatory (it will work fine in the short term) in 
case of the same name server for the domai nand the subdomain.
But how does it work then if no NS is found?
 
 
regards,
 
 
Hugo,
 



Date: Tue, 13 Mar 2012 10:02:32 -0400
Subject: RE:
From: ben.crosw...@gmail.com
To: hugo...@hotmail.com
CC: bind-users@lists.isc.org; dan.mcdon...@austinenergy.com


If you do not delegate the subdomains with NS records you are not fully 
delegating the subdomain. 
It will work fine in the short term, but are setting up a landmine for someone 
to step on later.
If decide to move that subdomain to other dns servers later it will disappear 
without the NS records. 
The best practice is to always put the NS records and not leave it to chance. 
On Mar 13, 2012 9:43 AM, "hugo hugoo"  wrote:



Thanks for the feedback.
Is this a glue record? I do not have any IP defined in the NS record.
 
What is the flow of a request to a subzone?
Is the content of the zone checked before checking the subzone?

 


> Date: Tue, 13 Mar 2012 08:26:02 -0500
> Subject: Re: 
> From: dan.mcdon...@austinenergy.com
> To: hugo...@hotmail.com; bind-users@lists.isc.org
> 
> 
> 
> 
> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> 
> > ==> do I have to create in zone "toto.be" the following NS record:
> > 
> > titi.toto.be. TTL IN NS ns1.xxx.be
> > 
> > 
> > I have found cases where this situation is present and other when it is not
> > present...and both cases seems to work.
> > What is the difference?
> 
> The glue records aren't necessary when both the zone and subzone are on the
> same server, although it is good to have them for completeness. When the
> zones are on different servers you need the glue records.
> 
> 
> 
> -- 
> Daniel J McDonald, CCIE # 2495, CISSP # 78281
> 

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

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

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

RE:

[Ben Croswell]

If you do not delegate the subdomains with NS records you are not fully
delegating the subdomain.
It will work fine in the short term, but are setting up a landmine for
someone to step on later.
If decide to move that subdomain to other dns servers later it will
disappear without the NS records.

The best practice is to always put the NS records and not leave it to
chance.
On Mar 13, 2012 9:43 AM, "hugo hugoo"  wrote:

>  Thanks for the feedback.
> Is this a glue record? I do not have any IP defined in the NS record.
>
> What is the flow of a request to a subzone?
> Is the content of the zone checked before checking the subzone?
>
>
>  > Date: Tue, 13 Mar 2012 08:26:02 -0500
> > Subject: Re:
> > From: dan.mcdon...@austinenergy.com
> > To: hugo...@hotmail.com; bind-users@lists.isc.org
> >
> >
> >
> >
> > On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> >
> > > ==> do I have to create in zone "toto.be" the following NS record:
> > >
> > > titi.toto.be. TTL IN NS ns1.xxx.be
> > >
> > >
> > > I have found cases where this situation is present and other when it
> is not
> > > present...and both cases seems to work.
> > > What is the difference?
> >
> > The glue records aren't necessary when both the zone and subzone are on
> the
> > same server, although it is good to have them for completeness. When the
> > zones are on different servers you need the glue records.
> >
> >
> >
> > --
> > Daniel J McDonald, CCIE # 2495, CISSP # 78281
> >
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re:

[Bill Owens]

On Tue, Mar 13, 2012 at 01:42:00PM +, hugo hugoo wrote:
> 
> Thanks for the feedback.
> Is this a glue record? I do not have any IP defined in the NS record.

No, a glue record is an address record (A or ) for an NS record in the 
parent zone, to avoid the problem of having the child zone needed to resolve 
the nameservers that would serve the child zone. For example, if your child 
zone is 'titi.toto.be' and the nameservers are 'ns.titi.toto.be' and 
'ns1.titi.toto.be', glue records in the parent are needed in order to allow a 
querier to follow the delegation.

> What is the flow of a request to a subzone?

Walking down the names from right to left, starting at the root, then 'be', 
then 'toto.be', and 'titi.toto.be' The easiest way to visualize it is to do a 
query with 'dig +trace'.

> Is the content of the zone checked before checking the subzone?

I'm not sure what you mean by 'checked'; it isn't verified in any way, but in 
the normal progression there would be a query for 'titi.toto.be' at the 
authoritative server for 'toto.be', which would return NS records; one of those 
nameservers would then be queried for records in 'titi.toto.be'.

Bill.
___
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: NS record outside of our name space

[King, Harold Clyde (Hal)]

Here's an example of my zone record:

$ORIGIN .
$TTL 1800   ; 30 minutes
Wordpress.example.com. IN SOA  hiddenmaster.example.com. 
ipmgr.example.com. (
2012020601 ; serial
10800  ; refresh (3 hours)
1800   ; retry (30 minutes)
604800 ; expire (1 week)
900; minimum (15 minutes)
)
$TTL 28800  ; 8 hours
NS  NS1.WORDPRESS.COM.
NS  NS2.WORDPRESS.COM.
NS  NS3.WORDPRESS.COM.
$ORIGIN wordpress.example.com.
$TTL 900; 15 minutes
www CNAME   wordpress.example.com.


--
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599

From: Hal King mailto:h...@utk.edu>>
Date: Tue, 13 Mar 2012 13:40:54 +
To: Bind Users mailto:bind-users@lists.isc.org>>
Subject: NS record outside of our name space

How can I make a record that will allow outside DNS to control a subdomain in 
our space.

We own example.com
We have a zone call wordpress.example.com
If I make an NS record in the zone nothing seems to happen?

ORIGIN wordpress.example.com
NS wordpress.outside.com

--
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599
___ Please visit 
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list 
bind-users mailing list 
bind-users@lists.isc.org 
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE:

[hugo hugoo]

Thanks for the feedback.
Is this a glue record? I do not have any IP defined in the NS record.
 
What is the flow of a request to a subzone?
Is the content of the zone checked before checking the subzone?

 

> Date: Tue, 13 Mar 2012 08:26:02 -0500
> Subject: Re: 
> From: dan.mcdon...@austinenergy.com
> To: hugo...@hotmail.com; bind-users@lists.isc.org
> 
> 
> 
> 
> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> 
> > ==> do I have to create in zone "toto.be" the following NS record:
> > 
> > titi.toto.be. TTL IN NS ns1.xxx.be
> > 
> > 
> > I have found cases where this situation is present and other when it is not
> > present...and both cases seems to work.
> > What is the difference?
> 
> The glue records aren't necessary when both the zone and subzone are on the
> same server, although it is good to have them for completeness. When the
> zones are on different servers you need the glue records.
> 
> 
> 
> -- 
> Daniel J McDonald, CCIE # 2495, CISSP # 78281
> 
  ___
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

NS record outside of our name space

[King, Harold Clyde (Hal)]

How can I make a record that will allow outside DNS to control a subdomain in 
our space.

We own example.com
We have a zone call wordpress.example.com
If I make an NS record in the zone nothing seems to happen?

ORIGIN wordpress.example.com
NS wordpress.outside.com

--
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Systems: Business Information Systems

The University of Tennessee
135D Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599
___
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 Amplification Attack Mitigation

[Fr34k]

Hello,

Did I miss any feedback on this, or perhaps there isn't any to offer (?)
Thank you.




>
> From: Fr34k 
>To: Bindlist  
>Sent: Friday, March 9, 2012 10:30 AM
>Subject: DNS Amplification Attack Mitigation
> 
>
>
>All,
>
>I am (we all are (?)) interested in techniques for mitigating DNS 
>amplification attacks for both recursive and authoritative BIND servers 
>(versions 9.x).
>
>
>Google found http://www.secureworks.com/research/threats/dns-amplification/ 
>and http://www.publicsafety.gc.ca/prg/em/ccirc/2009/av09-011-eng.aspx
>which mention limiting clients via ACLs and using "additional-from-cache no;" 
>as mitigation techniques.
>
>
>Good articles, but written several years ago so there might be additional 
>configuration suggestions from the community since 2009.
>Are there and, if so, what are they?
>Perhaps said another way, what other named.conf settings could we be looking 
>at in this effort?
>
>
>Thank you.
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
>from this list
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>
>___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: NS records

[Bill Owens]

On Tue, Mar 13, 2012 at 08:26:02AM -0500, Daniel McDonald wrote:
> 
> On 3/13/12 8:20 AM, "hugo hugoo"  wrote:
> 
> > ==> do I have to create in zone "toto.be" the following NS record:
> >  
> >  titi.toto.be.   TTL   IN   NSns1.xxx.be
> >  
> >  
> > I have found cases where this situation is present and other when it is not
> > present...and both cases seems to work.
> > What is the difference?
> 
> The glue records aren't necessary when both the zone and subzone are on the
> same server, although it is good to have them for completeness.  When the
> zones are on different servers you need the glue records.

That's true, and it also becomes a problem when you want to sign the zones with
DNSSEC; if there's no NS record in the parent, there can't be a chain of trust
from the parent to the child. Assuming that you'll someday want to sign
toto.be, you should put the parent NS records in place now. 

Bill.
___
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:

[Daniel McDonald]

On 3/13/12 8:20 AM, "hugo hugoo"  wrote:

> ==> do I have to create in zone "toto.be" the following NS record:
>  
>  titi.toto.be.   TTL   IN   NSns1.xxx.be
>  
>  
> I have found cases where this situation is present and other when it is not
> present...and both cases seems to work.
> What is the difference?

The glue records aren't necessary when both the zone and subzone are on the
same server, although it is good to have them for completeness.  When the
zones are on different servers you need the glue records.



-- 
Daniel J McDonald, CCIE # 2495, CISSP # 78281

___
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

with subject: NS record for subzone definition

[hugo hugoo]

Dear all,
 
I have a problem in the understanding of the creation of a subzone.
Here the situation; let's call the name server ns1.xxx.be
 
 
I have zone "toto.be" with some records (not important)
 
In the same name server, I want to create the subzone "titi.toto.be" with some 
records.
 
 
==> do I have to create in zone "toto.be" the following NS record:
 
 titi.toto.be.   TTL   IN   NSns1.xxx.be
 
 
I have found cases where this situation is present and other when it is not 
present...and both cases seems to work.
What is the difference?
   
 
thanks for any feedback,
 
Hugo,. 
  ___
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

[no subject]

[hugo hugoo]

Dear all,
 
I have a problem in the understanding of the creation of a subzone.
Here the situation; let's call the name server ns1.xxx.be
 
 
I have zone "toto.be" with some records (not important)
 
In the same name server, I want to create the subzone "titi.toto.be" with some 
records.
 
 
==> do I have to create in zone "toto.be" the following NS record:
 
 titi.toto.be.   TTL   IN   NSns1.xxx.be
 
 
I have found cases where this situation is present and other when it is not 
present...and both cases seems to work.
What is the difference?
   
 
thanks for any feedback,
 
Hugo,.___
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: Recursive queries fail after bind has been running for a few hours

[G.W. Haywood]

B0;261;0cHi there,

On Mon, Mar 12, 2012 at 12:05 PM, Mr X  wrote:


I'm having a bizarre issue with 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.2 -
recursive queries stop functioning after bind has been running for a few
hours. It's a very low volume system (dev), maybe a few queries per hour
...


I saw something very similar with versions of 9.7 and I believe 9.8.

I was never able to pin it down, and never collected any evidence that
it was BIND itself that was the problem, but I did have to restart it
on several occasions when recursive queries suddenly started to fail.

Your suspicions are similar to mine although your setup appears not to
be.  I was using self-compiled binaries on a Debian system, but I do
run DNSSEC.  Now that I'm runnning 9.9 the problem seems to have gone.

Try upgrading?

Is your server also authoritative?

--

73,
Ged.
___
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 requests error sending response: host unreachable

[lst_hoe02]

Zitat von Romgo :


I see, but It should be statefull right ?



If using stateful UPD filtering you might get hit by short timeout  
values for UDP state matching, so packets get dropped if the query is  
too slow.


Regards

Andreas


___
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 requests error sending response: host unreachable

[Romgo]

I see, but It should be statefull right ?


On 12 March 2012 23:57, Mark Andrews  wrote:

>
> In message <
> caaoqnkg-xfkws_fen9kedub7w19vf4jocsfp52lb8ixv5+g...@mail.gmail.com>
> , Romgo writes:
> >
> > Here is my Iptables configuration for bind :
> >
> > # prod.dns.in
> > $IPTABLES -t filter -A INPUT -j LOGACCEPT -p udp --dport 53 -i eth1-d
> > 192.168.201.2 -s 0/0
> > $IPTABLES -t filter -A INPUT -j LOGACCEPT -p tcp --dport 53 -i eth1 -d
> > 192.168.201.2 -s 0/0
> >
> >
> > # OUTPUT
> > #-
> > # prod.dns.out
> > $IPTABLES -t filter -A OUTPUT -j LOGACCEPT -p tcp --dport 53 -o eth1 -s
> > 192.168.201.2 -d 0/0
> > $IPTABLES -t filter -A OUTPUT -j LOGACCEPT -p udp --dport 53 -o eth1 -s
> > 192.168.201.2 -d 0/0
>
> This is obviously wrong.  You want to be looking at the source port not
> the destination port for reply traffic.
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
>
___
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