Re: Monitoring Zonefiletransfer

2014-02-25 Thread Markus Weber 

Hey guys,

sorry for the delay, i urgently had to take some days off last week.
Anyways, thanks for all your help, i appreciate this a lot.

I will now try to use only one DC as a master.
a last question, Do you also run monitoring software on bind? and if so,  
what or how do you monitor?




Am 19.02.2014, 20:33 Uhr, schrieb Barry S. Finkel :


On 2014-02-19 16:06, Barry S. Finkel wrote:


>See MS KB article 282826, where MS documents the handling of zone
>serial numbers in an AD environment.


And Dave Warren replied:


My experience is that it tends to work pretty well if BIND only points
to one particular MS DNS server at a time, with a failover script that
detects when that DNS server goes down and flips to another master (if
you're worried about such things)

That being said, even without that script and with multiple MS DNS
masters configured in BIND at once, any issues generally work themselves
out within 15 minutes or so, once the Active Directory serial number
update propagates through the MS DNS infrastructure. As described in the
article, the servers self-increment properly when a slave is detected,
and occasionally sync up the serial numbers between MS DNS servers
(again, only moving update).

The only inconsistencies are in those recently added/modified records,
so if you just plan for 15 minute update times for non-MS secondaries to
sync up and ignore the periodic "serial is lower than expected"
warnings, multi-mastering works fine in practice.

-- Dave Warren



That MS KB article states that if a Domain Controller DNS Server is
not used as a master for a slave server, then the zone serial number
is irrelevant.  But if the Server is used as a master, then the serial
number is relevant.  Assume one zone that is "mastered" on two DCs, and
the two serial numbers match (and the serial is N).  A dynamic update
for the zone is sent to DC1, and the serial number there is increased to
N+1.  At the same time a different dynamic update for the zone is sent
to DC2, and DC2 then has serial number N+1.  The two copies of the zone
are different, but they both have the same serial number.  When Active
Directory synchronizes the zone, what serial number can it use for the
synched zone?  It can't use N+1, because that serial has been used, and
the zone might have already been transferred to the slave server.
It can't be N+2, because, in the meantime, another dynamic update may
have come to DC1 or DC2, so serial N+2 might have already been used.

Another thing that I hinted in an earlier reply - With AD zones, the
serial number can increase unnecessarily.   In the past, when a
dynamic DNS update was sent to a DC, and that update was already in DNS
(e.g., a re-lease of a DHCP address), the Windows DNS Server code
treated the update as a no-op, except for updating an internal timestamp
in the zone.  But sometime later, MS changed the code, so that the
dynamic DNS update is no longer treated as a no-op.  This causes

1) the DNS update to be initially refused because it does not have
TSIG authorization, and the client (or DHCP Server) has to re-send
the update.

2) the zone serial number is updated, even when there is no update to
the zone; this causes unnecessary zone transfers.

--Barry Finkel
___
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: how to hidden the salve

2014-02-25 Thread houguanghua 
Sorry.  My description isn't very clear.
 
The local dns server isn't a stealth slave. I need a stealth slave and the 
local dns server can query it when all public NSs are out of service.
 
Thanks!
Guanghua 
 

> Date: Mon, 24 Feb 2014 13:41:03 -0500
> From: Kevin Darcy 
> To: bind-users@lists.isc.org
> Subject: Re: how to hidden the salve
> Message-ID: <530b923f.8070...@chrysler.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> 
> I guess I'm still not understanding your requirements. In my thinking, 
> the local DNS server would *be* a stealth slave. Why are you considering 
> these as 2 separate instances?
> 
>  - Kevin
> 
> On 2/24/2014 9:56 AM, houguanghua wrote:
> > Dan,
> >
> > Yes, also-notify can hide the slave name server.  But local dns server 
> > can't know where is 'stealth' slave too.
> >
> > Thanks,
> > Guanghua
> >
> > 
> > Date: Fri, 21 Feb 2014 07:50:05 -0600
> > From: Daniel McDonald 
> > To: Untitled 
> > Subject: Re: bind-users Digest, Vol 1769, Issue 1
> > Message-ID: 
> > Content-Type: text/plain; charset="US-ASCII"
> >
> > On 2/21/14 3:39 AM, "houguanghua"  wrote:
> >
> > > kevin,
> > >
> > > How does the local name server learn where is the 'stealth' slave? 
> > For the
> > > 'stealth' slave isn't in the NS records.
> >
> > Also-notify directive. Either in an options stanza or a zone stanza.
> >
> > >
> > > thanks,
> > > Guanghua
> >
> > -- 
> > Daniel J McDonald, CISSP # 78281
> >
> >
> >
> > > Date: Thu, 20 Feb 2014 10:48:36 -0500
> > > From: Kevin Darcy 
> > > To: bind-users@lists.isc.org
> > > Subject: Re: how to hidden the salve
> > > Message-ID: <530623d4.3000...@chrysler.com>
> > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> > >
> > > A "stealth" slave has a full copy of the zone, is not published in the
> > > NS records, and can resolve names in the latest copy of the zone 
> > that it
> > > transferred, even if all of the published NSes are down due to a DDoS
> > > attack.
> > >
> > > So, does that not meet the requirements?
> > >
> > > - Kevin
> > >
> > > On 2/20/2014 1:28 AM, houguanghua wrote:
> > > > "Stealth" slave doesn't fully meet the requirement. It's just part of
> > > > the requirement to not publish the slave name server in the NS
> > > > records. Further more, the 'stealth' slave is quired by local DNS
> > > > server only when all name servers in the NS records are out of 
> > service
> > > > ( maybe in case of ddos attack).
> > > > Guanghua
> > > > --
> > > > On 2/19/2014 11:54 AM, Kevin wrote:
> > > > Date: Wed, 19 Feb 2014 11:54:44 -0500
> > > > From: Kevin Darcy 
> > > > To: bind-users@lists.isc.org
> > > > Subject: Re: how to modify the cache
> > > > Message-ID: 5304e1d4.5000...@chrysler.com
> > > > 
> > > >
> > > > Not a good solution. Even under "normal" circumstances, there will be
> > > > temporary bottlenecks, dropped packets, etc.. that will trigger 
> > failover
> > > > and users will get different answers at different times. Not good for
> > > > support, maintainability, user experience/satisfaction, etc.
> > > >
> > > > If all you want is resilience, and you own/control the domain in
> > > > question, why not just slave it ("stealth" slave, i.e. you don't 
> > need to
> > > > publish it in the NS records)?
> > > >
> > > > If you *don't* own/control the domain in question, what business 
> > do you
> > > > have standing up a "fake" version of it in your own 
> > infrastructure? Not
> > > > a best practice.
> > > >
> > > > - Kevin
> > > >
> > > > On 2/19/2014 4:51 AM, houguanghua wrote:
> > > > > Steven,
> > > > >
> > > > > Your solution is very good. It can forward the queries to
> > > > > the specified name servers first.
> > > > >
> > > > > But if the specified name server is enabled only when normal dns 
> > query
> > > > > process is down. How to configure the local DNS server? The detailed
> > > > > scenario is descibed in below figure:
> > > > >
> > > > >
> > > >
> > > > --
> > > > | Root |
> > > > | nameServer |
> > > > / -
> > > > (2)/
> > > > /
> > > > -- --- -
> > > > | Client | __(1)\ | Local | ___(3)_\ |
> > > > Authority |
> > > > | Resolver | / | DNS Server | X / | DNS
> > > > Server |
> > > > --  -
> > > > \
> > > > \(4)
> > > > \
> > > > \ 
> > > > | Hidden |
> > > > | DNS Server |
> > > > 
> > > >
> > > > > Normally,
> > > > > 1) A internet user wants to access www.abc.com  > > > >,
> > > > > a DNS request is sent to local DNS server
> > > > > 2) Local DNS server queries the root name server, the .com name
> > > > > server to get the Authority Name Server of abc.com
> > > > > 3) local DNS server queries the Authority name server, and gets 
> > the IP
> > > > >
> > > > >

Re: how to hidden the salve

2014-02-25 Thread Kevin Darcy 
If you have zone-transfer permission, make a stealth slave. That, plus a 
static-stub definition on your "local" server, and you're set.


Or, to simplify things even further, make the "local" server the stealth 
slave (this makes some assumptions about your connectivity to the 
authoritative nameservers for the zone).


- Kevin

On 2/25/2014 9:49 AM, houguanghua wrote:

Sorry.  My description isn't very clear.

The local dns server isn't a stealth slave. I need a stealth slave and 
the local dns server can query it when all public NSs are out of service.


Thanks!
Guanghua


> Date: Mon, 24 Feb 2014 13:41:03 -0500
> From: Kevin Darcy 
> To: bind-users@lists.isc.org
> Subject: Re: how to hidden the salve
> Message-ID: <530b923f.8070...@chrysler.com>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> I guess I'm still not understanding your requirements. In my thinking,
> the local DNS server would *be* a stealth slave. Why are you 
considering

> these as 2 separate instances?
>
> - Kevin
>
> On 2/24/2014 9:56 AM, houguanghua wrote:
> > Dan,
> >
> > Yes, also-notify can hide the slave name server. But local dns server
> > can't know where is 'stealth' slave too.
> >
> > Thanks,
> > Guanghua
> >
> > 
> > Date: Fri, 21 Feb 2014 07:50:05 -0600
> > From: Daniel McDonald 
> > To: Untitled 
> > Subject: Re: bind-users Digest, Vol 1769, Issue 1
> > Message-ID: 
> > Content-Type: text/plain; charset="US-ASCII"
> >
> > On 2/21/14 3:39 AM, "houguanghua"  wrote:
> >
> > > kevin,
> > >
> > > How does the local name server learn where is the 'stealth' slave?
> > For the
> > > 'stealth' slave isn't in the NS records.
> >
> > Also-notify directive. Either in an options stanza or a zone stanza.
> >
> > >
> > > thanks,
> > > Guanghua
> >
> > --
> > Daniel J McDonald, CISSP # 78281
> >
> >
> >
> > > Date: Thu, 20 Feb 2014 10:48:36 -0500
> > > From: Kevin Darcy 
> > > To: bind-users@lists.isc.org
> > > Subject: Re: how to hidden the salve
> > > Message-ID: <530623d4.3000...@chrysler.com>
> > > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> > >
> > > A "stealth" slave has a full copy of the zone, is not published 
in the

> > > NS records, and can resolve names in the latest copy of the zone
> > that it
> > > transferred, even if all of the published NSes are down due to a 
DDoS

> > > attack.
> > >
> > > So, does that not meet the requirements?
> > >
> > > - Kevin
> > >
> > > On 2/20/2014 1:28 AM, houguanghua wrote:
> > > > "Stealth" slave doesn't fully meet the requirement. It's just 
part of

> > > > the requirement to not publish the slave name server in the NS
> > > > records. Further more, the 'stealth' slave is quired by local DNS
> > > > server only when all name servers in the NS records are out of
> > service
> > > > ( maybe in case of ddos attack).
> > > > Guanghua
> > > > --
> > > > On 2/19/2014 11:54 AM, Kevin wrote:
> > > > Date: Wed, 19 Feb 2014 11:54:44 -0500
> > > > From: Kevin Darcy 
> > > > To: bind-users@lists.isc.org
> > > > Subject: Re: how to modify the cache
> > > > Message-ID: 5304e1d4.5000...@chrysler.com
> > > > 
> > > >
> > > > Not a good solution. Even under "normal" circumstances, there 
will be

> > > > temporary bottlenecks, dropped packets, etc.. that will trigger
> > failover
> > > > and users will get different answers at different times. Not 
good for

> > > > support, maintainability, user experience/satisfaction, etc.
> > > >
> > > > If all you want is resilience, and you own/control the domain in
> > > > question, why not just slave it ("stealth" slave, i.e. you don't
> > need to
> > > > publish it in the NS records)?
> > > >
> > > > If you *don't* own/control the domain in question, what business
> > do you
> > > > have standing up a "fake" version of it in your own
> > infrastructure? Not
> > > > a best practice.
> > > >
> > > > - Kevin
> > > >
> > > > On 2/19/2014 4:51 AM, houguanghua wrote:
> > > > > Steven,
> > > > >
> > > > > Your solution is very good. It can forward the queries to
> > > > > the specified name servers first.
> > > > >
> > > > > But if the specified name server is enabled only when normal 
dns

> > query
> > > > > process is down. How to configure the local DNS server? The 
detailed

> > > > > scenario is descibed in below figure:
> > > > >
> > > > >
> > > >
> > > > --
> > > > | Root |
> > > > | nameServer |
> > > > / -
> > > > (2)/
> > > > /
> > > > -- --- -
> > > > | Client | __(1)\ | Local | ___(3)_\ |
> > > > Authority |
> > > > | Resolver | / | DNS Server | X / | DNS
> > > > Server |
> > > > --  -
> > > > \
> > > > \(4)
> > > > \
> > > > \ 
> > > > | Hidden |
> > > > | DNS Server |
> > > > 
> > > >
> > > > > Normally,
> > > > > 1) A internet user wants to access www.abc.com

Re: Monitoring Zonefiletransfer

2014-02-25 Thread Lawrence K. Chen, P.Eng. 
Hmmm, so that explains what I'm seeing in my logs of my nameservers
getting hammered by AD.

Should I be worried?  Is there anything that could be done on my end to
help reduce the impact?



On our campus, we have always allowed delegation of subdomains to
department nameservers, with the requirement that we be secondary to
them.  Some departments also have other domains on their nameservers,
again have us as their secondary (and often we're the only published
nameservers for these domains.)

But, AD was different...they did their own thing.

Except there's this problem now with their authoritative servers also
being open recursive query resolvers ... exposed to the whole world.

Since they won't turn off recursion (and there's no way to limit its scope)

So, we've started pushing that they need to use us as secondaries.

Right now it has only been tested with Central AD, where I'm seeing one
DC sending updates ranging from a few minutes to a few hours.  While the
other DC is trying at intervals of 2-9 minutes, but its N-1

Though when they were first trying to get it going...they had some
trouble, which turned out that it thought the IP space of my nameservers
belonged to it and that my nameservers were not part that space.

Namely, one of my DNS vlans is 129.130.254.0/28 (ns-1.ksu.edu lives
here, ns-2.ksu.edu/ns-3.ksu.edu live in the other one)...where some
other portion of the /24 is a vlan that they have servers in.

Hmmm, I noticed in the dump of ads.ksu.edu, it has A records for my
nameserversis that a problem?

On 02/25/14 03:10, Markus Weber wrote:
> Hey guys,
> 
> sorry for the delay, i urgently had to take some days off last week.
> Anyways, thanks for all your help, i appreciate this a lot.
> 
> I will now try to use only one DC as a master.
> a last question, Do you also run monitoring software on bind? and if so,
> what or how do you monitor?
> 
> 
> 
> Am 19.02.2014, 20:33 Uhr, schrieb Barry S. Finkel :
> 
>>> On 2014-02-19 16:06, Barry S. Finkel wrote:
>>>
 >See MS KB article 282826, where MS documents the handling of zone
 >serial numbers in an AD environment.
>>
>> And Dave Warren replied:
>>
>>> My experience is that it tends to work pretty well if BIND only points
>>> to one particular MS DNS server at a time, with a failover script that
>>> detects when that DNS server goes down and flips to another master (if
>>> you're worried about such things)
>>>
>>> That being said, even without that script and with multiple MS DNS
>>> masters configured in BIND at once, any issues generally work themselves
>>> out within 15 minutes or so, once the Active Directory serial number
>>> update propagates through the MS DNS infrastructure. As described in the
>>> article, the servers self-increment properly when a slave is detected,
>>> and occasionally sync up the serial numbers between MS DNS servers
>>> (again, only moving update).
>>>
>>> The only inconsistencies are in those recently added/modified records,
>>> so if you just plan for 15 minute update times for non-MS secondaries to
>>> sync up and ignore the periodic "serial is lower than expected"
>>> warnings, multi-mastering works fine in practice.
>>>
>>> -- Dave Warren
>>
>>
>> That MS KB article states that if a Domain Controller DNS Server is
>> not used as a master for a slave server, then the zone serial number
>> is irrelevant.  But if the Server is used as a master, then the serial
>> number is relevant.  Assume one zone that is "mastered" on two DCs, and
>> the two serial numbers match (and the serial is N).  A dynamic update
>> for the zone is sent to DC1, and the serial number there is increased to
>> N+1.  At the same time a different dynamic update for the zone is sent
>> to DC2, and DC2 then has serial number N+1.  The two copies of the zone
>> are different, but they both have the same serial number.  When Active
>> Directory synchronizes the zone, what serial number can it use for the
>> synched zone?  It can't use N+1, because that serial has been used, and
>> the zone might have already been transferred to the slave server.
>> It can't be N+2, because, in the meantime, another dynamic update may
>> have come to DC1 or DC2, so serial N+2 might have already been used.
>>
>> Another thing that I hinted in an earlier reply - With AD zones, the
>> serial number can increase unnecessarily.   In the past, when a
>> dynamic DNS update was sent to a DC, and that update was already in DNS
>> (e.g., a re-lease of a DHCP address), the Windows DNS Server code
>> treated the update as a no-op, except for updating an internal timestamp
>> in the zone.  But sometime later, MS changed the code, so that the
>> dynamic DNS update is no longer treated as a no-op.  This causes
>>
>> 1) the DNS update to be initially refused because it does not have
>> TSIG authorization, and the client (or DHCP Server) has to re-send
>> the update.
>>
>> 2) the zone serial number is updated, even when there is no update to
>> the

BIND 9.10.0b1 has been released.

2014-02-25 Thread Michael McNally 
BIND 9.10.0b1 has been released and is now available from:

  http://www.isc.org/downloads

At ISC we are quite excited about the long list of new
features and feature improvements in this major release
and we hope that you'll share our enthusiasm.

We'd particularly like to hear from DNS operators who have
a chance to try the new software while it is in beta and
provide feedback on the new features and utilities that
have been added.  If you have an interest in helping us to
improve BIND, please consider joining the bind-beta-response
list and sharing your experience with the development release.

  https://lists.isc.org/mailman/listinfo/bind-beta-response
___
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 +sigchase looping

2014-02-25 Thread Evan Hunt 
On Tue, Feb 25, 2014 at 08:57:08AM +1100, Mark Andrews wrote:
> SIGCHASE is a external contribution that is provide "as is" to dig.
> The reason that you have to explicitly define it is that ISC hasn't
> fully gone through the code to find bugs like this in it and it
> basically needs a full re-write.  That said it does mostly work and
> is better than nothing.

...but it might not be better than the new "delve" tool (backronym:
"domain entity lookup and validation engine"), which shipped today in
BIND 9.10.0b1.

Delve has command line semantics similar to dig, but uses the same
resolver and validator logic that named does, to perform a DNS lookup
and validate it.  The +vtrace option turns on valiator logging, +rtrace
reports each record fetched, and +mtrace prints all messages exchanged
with the name server in full.

It does *not* (or anyway not yet) do full iterative resolution from the
root, but it will send all the needed queries to the local name server
to resolve and validate a name, including following CNAMEs and fetching
DNSKEY and DS records to establish a chain of trust.

My hope is that people will find they don't need dig +sigchase anymore,
and we can deprecate it in a future release. If you have a use case for
dig +sigchase that delve doesn't accomodate, please let me know so I
can try to address it.

Examples:

  Valid signed response:

$ delve  isc.org
; fully validated
isc.org.60  IN  2001:4f8:0:2::69
isc.org.60  IN  RRSIG    5 2 60 20140326233255
20140224233255 4521 isc.org.
DP8IFXWtADmptzScrFj+Pt425PX/cfpGiNnzjIZtoMfI5ueq1sFfV0UX
PwGPD1PGbrUj/s/w9uh7XgfNpFr8xZujb4JwN+1xOeWcA+58oRIlTjoV
OqVdLa9i/eMyl8sj0wMfy76Olasa1RfbzJJmY1Sp90uImfNrzd136hw0 Hac=
isc.org.60  IN  RRSIG    5 2 60 20140326233255
20140224233255 50012 isc.org.
ibMtXAh67O7kbq3+bTkJt/sO8q1rmQBfRgvSLK0Dx8GcryfIBS6VshFn
qirzgRVmenlITdf9KFWA2qPT6Tfh+4XQFFfwxiNhs5Pi1XlK0oft1LVc
shyHJdMAa+Ap2VGg61Sch3ckUjUXjNqIf4IhRGXrRRsU/dalkBJk4YCk Thk=

  Legitimate unsigned repsonse:

$ delve unsigned.com
; unsigned answer
unsigned.com.   87600   IN  A   204.14.120.250

  Valid NXDOMAIN from a signed zone:

$ delve nonexistent.example.org
;; resolution failed: ncache nxdomain
; negative response, fully validated
; nonexistent.example.org. 3600 IN  \-ANY   ;-$NXDOMAIN
; example.org. SOA sns.dns.icann.org. noc.dns.icann.org. 2013103114 7200
3600 1209600 3600
; example.org. RRSIG SOA ...
; example.org. RRSIG NSEC ...
; example.org. NSEC www.example.org. A NS SOA TXT  RRSIG NSEC DNSKEY

  Invalid response:

$ delve www.dnssec-failed.org
;; validating dnssec-failed.org/DNSKEY: no valid signature found (DS)
;; no valid RRSIG resolving 'dnssec-failed.org/DNSKEY/IN': 127.0.1.1#53
;; broken trust chain resolving 'www.dnssec-failed.org/A/IN': 127.0.1.1#53
;; resolution failed: broken trust chain

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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