Re: ISC BIND 9.7.0b1 is now available

[Stephane Bortzmeyer]

On Thu, Oct 29, 2009 at 09:24:48AM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 25 lines which said:

> > - Support for RFC 5011 automated trust anchor maintenance (see
> >   README.rfc5011 for additional details).

Hmmm, it suddenly had a problem:

02-Nov-2009 10:59:14.945 zone managed-keys.bind/IN/_meta: loaded serial 156
...
02-Nov-2009 11:26:35.154 malformed transaction: managed-keys.bind.jnl last 
serial 157 != transaction first serial 156
02-Nov-2009 11:26:35.154 zone managed-keys.bind/IN/_meta: 
keyfetch_done:dns_journal_write_transaction -> unexpected error
...
02-Nov-2009 11:27:04.198 malformed transaction: managed-keys.bind.jnl last 
serial 158 != transaction first serial 157
02-Nov-2009 11:27:04.198 zone managed-keys.bind/IN/_meta: 
keyfetch_done:dns_journal_write_transaction -> unexpected error

Is it serious? The file managed-keys.bind looks normal.

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

Re: Slave to Win2003 DNS

[Matus UHLAR - fantomas]

>> On 31.10.09 12:07, Jukka Pakkanen wrote:
>>> For some reason the slaves don't update the zone unless I restart the 
>>>  BIND service in the server, and after a while, fail to respond to  
>>> queries.

> Matus UHLAR - fantomas kirjoitti:
>> Is the master updating SOA serial?

On 01.11.09 16:59, Jukka Pakkanen wrote:
> It is. And "notify name servers " is  chosen.
>
> Our slave servers are ns1.qnet.fi, ns2.qnet.fi and ns3.qnet.fi.  And the  
> master win2003 server is xeon.merinova.fi.  The zone is merinova.local  
> and example host xeonx.merinova.local.
>
> At the moment ns3 is not responding to queries to merinova.local.
>
> Also just made few updates to the zone, the serial in the master is 6240  
> but the responding slaves ns1 and ns2 still report 6239.

there should be something in logs of your BIND servers in such case...
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 9.6.1-P1 zone parser false errors

[Sam Wilson]

In article ,
 Chris Buxton  wrote:

> As I recall, named-checkzone calls out to the operating system stub  
> resolver to look up these names. Is there any way the stub resolver  
> could be getting different data? Is there anything in the stub  
> resolver config (/etc/{hosts,resolv.conf}) that might explain this?  
> What do you get if you use 'host' to look up one of these mailhost  
> names?

And if you're using a system with an nsswitch.conf file or equivalent, 
what does that say?

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

Re: Slave to Win2003 DNS

[Jukka Pakkanen]

Matus UHLAR - fantomas kirjoitti:

On 31.10.09 12:07, Jukka Pakkanen wrote:
  
For some reason the slaves don't update the zone unless I restart the 
 BIND service in the server, and after a while, fail to respond to  
queries.



  

Matus UHLAR - fantomas kirjoitti:


Is the master updating SOA serial?
  


On 01.11.09 16:59, Jukka Pakkanen wrote:
  

It is. And "notify name servers " is  chosen.

Our slave servers are ns1.qnet.fi, ns2.qnet.fi and ns3.qnet.fi.  And the  
master win2003 server is xeon.merinova.fi.  The zone is merinova.local  
and example host xeonx.merinova.local.


At the moment ns3 is not responding to queries to merinova.local.

Also just made few updates to the zone, the serial in the master is 6240  
but the responding slaves ns1 and ns2 still report 6239.



there should be something in logs of your BIND servers in such case...
  


Actually the ns1 & ns2 had updated the serial when I checked now, ns3 
still "servfail".  Restarted the BIND service and immediately the zone 
is online again in that server as well...



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

multiple internal views not working

[Paul Krash]

Morning!

I have been struggling with getting two internal views to work on three 
BIND servers running on Ubuntu Linux 8.04.2 x64

( kernel 2.6.24-23-server ) for two straight working days
(OK, I have other projects too. :-)

Scope: present different CNAMES and A records to one subnet 
(10.x.D.0/24) and another for all remaining (10.x.0.0/16)


This will allow my .5 subnet to automount NFS via UDP
without jiggering the network infrastructure (routers and switches).
NFS and NIS servers are homed on multiple networks
(.A.x/24, .B.x/24, .D.x/24)

Any suggestions or help would be greatly appreciated (virtual beer and 
libations are on the way) in finding a working config example.


I have read the ARMs, searched Google and communities, no joy.

I apologize in advance if there is a well known fount of this knowledge,
you know how it is, being a sys/sec/net admin at a dynamically changing 
technology company :-)


Best,

Paul Krash
Sys/Sec/Net Administrator
Exegy, Inc.
pkr...@exegy.com

This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slave to Win2003 DNS

[bsfinkel]

Jukka Pakkanen  wrote:

>Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS 
>server, zone "company.local".
>
>For some reason t he slaves don't update the zone unless I restart the 
>BIND service in the server, and after a while, fail to respond to queries.
>
>Example, after a couple of days since the last restart, the BIND servers 
>stops responding to queries to "company.local" (SERVFAIL), at the server 
>I can see that the cache file is not updated since the service was 
>previously started.  I restart BIND service, and immediately the cache 
>file is updated, server again responses to queries etc.
>
>I suspect this is not a problem in the BIND, but in the Windows 2003 
>DNS, but any ideas anyway, what to look in the server?  Haven't been 
>playing with the Windows DNS a lot...

I have seen the three replies to this, and I will add the following:

Is the W2003 DNS Server sending NOTIFY packets to the BIND slaves
when a zone is updated?  One of the problems with the Windows DNS
Server is that it logs only successful zone transfers.  Unsuccessful
zone transfers are not logged because the MS Developers did not want
to fill the EventLog with these entries.  A number of years ago, when
we installed AD and put the AD zones on a MS W2000 DNS Server, we
formally requested that MS log unsuccessful zone transfers along with
some information as to why the transfer was rejected.

Do you have DNS logging enabled on the MS DNS Server?  I suggest that
full logging be enabled, and the dns.log file be made sufficiently
large so that you will be able to see what may be happening.  Note
that the dns.log file increases in size until it reaches its max
size; then it is cleared, and new entries are added.  The dns.log
file is NOT a syslog file, as we in the Unix community are used to
using.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory  Phone:+1 (630) 252-7277
9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL   60439-4828 IBMMAIL:  I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

One A record fails on one server on Sunday evening

[Josh Luthman]

I have two servers that users query that as as cache servers.

The server having the problem is CentOS 4.4 running bind 9.2.4

The second server configured similarly is CentOS 3.9 also running bind
9.2.4.

There is one A record on Godaddy's DNS servers that fails look ups on the
4.4 server start around 7PM EST Sunday.  I have been able to solve this each
Monday morning by issuing the commands (rndc reload && /etc/init.d/named
restart).

I have not had to do this on the second 3.9 server.

I am looking for any suggestions or ideas to help fix this issue.  Thanks in
advance!

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

"When you have eliminated the impossible, that which remains, however
improbable, must be the truth."
--- Sir Arthur Conan Doyle
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple internal views not working

[Jeremy C. Reed]

It may be useful for you to show us what you tried (configurations and 
that it is restarted), how you tested, and any network traces and log 
files showing that it is not working.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Josh Luthman]

The issue is that the A record no longer gets resolved.

The command dig mail.alexandertelecominc.com @firstserver times out.  Not
sure what else I can provide that would help.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

"When you have eliminated the impossible, that which remains, however
improbable, must be the truth."
--- Sir Arthur Conan Doyle


On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed  wrote:

> > I am looking for any suggestions or ideas to help fix this issue.  Thanks
> in
> > advance!
>
> To get good help, you may want to tell us what the issue is. Provide
> real names and show your real tests. Also the version of BIND you are
> using is out of date and is no longer supported.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Feature request - disable internal recursion cache

[Dmitry Rybin]

Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries, 
that bind. :(

___
So, you don't cache locally, you forward to another daemon that (in the 
best case) answers from *its* cache.


How have you improved performance by changing nothing else and adding a 
network hop?


recursion possibilities of bind is very pity in compare with 
powerdns-recursor, unbound & so on. It allocate a lot of memory and make 
high CPU usage.


Sometimes unable change authoritative and recursive IPs.
The decision is:
Authoritative q: bind answer it
Recursive: pass from bind ACL and proxy all recursive queries to special 
recursion daemon.


It'll be very useful option.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Jeremy C. Reed]

> I am looking for any suggestions or ideas to help fix this issue.  Thanks in
> advance!

To get good help, you may want to tell us what the issue is. Provide 
real names and show your real tests. Also the version of BIND you are 
using is out of date and is no longer supported.___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slave to Win2003 DNS

[Jukka Pakkanen]

bsfin...@anl.gov kirjoitti:

Jukka Pakkanen  wrote:

  
Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS 
server, zone "company.local".


For some reason t he slaves don't update the zone unless I restart the 
BIND service in the server, and after a while, fail to respond to queries.


Example, after a couple of days since the last restart, the BIND servers 
stops responding to queries to "company.local" (SERVFAIL), at the server 
I can see that the cache file is not updated since the service was 
previously started.  I restart BIND service, and immediately the cache 
file is updated, server again responses to queries etc.


I suspect this is not a problem in the BIND, but in the Windows 2003 
DNS, but any ideas anyway, what to look in the server?  Haven't been 
playing with the Windows DNS a lot...



I have seen the three replies to this, and I will add the following:

Is the W2003 DNS Server sending NOTIFY packets to the BIND slaves
when a zone is updated?  
I suppose it is, because earlier today when I checked the serial number 
was updated in the master since the weekend, and the two working slaves 
had the updated serial as well. And when made a change to the zone, they 
updated the zone file in a short time as well.  Also if you check the 
servers right now, they are already at "6278", so looks like the notify 
& zone transfers work ok.


But for still unknown reason the slaves at some point stop responding 
queries to this zone (servfail) and won't recover until service restart. 
Maybe after the zone data is expired (24hrs), if not refreshed/updated 
before that??


These same servers are slaves to a bind master, and have no problems there.


Do you have DNS logging enabled on the MS DNS Server?  I suggest that
full logging be enabled, and the dns.log file be made sufficiently
large so that you will be able to see what may be happening.  Note
that the dns.log file increases in size until it reaches its max
size; then it is cleared, and new entries are added.  The dns.log
file is NOT a syslog file, as we in the Unix community are used to
using.
  

I'll check that and enable if not already.


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

Re: Feature request - disable internal recursion cache

[Dmitry Rybin]

Matus UHLAR - fantomas wrote:

Bind answer authoritative for all clients, and forward (if allowed)  
recursive queries to recursive server.


why shouldn't it cache those responses?


Bind cache is slow. It allocate a lot of memory and make high CPU usage.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Bill Larson]

Josh Luthman  said:

> --000e0cd32f54da30b8047764ddcc
> Content-Type: text/plain; charset=ISO-8859-1
> 
> The issue is that the A record no longer gets resolved.
> 
> The command dig mail.alexandertelecominc.com @firstserver times out.  Not
> sure what else I can provide that would help.

Well, when you are querying this "firstserver" (whatever that is - giving us 
a fully qualified domain name would be helpful), it times out.  The DNS 
server on this "firstserver" isn't answering the query.

"Not sure what else I can provide that would help".  You don't give us much 
to work with.

Bill Larson

> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> "When you have eliminated the impossible, that which remains, however
> improbable, must be the truth."
> --- Sir Arthur Conan Doyle
> 
> 
> On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed  wrote:
> 
> > > I am looking for any suggestions or ideas to help fix this issue.  
Thanks
> > in
> > > advance!
> >
> > To get good help, you may want to tell us what the issue is. Provide
> > real names and show your real tests. Also the version of BIND you are
> > using is out of date and is no longer supported.
> 
> --000e0cd32f54da30b8047764ddcc
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> The issue is that the A record no longer gets resolved.The command 
=
> dig http://mail.alexandertelecominc.com";>mail.alexandertelecomin=
> c.com @firstserver times out.=A0 Not sure what else I can provide that 
=
> would help.
> 
> Josh LuthmanOffice: 937-552-2340Direct: 937-552-23431100 
Wa=
> yne StSuite 1337Troy, OH 45373"When you have 
eliminate=
> d the impossible, that which remains, however improbable, must be the 
truth=
> ."
> 
> --- Sir Arthur Conan Doyle
> On Mon, Nov 2, 2009 at 10:13 AM, Jeremy 
=
> C. Reed jr...@isc.or=
> g> wrote: r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-
le=
> ft: 1ex;">
> 
> > I am looking for any suggestions or ideas to help 
fi=
> x this issue.=A0 Thanks in
> > advance!
> 
> To get good help, you may want to tell us what the issue is. 
Provide<=
> br>
> real names and show your real tests. Also the version of BIND you are
> using is out of date and is no longer supported.
> 
> --000e0cd32f54da30b8047764ddcc--
> 



-- 



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

Re: One A record fails on one server on Sunday evening

[Josh Luthman]

Let me say it this way...

Starting ~7PM EST Sunday evening the command

dig mail.alexandertelecominc.com @74.218.88.168 #fails
dig mail.alexandertelecominc.com @4.2.2.2 #works

until I issue

rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

"When you have eliminated the impossible, that which remains, however
improbable, must be the truth."
--- Sir Arthur Conan Doyle


On Mon, Nov 2, 2009 at 10:33 AM, Bill Larson  wrote:

> Josh Luthman  said:
>
> > --000e0cd32f54da30b8047764ddcc
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > The issue is that the A record no longer gets resolved.
> >
> > The command dig mail.alexandertelecominc.com @firstserver times out.
>  Not
> > sure what else I can provide that would help.
>
> Well, when you are querying this "firstserver" (whatever that is - giving
> us
> a fully qualified domain name would be helpful), it times out.  The DNS
> server on this "firstserver" isn't answering the query.
>
> "Not sure what else I can provide that would help".  You don't give us much
> to work with.
>
> Bill Larson
>
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > "When you have eliminated the impossible, that which remains, however
> > improbable, must be the truth."
> > --- Sir Arthur Conan Doyle
> >
> >
> > On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed  wrote:
> >
> > > > I am looking for any suggestions or ideas to help fix this issue.
> Thanks
> > > in
> > > > advance!
> > >
> > > To get good help, you may want to tell us what the issue is. Provide
> > > real names and show your real tests. Also the version of BIND you are
> > > using is out of date and is no longer supported.
> >
> > --000e0cd32f54da30b8047764ddcc
> > Content-Type: text/html; charset=ISO-8859-1
> > Content-Transfer-Encoding: quoted-printable
> >
> > The issue is that the A record no longer gets resolved.The
> command
> =
> > dig  href=3D"http://mail.alexandertelecominc.com";>mail.alexandertelecomin=
> > c.com @firstserver times out.=A0 Not sure what else I can provide
> that
> =
> > would help.
> >
> > Josh LuthmanOffice: 937-552-2340Direct: 937-552-23431100
> Wa=
> > yne StSuite 1337Troy, OH 45373"When you have
> eliminate=
> > d the impossible, that which remains, however improbable, must be the
> truth=
> > ."
> >
> > --- Sir Arthur Conan Doyle
> > On Mon, Nov 2, 2009 at 10:13 AM,
> Jeremy
> =
> > C. Reed < href=3D"mailto:jr...@isc.org";>jr...@isc.or=
> > g> wrote: style=3D"borde=
> > r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-
> le=
> > ft: 1ex;">
> >
> > > I am looking for any suggestions or ideas to help
> fi=
> > x this issue.=A0 Thanks in
> > > advance!
> > 
> > To get good help, you may want to tell us what the issue is.
> Provide<=
> > br>
> > real names and show your real tests. Also the version of BIND you are
> > using is out of date and is no longer supported.
> >
> > --000e0cd32f54da30b8047764ddcc--
> >
>
>
>
> --
>
>
>
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Jeremy C. Reed]

On Mon, 2 Nov 2009, Josh Luthman wrote:

> dig mail.alexandertelecominc.com @74.218.88.168 #fails

What does "fails" mean?

> dig mail.alexandertelecominc.com @4.2.2.2 #works
> 
> until I issue
> 
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server

Check named logs and look at named cache before you reload (next time).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Bill Larson]

Josh Luthman  said:

> Let me say it this way...
> 
> Starting ~7PM EST Sunday evening the command
> 
> dig mail.alexandertelecominc.com @74.218.88.168 #fails
> dig mail.alexandertelecominc.com @4.2.2.2 #works
> 
> until I issue
> 
> rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server

Ok, we're getting somewhere.  Do the logs on your 74.218.88.168 server tell 
you anything?  Is there anything unusual logged prior to ~7PM EST Sunday?

Again, without knowing more there is no way that we can identify exactly 
what occurred to cause the query to fail.  Also, even with all the 
information that is available, we may still not be able to identify the 
problem.

Then again, is this a one time situation or does it occur regularly?

> Josh Luthman
> Office: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> "When you have eliminated the impossible, that which remains, however
> improbable, must be the truth."
> --- Sir Arthur Conan Doyle

I don't know exactly why, but this statement struck me.  Sherlock Holmes 
should never have been susceptable to this logical falicy.  

The opposite of "the impossible" is "the possible", but no matter how 
improbable this "possible" may be, this is not the same as "truth".

A counter example, something occurs and there are three posited causes.  One 
cause is "impossible" and can be eliminated.  This leaves the other two 
possibilities, no matter how improbable.  This does NOT make both, or 
either, of these possibilities "the truth".

> On Mon, Nov 2, 2009 at 10:33 AM, Bill Larson  wrote:
> 
> > Josh Luthman  said:
> >
> > > --000e0cd32f54da30b8047764ddcc
> > > Content-Type: text/plain; charset=ISO-8859-1
> > >
> > > The issue is that the A record no longer gets resolved.
> > >
> > > The command dig mail.alexandertelecominc.com @firstserver times out.
> >  Not
> > > sure what else I can provide that would help.
> >
> > Well, when you are querying this "firstserver" (whatever that is - giving
> > us
> > a fully qualified domain name would be helpful), it times out.  The DNS
> > server on this "firstserver" isn't answering the query.
> >
> > "Not sure what else I can provide that would help".  You don't give us 
much
> > to work with.
> >
> > Bill Larson
> >
> > > Josh Luthman
> > > Office: 937-552-2340
> > > Direct: 937-552-2343
> > > 1100 Wayne St
> > > Suite 1337
> > > Troy, OH 45373
> > >
> > > "When you have eliminated the impossible, that which remains, however
> > > improbable, must be the truth."
> > > --- Sir Arthur Conan Doyle
> > >
> > >
> > > On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed  wrote:
> > >
> > > > > I am looking for any suggestions or ideas to help fix this issue.
> > Thanks
> > > > in
> > > > > advance!
> > > >
> > > > To get good help, you may want to tell us what the issue is. Provide
> > > > real names and show your real tests. Also the version of BIND you are
> > > > using is out of date and is no longer supported.
> > >
> > > --000e0cd32f54da30b8047764ddcc
> > > Content-Type: text/html; charset=ISO-8859-1
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > The issue is that the A record no longer gets resolved.The
> > command
> > =
> > > dig  > href=3D"http://mail.alexandertelecominc.com";>mail.alexandertelecomin=
> > > c.com @firstserver times out.=A0 Not sure what else I can provide
> > that
> > =
> > > would help.
> > >
> > > Josh LuthmanOffice: 937-552-2340Direct: 937-552-
23431100
> > Wa=
> > > yne StSuite 1337Troy, OH 45373"When you have
> > eliminate=
> > > d the impossible, that which remains, however improbable, must be the
> > truth=
> > > ."
> > >
> > > --- Sir Arthur Conan Doyle
> > > On Mon, Nov 2, 2009 at 10:13 AM,
> > Jeremy
> > =
> > > C. Reed < > href=3D"mailto:jr...@isc.org";>jr...@isc.or=
> > > g> wrote: > style=3D"borde=
> > > r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 
padding-
> > le=
> > > ft: 1ex;">
> > >
> > > > I am looking for any suggestions or ideas to 
help
> > fi=
> > > x this issue.=A0 Thanks in
> > > > advance!
> > > 
> > > To get good help, you may want to tell us what the issue is.
> > Provide<=
> > > br>
> > > real names and show your real tests. Also the version of BIND you 
are
> > > using is out of date and is no longer supported.
> > >
> > > --000e0cd32f54da30b8047764ddcc--
> > >
> >
> >
> >
> > --
> >
> >
> >
> >
> 



-- 



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

Re: multiple internal views not working

[Krash, Paul]

Agreed. Will do. As time permits today. Thank you for your help!
Paul Krash from mobile +01.314.283.4942

- Original Message -
From: Jeremy C. Reed 
To: Krash, Paul
Cc: bind-users@lists.isc.org 
Sent: Mon Nov 02 09:09:50 2009
Subject: Re: multiple internal views not working

It may be useful for you to show us what you tried (configurations and 
that it is restarted), how you tested, and any network traces and log 
files showing that it is not working.
 
This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: One A record fails on one server on Sunday evening

[Josh Luthman]

It has happened the last 4 or 5 Sunday nights.

Currently there are no logs - what categories would you suggest I start
logging?

The server comes back with simply no response.  It just times out.  It
resolves every other record I could think of to ask it.  Also, it may or may
not be relevant but if I ssh in I can ping (and hence resolve) the
mail.alexandertelecominc.com.

Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

"When you have eliminated the impossible, that which remains, however
improbable, must be the truth."
--- Sir Arthur Conan Doyle


On Mon, Nov 2, 2009 at 11:11 AM, Bill Larson  wrote:

> Josh Luthman  said:
>
> > Let me say it this way...
> >
> > Starting ~7PM EST Sunday evening the command
> >
> > dig mail.alexandertelecominc.com @74.218.88.168 #fails
> > dig mail.alexandertelecominc.com @4.2.2.2 #works
> >
> > until I issue
> >
> > rndc reload && /etc/init.d/named restart #on the 74.218.88.168 server
>
> Ok, we're getting somewhere.  Do the logs on your 74.218.88.168 server tell
> you anything?  Is there anything unusual logged prior to ~7PM EST Sunday?
>
> Again, without knowing more there is no way that we can identify exactly
> what occurred to cause the query to fail.  Also, even with all the
> information that is available, we may still not be able to identify the
> problem.
>
> Then again, is this a one time situation or does it occur regularly?
>
> > Josh Luthman
> > Office: 937-552-2340
> > Direct: 937-552-2343
> > 1100 Wayne St
> > Suite 1337
> > Troy, OH 45373
> >
> > "When you have eliminated the impossible, that which remains, however
> > improbable, must be the truth."
> > --- Sir Arthur Conan Doyle
>
> I don't know exactly why, but this statement struck me.  Sherlock Holmes
> should never have been susceptable to this logical falicy.
>
> The opposite of "the impossible" is "the possible", but no matter how
> improbable this "possible" may be, this is not the same as "truth".
>
> A counter example, something occurs and there are three posited causes.
>  One
> cause is "impossible" and can be eliminated.  This leaves the other two
> possibilities, no matter how improbable.  This does NOT make both, or
> either, of these possibilities "the truth".
>
> > On Mon, Nov 2, 2009 at 10:33 AM, Bill Larson  wrote:
> >
> > > Josh Luthman  said:
> > >
> > > > --000e0cd32f54da30b8047764ddcc
> > > > Content-Type: text/plain; charset=ISO-8859-1
> > > >
> > > > The issue is that the A record no longer gets resolved.
> > > >
> > > > The command dig mail.alexandertelecominc.com @firstserver times out.
> > >  Not
> > > > sure what else I can provide that would help.
> > >
> > > Well, when you are querying this "firstserver" (whatever that is -
> giving
> > > us
> > > a fully qualified domain name would be helpful), it times out.  The DNS
> > > server on this "firstserver" isn't answering the query.
> > >
> > > "Not sure what else I can provide that would help".  You don't give us
> much
> > > to work with.
> > >
> > > Bill Larson
> > >
> > > > Josh Luthman
> > > > Office: 937-552-2340
> > > > Direct: 937-552-2343
> > > > 1100 Wayne St
> > > > Suite 1337
> > > > Troy, OH 45373
> > > >
> > > > "When you have eliminated the impossible, that which remains, however
> > > > improbable, must be the truth."
> > > > --- Sir Arthur Conan Doyle
> > > >
> > > >
> > > > On Mon, Nov 2, 2009 at 10:13 AM, Jeremy C. Reed 
> wrote:
> > > >
> > > > > > I am looking for any suggestions or ideas to help fix this issue.
> > > Thanks
> > > > > in
> > > > > > advance!
> > > > >
> > > > > To get good help, you may want to tell us what the issue is.
> Provide
> > > > > real names and show your real tests. Also the version of BIND you
> are
> > > > > using is out of date and is no longer supported.
> > > >
> > > > --000e0cd32f54da30b8047764ddcc
> > > > Content-Type: text/html; charset=ISO-8859-1
> > > > Content-Transfer-Encoding: quoted-printable
> > > >
> > > > The issue is that the A record no longer gets resolved.The
> > > command
> > > =
> > > > dig  > > href=3D"http://mail.alexandertelecominc.com";>mail.alexandertelecomin=
> > > > c.com @firstserver times out.=A0 Not sure what else I can
> provide
> > > that
> > > =
> > > > would help.
> > > >
> > > > Josh LuthmanOffice: 937-552-2340Direct: 937-552-
> 23431100
> > > Wa=
> > > > yne StSuite 1337Troy, OH 45373"When you have
> > > eliminate=
> > > > d the impossible, that which remains, however improbable, must be the
> > > truth=
> > > > ."
> > > >
> > > > --- Sir Arthur Conan Doyle
> > > > On Mon, Nov 2, 2009 at 10:13 AM,
> > > Jeremy
> > > =
> > > > C. Reed < > > href=3D"mailto:jr...@isc.org";>jr...@isc.or=
> > > > g> wrote: > > style=3D"borde=
> > > > r-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
> padding-
> > > le=
> > > > ft: 1ex;">
> > > >
> > > > > I am looking for any suggestions or ideas to
> help
> > > fi=
> > > > x this issue.=A0 Thanks in
> > > > > advance!
> > > > 
> > > > To get good help

Re: Feature request - disable internal recursion cache

[Kevin Darcy]

Dmitry Rybin wrote:

Kevin Darcy wrote:
Daemon as unbound, pdns-recursor - much faster in recursion queries, 
that bind. :(

___
So, you don't cache locally, you forward to another daemon that (in 
the best case) answers from *its* cache.


How have you improved performance by changing nothing else and adding 
a network hop?


recursion possibilities of bind is very pity in compare with 
powerdns-recursor, unbound & so on. It allocate a lot of memory and 
make high CPU usage.


Sometimes unable change authoritative and recursive IPs.
So, you want to add an operational mode to BIND because you 
mis-deployed/mis-architected something, and are therefore locked into 
using the same IP for recursive and authoritative nameservice?


If you prefer other recursive resolvers to BIND, then go ahead and use 
them, you should have planned ahead and provisioned separate IPs so that 
you'd have that option.


You might be able to deal with your current predicament by selectively 
NAT'ing or PAT'ing incoming recursive queries, to bypass your BIND 
instance, e.g. using the "u32" module of iptables, see, e.g. (for 
inspiration) 
http://www.stupendous.net/archives/2009/01/24/dropping-spurious-nsin-recursive-queries/


But, frankly, anything along those lines would be a kludge.


   - Kevin



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

Re: ISC BIND 9.7.0b1 is now available

[Evan Hunt]

> Is it serious? The file managed-keys.bind looks normal.

It's concerning.  How many 5011-maintained zones are you running?  Can I
see your managed-keys.bind file?

I would expect the result of this to be that keys are not properly updated
in managed-keys.bind until the problem with committing to the journal has
gone away.  If it persists for more than one or two events, restart named.
If that doesn't fix it, delete managed-keys.bind.jnl and restart named
again.

I don't know how the journal's serial number would have gotten out of sync
like that.  I'll have to look closer.

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

Re: multiple internal views not working

[Kevin Darcy]

I you control all of the resolvers in this scenario, and the clients 
aren't doing their own caching-and-reordering-of-responses, you might 
consider using sortlists and round-robins instead of views. That would 
get you out of having to maintain the same zones in parallel.


Note that if the clients are recent Wintel they *already* perform 
sortlisting automatically, for addresses on their own subnets. It's 
built into the network stack. http://support.microsoft.com/kb/182644/EN-US/


- Kevin

P.S. Why would the CNAMEs need to be differentiated? Surely only the A 
records would vary, and the CNAMEs could stay the same (?)


Paul Krash wrote:

Morning!

I have been struggling with getting two internal views to work on 
three BIND servers running on Ubuntu Linux 8.04.2 x64

( kernel 2.6.24-23-server ) for two straight working days
(OK, I have other projects too. :-)

Scope: present different CNAMES and A records to one subnet 
(10.x.D.0/24) and another for all remaining (10.x.0.0/16)


This will allow my .5 subnet to automount NFS via UDP
without jiggering the network infrastructure (routers and switches).
NFS and NIS servers are homed on multiple networks
(.A.x/24, .B.x/24, .D.x/24)

Any suggestions or help would be greatly appreciated (virtual beer and 
libations are on the way) in finding a working config example.


I have read the ARMs, searched Google and communities, no joy.

I apologize in advance if there is a well known fount of this knowledge,
you know how it is, being a sys/sec/net admin at a dynamically 
changing technology company :-)


Best,

Paul Krash
Sys/Sec/Net Administrator
Exegy, Inc.
pkr...@exegy.com

This e-mail and any documents accompanying it may contain legally 
privileged and/or confidential information belonging to Exegy, Inc. 
Such information may be protected from disclosure by law. The 
information is intended for use by only the addressee. If you are not 
the intended recipient, you are hereby notified that any disclosure or 
use of the information is strictly prohibited. If you have received 
this e-mail in error, please immediately contact the sender by e-mail 
or phone regarding instructions for return or destruction and do not 
use or disclose the content to others.

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




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

Re: multiple internal views not working (requested conf files and logs)

[Paul Krash]

Jeremy C. Reed wrote:

It may be useful for you to show us what you tried (configurations and
that it is restarted), how you tested, and any network traces and log
files showing that it is not working.


All, the 'dot5' view works great. The 'internal' view does not serve.
If I reverse the view order in named.local.conf, the first view gets 
served, any views following do not.


I have incremented the files and restarted the daemon. No joy.

Thanks again!

PKrash

from the daemon.log :

Nov  2 14:38:25 bind named[22011]: client 10.x.5.25#45709: view dot5: 
query: code.fckd.net IN A +
Nov  2 14:38:36 bind named[22011]: client 10.x.5.25#48023: view dot5: 
query: home.fckd.net IN A +
Nov  2 14:39:38 bind named[22011]: client 10.x.4.123#54159: view 
internal: query: code.fckd.net IN A +
Nov  2 14:39:38 bind named[22011]: client 10.x.4.123#36511: view 
internal: query: code.fckd.net IN A +
Nov  2 14:39:38 bind named[22011]: client 10.x.4.123#37112: view 
internal: query: code IN A +



named.local.conf :



r...@bind:/etc/bind# cat named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

view dot5 {
match-clients {
10.x.5.0/24;
};
zone "5.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.5.default.rev";
};
zone "eng.exegy.net" {
type master;
file "/etc/bind/fckd.net.default.dot5";
notify yes;
also-notify {
10.x.1.32;
};
};
};

view internal {

zone "eng.exegy.net" {
type master;
file "/etc/bind/fckd.net.default.hosts";
notify yes;
also-notify {
10.x.1.32;
};
};


zone "0.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.0.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "1.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.1.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "2.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.2.default.rev";
notify yes;
also-notify {
10.x.1.32;
};ls -la
};
zone "3.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.3.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "4.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.4.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "6.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.6.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "7.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.7.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "8.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.8.rev";
};
};



fckd.net.default.dot5 :


This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple internal views not working (requested conf files and logs)

[Jeremy C. Reed]

On Mon, 2 Nov 2009, Paul Krash wrote:

> > view internal {
> > 
> > zone "eng.exegy.net" {

Do you have anything to match here? By default, match-clients and 
match-destinations default to matching all addresses (even not 
"internal"). So when you reversed, the other view (dot5) would never 
match and wouldn't work.

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

Re: multiple internal views not working (requested conf files and logs)

[Kevin Darcy]

Confused. Looks like the clients are matching the correct view, but 
"fckd.net" is not defined in either view, so what exactly was the point 
of having views? fckd.net names are going to get resolved the same 
regardless.


- Kevin

Paul Krash wrote:

Jeremy C. Reed wrote:

It may be useful for you to show us what you tried (configurations and
that it is restarted), how you tested, and any network traces and log
files showing that it is not working.


All, the 'dot5' view works great. The 'internal' view does not serve.
If I reverse the view order in named.local.conf, the first view gets 
served, any views following do not.


I have incremented the files and restarted the daemon. No joy.

Thanks again!

PKrash

from the daemon.log :

Nov 2 14:38:25 bind named[22011]: client 10.x.5.25#45709: view dot5: 
query: code.fckd.net IN A +
Nov 2 14:38:36 bind named[22011]: client 10.x.5.25#48023: view dot5: 
query: home.fckd.net IN A +
Nov 2 14:39:38 bind named[22011]: client 10.x.4.123#54159: view 
internal: query: code.fckd.net IN A +
Nov 2 14:39:38 bind named[22011]: client 10.x.4.123#36511: view 
internal: query: code.fckd.net IN A +
Nov 2 14:39:38 bind named[22011]: client 10.x.4.123#37112: view 
internal: query: code IN A +



named.local.conf :

 


r...@bind:/etc/bind# cat named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

view dot5 {
match-clients {
10.x.5.0/24;
};
zone "5.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.5.default.rev";
};
zone "eng.exegy.net" {
type master;
file "/etc/bind/fckd.net.default.dot5";
notify yes;
also-notify {
10.x.1.32;
};
};
};

view internal {

zone "eng.exegy.net" {
type master;
file "/etc/bind/fckd.net.default.hosts";
notify yes;
also-notify {
10.x.1.32;
};
};


zone "0.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.0.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "1.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.1.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "2.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.2.default.rev";
notify yes;
also-notify {
10.x.1.32;
};ls -la
};
zone "3.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.3.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "4.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.4.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "6.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.6.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "7.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.7.default.rev";
notify yes;
also-notify {
10.x.1.32;
};
};
zone "8.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.x.8.rev";
};
};



fckd.net.default.dot5 :
 



This e-mail and any documents accompanying it may contain legally 
privileged and/or confidential information belonging to Exegy, Inc. 
Such information may be protected from disclosure by law. The 
information is intended for use by only the addressee. If you are not 
the intended recipient, you are hereby notified that any disclosure or 
use of the information is strictly prohibited. If you have received 
this e-mail in error, please immediately contact the sender by e-mail 
or phone regarding instructions for return or destruction and do not 
use or disclose the content to others.

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




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

Re: Feature request - disable internal recursion cache

[Kevin Darcy]

Barry Margolin wrote:

In article ,
 Kevin Darcy  wrote:

  

Chris Thompson wrote:


On Oct 30 2009, Michael Hare wrote:

  
For those of us that are still running auth and recursive on the same 
IP, I believe the benefit would be to deploy a best practices 
recursive only nameserver on a different machine/IP address without 
getting, in my case, possibly hundreds of thousands of clients to 
change their DNS resolver IP address.


Put the authoritative-only nameservers at the new IP addresses, keeping
the recursive ones at the original IP addresses.

Been there, done that!

  
Well, except then you need to update all of your delegations. That can 
not only be an administrative hassle, but can also get very expensive, 
especially if you have hundreds of them in ccTLDs, where you have to pay 
your "in-country agent" a fee for every registry change. It's quite a 
racket.



You don't have to change all the domain registrations.  You just have to 
change the A records of the nameserver names.  Hopefully you haven't 
done something silly like use different nameserver names for each domain.
  

Unfortunately, the reality of the situation is that many folks have taken
http://cr.yp.to/djbdns/notes.html#gluelessness to heart, despite its 
obsolescence, and consider all delegations which *don't* point to names 
in the specific domain which is being delegated, to be "glueless" and in 
some way inferior to "in-bailiwick" delegations.


So the practice of delegating to domain-unique nameserver names, is 
rather rampant, and it means many folks would have to update a *lot* of 
records, if they changed the address(es) of their authoritative 
nameserver(s). It's not a trivial change at all.


- Kevin

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

Re: multiple internal views not working (requested conf files and logs)

[Paul Krash]

Jeremy C. Reed wrote:
>
> Do you have anything to match here? By default, match-clients and
> match-destinations default to matching all addresses (even not
> "internal"). So when you reversed, the other view (dot5) would never
> match and wouldn't work.
>

Hey Mr. Reed!

Would this statement be enough for the second 'internal' view? :

match-clients {
!10.x.5.0/24;
};

Or, do I have to explicitly define a match for every subnet?

e.g.:

match-clients {
  !10.x.5.0/24;
  10.x.1.0/24;
  10.x.2.0/24;
  10.x.3.0/24;
  10.x.4.0/24;
  10.x.6.0/24;
  10.x.7.0/24;
  10.x.8.0/24;
};

Best,

PKrash

This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple internal views not working (requested conf files

[Krash, Paul]

Kevin Darcy asked:

>Confused. Looks like the clients are matching the 
>correct view, but "fckd.net" is not defined in either view,
> so what exactly was the point of having views? fckd.net names are
>going to get resolved the same regardless.

I attempted to obfuscate our internal domain name, Mr. Reed caught it.
fckd.net is the imaginary name of the segment I am serving.

Sorry for the confusion, too many balls in the air today
(some are on the floor :-)

what I understand that this:

view dot5 {
match-clients {
10.x.5.0/24;
};
zone "5.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.19.5.default.rev";
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default.dot5";
notify yes;
also-notify {
10.x.1.32;
};
};
};
_

will serve one zone to .5 network only.

While this:



view internal {

match-clients {
!10.x.5.0/24;
10.x.x.0/16 
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default";
notify yes;
also-notify {
10.x.1.32;
};
};
---

will serve a different zone file to the rest of the 10.x.x.0/16 network.

I think I am close to resolving this, back to integration of Samba+NFS+
NIS+LDAP+DHCP+DNS+Kerberos w/Active Directory 2008, without third party
plugins and helpers.(*long* term project)[sigh]

PKrash
 
This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple internal views not working (requested conf files

[Kevin Darcy]

Krash, Paul wrote:

Kevin Darcy asked:

  
Confused. Looks like the clients are matching the 
correct view, but "fckd.net" is not defined in either view,

so what exactly was the point of having views? fckd.net names are
going to get resolved the same regardless.



I attempted to obfuscate our internal domain name, Mr. Reed caught it.
fckd.net is the imaginary name of the segment I am serving.
  
Ah, OK. But now that the real domain name has been "outed", is there any 
point in trying to obfuscate it?

Sorry for the confusion, too many balls in the air today
(some are on the floor :-)

what I understand that this:

view dot5 {
match-clients {
10.x.5.0/24;
};
zone "5.x.10.in-addr.arpa" {
type master;
file "/etc/bind/10.19.5.default.rev";
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default.dot5";
notify yes;
also-notify {
10.x.1.32;
};
};
};
_

will serve one zone to .5 network only.

While this:



view internal {

match-clients {
!10.x.5.0/24;
10.x.x.0/16 
};
zone "fckd.net" {
type master;
file "/etc/bind/fckd.net.default";
notify yes;
also-notify {
10.x.1.32;
};
};
---

will serve a different zone file to the rest of the 10.x.x.0/16 network.
  
Views are matched in order, so "!10.x.5.0/24;" is redundant -- anything 
in that range would have been matched by the previous view.


Also, if 10.x/16 matches your entire community of clients you could just 
use "any" for the second view.

I think I am close to resolving this, back to integration of Samba+NFS+
NIS+LDAP+DHCP+DNS+Kerberos w/Active Directory 2008, without third party
plugins and helpers.(*long* term project)[sigh]
  
Make sure to publish a quick 3-step setup guide once you're done with 
that :-)


- Kevin

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

Re: multiple internal views not working (requested conf files

[Alan Clegg]

Kevin Darcy wrote:

Views are matched in order, so "!10.x.5.0/24;" is redundant -- anything 
in that range would have been matched by the previous view.


But, but by explicitly putting it there, the ordering of the views is 
no-longer important.  "Better safe than sorry".


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

Re: multiple internal views not working (requested conf files

[Kevin Darcy]

Alan Clegg wrote:

Kevin Darcy wrote:

Views are matched in order, so "!10.x.5.0/24;" is redundant -- 
anything in that range would have been matched by the previous view.


But, but by explicitly putting it there, the ordering of the views is 
no-longer important. "Better safe than sorry".


If I were inclined to rearrange views on a whim, then maybe I'd think 
more highly of the value of "view portability".


But the typical view-based config I've ever dealt with had one or more 
views matching specific ranges and/or TSIG keys, followed by an 
"any"-matching view at the end. Such a structure is inherently 
sequential and does not lend itself to rearrangement.


I'm also wary of declaring the same range in multiple match lists (once 
asserted, then negated everywhere else), since that means if the numeric 
value of the range changes, you have multiple places to update, and you 
could miss one.


- Kevin

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

multiple internal views not working (RESOLVED)

[Paul Krash]

All,

thanks so much for your help in understanding match-clients in the view 
statement for zones.


For historical purposes (and future searchers) this statement works:

match clients { !10.x.5.0/24; 10.x.0.0/16; }

doesn't serve .5, but serves everything else.

Thank you Mr. Clegg (where do I send that beer? :-)

Now I can have very complex views (coming soon {tm}) and not have to 
worry about those poor folks looking at this two years from now,
when the network has grow into multiple /16s with all the varied 
security that will be necessary when we have more than a basketful

of subnets. :-)

The three step process for 
LDAP+DHCP+LDAP+SAMBA(CIFS)+BIND+NFS+NIS+Kerberos integration with Active 
Directory 2008 without third party tools/helpers:


When I get this working (if it is even possible) I will post a virtual 
appliance, with a complete HOWTO.  I've gotten most of it to work,
the LDAP is particularly fckd, Kerberos key caching on Centos 5.3 
without certificates is troublesome.  Syncing BIND DNS with Active 
Directory seems to work, machine accounts, not so much.


Anyways, thanks for all your help, it was great!

Best,

PKrash

This e-mail and any documents accompanying it may contain legally privileged 
and/or confidential information belonging to Exegy, Inc. Such information may 
be protected from disclosure by law. The information is intended for use by 
only the addressee. If you are not the intended recipient, you are hereby 
notified that any disclosure or use of the information is strictly prohibited. 
If you have received this e-mail in error, please immediately contact the 
sender by e-mail or phone regarding instructions for return or destruction and 
do not use or disclose the content to others.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple internal views not working

[Barry Margolin]

In article ,
 "Paul Krash"  wrote:

> Morning!
> 
> I have been struggling with getting two internal views to work on three 
> BIND servers running on Ubuntu Linux 8.04.2 x64
> ( kernel 2.6.24-23-server ) for two straight working days
> (OK, I have other projects too. :-)
> 
> Scope: present different CNAMES and A records to one subnet 
> (10.x.D.0/24) and another for all remaining (10.x.0.0/16)
> 
> This will allow my .5 subnet to automount NFS via UDP
> without jiggering the network infrastructure (routers and switches).
> NFS and NIS servers are homed on multiple networks
> (.A.x/24, .B.x/24, .D.x/24)
> 
> Any suggestions or help would be greatly appreciated (virtual beer and 
> libations are on the way) in finding a working config example.
> 
> I have read the ARMs, searched Google and communities, no joy.
> 
> I apologize in advance if there is a well known fount of this knowledge,
> you know how it is, being a sys/sec/net admin at a dynamically changing 
> technology company :-)

Make sure you have the views in the appropriate order.  Views are 
checked in the order they appear in the named.conf file, not order of 
specificity.  So you need to have the /24 view before the /16 view.

-- 
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: One A record fails on one server on Sunday evening

[Barry Margolin]

In article ,
 Josh Luthman  wrote:

> It has happened the last 4 or 5 Sunday nights.
> 
> Currently there are no logs - what categories would you suggest I start
> logging?
> 
> The server comes back with simply no response.  It just times out.  It
> resolves every other record I could think of to ask it.  Also, it may or may
> not be relevant but if I ssh in I can ping (and hence resolve) the
> mail.alexandertelecominc.com.

When it's failing, make a cache dump.  Check the cache for the NS 
records of the domain, and the A records for the nameservers.

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