expired or non-authoritative domains

[Konstantin N. Bezruchenko]

Hello,

I have a two DNS servers, which our customers uses to "host" their domains.

Sometimes customers forgot to renew domain, or just don't want to
renew it, or they move domain to other name servers.
However i still have records for this domains in my configs.

Is there any way to determine which domains are no longer use my name servers?

Sure, i can write some script just to make queries to root servers,
parse answers and look if domains is still refers to my nameservers,
but i believe there must be some native way?

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

Re: expired or non-authoritative domains

[Mark Andrews]

In message <2070cf420902060124ged41b99jf56a15306c9b2...@mail.gmail.com>, "Konst
antin N. Bezruchenko" writes:
> Hello,
> 
> I have a two DNS servers, which our customers uses to "host" their domains.
> 
> Sometimes customers forgot to renew domain, or just don't want to
> renew it, or they move domain to other name servers.
> However i still have records for this domains in my configs.
> 
> Is there any way to determine which domains are no longer use my name servers
> ?
> 
> Sure, i can write some script just to make queries to root servers,
> parse answers and look if domains is still refers to my nameservers,
> but i believe there must be some native way?

Unless you are serving tld's you don't want to query the root
servers.  You want to query the parent servers and yes that
is the easiest way.
 
Mark
> Thanks.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SERVFAIL from validating nameservers for advocaat.pro & advocaten.pro

[Sam Wilson]

In article ,
 Mark Andrews  wrote:

> In message , Chris 
> Thompson writes:
> > On Feb 5 2009, I wrote:
> > 
> > >DLV records for advocaat.pro & advocaten.pro are among the recent
> >additions to dlv.isc.org. Using validating recursive nameservers
> > >running BIND 9.5.1-P1 (configured to trust dlv.isc.org), I get SERVFAILs
> > >looking things up in them, although not consistently. This doesn't
> > >happen with non-validating nameservers.
> > >
> > >I can't work out what is wrong with them. Does anyone else see the
> > >same effect?
> > 
> > More info about the "not consistently" bit. With nothing about
> > them in the cache ("rndc flushname advocaat.pro") looking up SOA or
> > NS records for them gives SERVFAIL. But looking up A records does
> > not, and after that SOA and NS lookups work OK as well.
> > 
> > Hmmm...
> 
>   The TLD lies.  DNSSEC is doing exactly what it is
>   supposed to do and is blocking ibad answers.

This may be coincidence but we had something similar with dell.com 
servers for a while yesterday - some of our caching servers would return 
SERVFAIL when looking up either a particular name, 
premierconfigure.euro.dell.com, or the NS records for dell.com.  I was 
still baffled when it fixed itself.  Did anyone else notice anything 
similar?

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

Re: How to create the TSIG?

[Niall O'Reilly]

On Thu, 2009-02-05 at 16:58 -0800, Chris Buxton wrote:
> Use a different key for each slave.

Definitely, if each of your slaves is under distinct
administration.

If some organization is managing more than one of your
slaves for you, I'ld suggest using a distinct key only
for each cluster of commonly-administered servers.
This may cut down on key-management effort.

Do take care to use a secure channel for distributing
the keys!

/Niall


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

RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting

[wiskbroom]

Thanks for the reply.  My DMZ, or external lookups, are all performed via one 
of six BIND-9 servers.

The product that we use is based on BIND-8, though they've recently come out 
with a BIND-9 version.

If I "split" my lookups and have internal lookups pointed at the MS DNS 
servers, and non-authoritative lookups to my external servers (running BIND-9), 
then shouldn't this address the issues you spoke of?

How are you able to allow for the windoze boxes to automatically add entries? 
In other words, a strong case they made is that they must presently maintain 
two databases, AD *and* DNS.  With MS DNS, they say, this is not the case 
whereby when you add an entry or join a host, that entry is automatically added 
in DNS.  

In there a way to do this in BIND?

Thanks again,

.vp



> Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For 
> Coexisting
> Date: Fri, 6 Feb 2009 09:49:42 -0500
> From: jlight...@water.com
> To: wiskbr...@hotmail.com; bind-users@lists.isc.org
>
> I don't see why it is either/or.
>
> Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
> DNS servers for external lookups. The internal servers refer all
> queries they aren't authoritative for to the external ones which in turn
> refer all queries for domains we don't own to the root servers.
>
> The only "gotcha" is that we have some domains that we want to present
> different IPs for internally (10.x.x.x) or externally (12.x.x.x). On
> the Windoze DNS servers they have our primary domain with those internal
> addresses and on the BIND DNS servers we have those external addresses.
>
>
> Of course you could do it all with just BIND servers running views but
> this is the way I inherited the BIND servers here.
>
> We don't seem to have the headaches your Windoze team is moaning about.
> Hopefully you are running redundant (master/slave) BIND servers?
>
> Also I'd suggest upgrading to BIND 9 once you've got all the rest of
> this quieted down.
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> wiskbr...@hotmail.com
> Sent: Friday, February 06, 2009 9:25 AM
> To: bind-users@lists.isc.org
> Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
> Coexisting
>
>
>
> Hello;
>
> My site is presently using a product derived from BIND-8 for internal
> DNS only.
>
> For years our Windows team has been arguing that they want to be
> non-dependent on the non-MS DNS servers; which they say causes them much
> grief on firmwide shutdown/bootups.
>
> Well, their concerns have fallen on ears of those who can make that
> decision and it now appears as though we must either come up with good
> reasons why we should retain BIND, or a BIND derived product, or simply
> a plan to allow MSDNS and BIND to coexist at all.
>
> Can anyone provide me, or point me at, any good docs on this subject, I
> am certain that their a tons of stuff out there, I need simple, to the
> point type of stuff.
>
> Also, can anyone think of any good reason why our internal, non-public
> accessible network, should not just be allowed to run either a mixed
> BIND/MS-DNs setup? The slave/cache/whatever-but not master, would have
> to be BIND.
>
>
> The case the windows team made was ease of adding entries, you simply
> add into the MMC, or even easier, when you join a host into a domain, it
> adds itself.
>
> Thanks all,
>
> .vp
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> Please consider our environment before printing this e-mail or attachments.
> --
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
> information and is for the sole use of the intended recipient(s). If you are 
> not the intended recipient, any disclosure, copying, distribution, or use of 
> the contents of this information is prohibited and may be unlawful. If you 
> have received this electronic transmission in error, please reply immediately 
> to the sender that you have received the message in error, and delete it. 
> Thank you.
> --
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices ForCoexisting

[Baird, Josh]

We also run in a mixed MSDNS/BIND environment.  All of our AD domain
controllers run MSDNS and are authoritative for the AD domain only.  They
forward all non-authoritative requests (all non AD domain queries) to
caching BIND9/Linux servers which also contain slave zones for all of our
internal domains (non AD) to override recursion.  Our BIND environment also
gets a copy of the AD zone so they are also able to resolve the AD domain
requests if necessary. 

Our external authoritative infrastructure is entirely BIND.  We do not use
views.  We have separate internal and external (stealth) masters.

Josh

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff Lightner
Sent: Friday, February 06, 2009 8:50 AM
To: wiskbr...@hotmail.com; bind-users@lists.isc.org
Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices
ForCoexisting

I don't see why it is either/or.

Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
DNS servers for external lookups.   The internal servers refer all
queries they aren't authoritative for to the external ones which in turn
refer all queries for domains we don't own to the root servers.

The only "gotcha" is that we have some domains that we want to present
different IPs for internally (10.x.x.x) or externally (12.x.x.x).  On
the Windoze DNS servers they have our primary domain with those internal
addresses and on the BIND DNS servers we have those external addresses.


Of course you could do it all with just BIND servers running views but
this is the way I inherited the BIND servers here.  

We don't seem to have the headaches your Windoze team is moaning about.
Hopefully you are running redundant (master/slave) BIND servers?

Also I'd suggest upgrading to BIND 9 once you've got all the rest of
this quieted down.  

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of
wiskbr...@hotmail.com
Sent: Friday, February 06, 2009 9:25 AM
To: bind-users@lists.isc.org
Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
Coexisting



Hello;

My site is presently using a product derived from BIND-8 for internal
DNS only.

For years our Windows team has been arguing that they want to be
non-dependent on the non-MS DNS servers; which they say causes them much
grief on firmwide shutdown/bootups. 

Well, their concerns have fallen on ears of those who can make that
decision and it now appears as though we must either come up with good
reasons why we should retain BIND, or a BIND derived product, or simply
a plan to allow MSDNS and BIND to coexist at all.

Can anyone provide me, or point me at, any good docs on this subject, I
am certain that their a tons of stuff out there, I need simple, to the
point type of stuff.

Also, can anyone think of any good reason why our internal, non-public
accessible network, should not just be allowed to run either a mixed
BIND/MS-DNs setup?  The slave/cache/whatever-but not master, would have
to be BIND. 


The case the windows team made was ease of adding entries, you simply
add into the MMC, or even easier, when you join a host into a domain, it
adds itself.

Thanks all,

.vp

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
 
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you
have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


smime.p7s
Description: S/MIME cryptographic signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices ForCoexisting

[Baird, Josh]

In my case, we let AD/MSDNS do dynamic updates.. no dynamic updates are
necessary with BIND.  Not sure I understand your "split" lookups - but your
external authoritative nameservers should NOT allow recursion.

Josh

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of wiskbr...@hotmail.com
Sent: Friday, February 06, 2009 9:09 AM
To: jlight...@water.com; bind-users@lists.isc.org
Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices
ForCoexisting


Thanks for the reply.  My DMZ, or external lookups, are all performed via
one of six BIND-9 servers.

The product that we use is based on BIND-8, though they've recently come out
with a BIND-9 version.

If I "split" my lookups and have internal lookups pointed at the MS DNS
servers, and non-authoritative lookups to my external servers (running
BIND-9), then shouldn't this address the issues you spoke of?

How are you able to allow for the windoze boxes to automatically add
entries? In other words, a strong case they made is that they must presently
maintain two databases, AD *and* DNS.  With MS DNS, they say, this is not
the case whereby when you add an entry or join a host, that entry is
automatically added in DNS.  

In there a way to do this in BIND?

Thanks again,

.vp



> Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
Coexisting
> Date: Fri, 6 Feb 2009 09:49:42 -0500
> From: jlight...@water.com
> To: wiskbr...@hotmail.com; bind-users@lists.isc.org
>
> I don't see why it is either/or.
>
> Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
> DNS servers for external lookups. The internal servers refer all
> queries they aren't authoritative for to the external ones which in turn
> refer all queries for domains we don't own to the root servers.
>
> The only "gotcha" is that we have some domains that we want to present
> different IPs for internally (10.x.x.x) or externally (12.x.x.x). On
> the Windoze DNS servers they have our primary domain with those internal
> addresses and on the BIND DNS servers we have those external addresses.
>
>
> Of course you could do it all with just BIND servers running views but
> this is the way I inherited the BIND servers here.
>
> We don't seem to have the headaches your Windoze team is moaning about.
> Hopefully you are running redundant (master/slave) BIND servers?
>
> Also I'd suggest upgrading to BIND 9 once you've got all the rest of
> this quieted down.
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> wiskbr...@hotmail.com
> Sent: Friday, February 06, 2009 9:25 AM
> To: bind-users@lists.isc.org
> Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
> Coexisting
>
>
>
> Hello;
>
> My site is presently using a product derived from BIND-8 for internal
> DNS only.
>
> For years our Windows team has been arguing that they want to be
> non-dependent on the non-MS DNS servers; which they say causes them much
> grief on firmwide shutdown/bootups.
>
> Well, their concerns have fallen on ears of those who can make that
> decision and it now appears as though we must either come up with good
> reasons why we should retain BIND, or a BIND derived product, or simply
> a plan to allow MSDNS and BIND to coexist at all.
>
> Can anyone provide me, or point me at, any good docs on this subject, I
> am certain that their a tons of stuff out there, I need simple, to the
> point type of stuff.
>
> Also, can anyone think of any good reason why our internal, non-public
> accessible network, should not just be allowed to run either a mixed
> BIND/MS-DNs setup? The slave/cache/whatever-but not master, would have
> to be BIND.
>
>
> The case the windows team made was ease of adding entries, you simply
> add into the MMC, or even easier, when you join a host into a domain, it
> adds itself.
>
> Thanks all,
>
> .vp
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
> Please consider our environment before printing this e-mail or
attachments.
> --
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you
have received this electronic transmission in error, please reply
immediately to the sender that you have received the message in error, and
delete it. Thank you.
> --
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


smime.p7s
Description: S/MIME cryptographic signature
__

Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting

[wiskbroom]

Hello;

My site is presently using a product derived from BIND-8 for internal DNS only.

For years our Windows team has been arguing that they want to be non-dependent 
on the non-MS DNS servers; which they say causes them much grief on firmwide 
shutdown/bootups. 

Well, their concerns have fallen on ears of those who can make that decision 
and it now appears as though we must either come up with good reasons why we 
should retain BIND, or a BIND derived product, or simply a plan to allow MSDNS 
and BIND to coexist at all.

Can anyone provide me, or point me at, any good docs on this subject, I am 
certain that their a tons of stuff out there, I need simple, to the point type 
of stuff.

Also, can anyone think of any good reason why our internal, non-public 
accessible network, should not just be allowed to run either a mixed 
BIND/MS-DNs setup?  The slave/cache/whatever-but not master, would have to be 
BIND. 


The case the windows team made was ease of adding entries, you simply add into 
the MMC, or even easier, when you join a host into a domain, it adds itself.

Thanks all,

.vp

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

RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices ForCoexisting

[Jeff Lightner]

I'm with Josh on this.

The only things that we have that would have both internal and external
addresses are servers.  For the domain I'm speaking of those are hard
assigned addresses not DHCP so there is no dynamic update being done.
We simply send an email to the Windoze Admins asking them to add the
internal IP to their DNS records for our servers as we build them.  We
have VLAN ranges for different kinds of servers (e.g. UNIX VLAN, Linux
VLAN etc...).  

There should be no need to add external IPs for all your desktops unless
you're doing something weird. (Every user has his own web server maybe?.
For the desktops (which are in their own VLANs) and VPN connections
there are DHCP entries that go into the Windoze DNS servers dynamically
but those never go into the BIND DNS servers because we're not expecting
queries from outside our network to find specific desktops.   In the
event we have a need for outsiders (e.g. vendors) who have a need to get
to "internal" connections they typically set up a VPN connection for
them so they use the Windoze DNS.  The firewall is used to restrict
which systems they can actually access.

-Original Message-
From: Baird, Josh [mailto:jba...@follett.com] 
Sent: Friday, February 06, 2009 10:13 AM
To: wiskbr...@hotmail.com; Jeff Lightner; bind-users@lists.isc.org
Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices
ForCoexisting

In my case, we let AD/MSDNS do dynamic updates.. no dynamic updates are
necessary with BIND.  Not sure I understand your "split" lookups - but
your
external authoritative nameservers should NOT allow recursion.

Josh

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of
wiskbr...@hotmail.com
Sent: Friday, February 06, 2009 9:09 AM
To: jlight...@water.com; bind-users@lists.isc.org
Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices
ForCoexisting


Thanks for the reply.  My DMZ, or external lookups, are all performed
via
one of six BIND-9 servers.

The product that we use is based on BIND-8, though they've recently come
out
with a BIND-9 version.

If I "split" my lookups and have internal lookups pointed at the MS DNS
servers, and non-authoritative lookups to my external servers (running
BIND-9), then shouldn't this address the issues you spoke of?

How are you able to allow for the windoze boxes to automatically add
entries? In other words, a strong case they made is that they must
presently
maintain two databases, AD *and* DNS.  With MS DNS, they say, this is
not
the case whereby when you add an entry or join a host, that entry is
automatically added in DNS.  

In there a way to do this in BIND?

Thanks again,

.vp



> Subject: RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
Coexisting
> Date: Fri, 6 Feb 2009 09:49:42 -0500
> From: jlight...@water.com
> To: wiskbr...@hotmail.com; bind-users@lists.isc.org
>
> I don't see why it is either/or.
>
> Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
> DNS servers for external lookups. The internal servers refer all
> queries they aren't authoritative for to the external ones which in
turn
> refer all queries for domains we don't own to the root servers.
>
> The only "gotcha" is that we have some domains that we want to present
> different IPs for internally (10.x.x.x) or externally (12.x.x.x). On
> the Windoze DNS servers they have our primary domain with those
internal
> addresses and on the BIND DNS servers we have those external
addresses.
>
>
> Of course you could do it all with just BIND servers running views but
> this is the way I inherited the BIND servers here.
>
> We don't seem to have the headaches your Windoze team is moaning
about.
> Hopefully you are running redundant (master/slave) BIND servers?
>
> Also I'd suggest upgrading to BIND 9 once you've got all the rest of
> this quieted down.
>
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> wiskbr...@hotmail.com
> Sent: Friday, February 06, 2009 9:25 AM
> To: bind-users@lists.isc.org
> Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
> Coexisting
>
>
>
> Hello;
>
> My site is presently using a product derived from BIND-8 for internal
> DNS only.
>
> For years our Windows team has been arguing that they want to be
> non-dependent on the non-MS DNS servers; which they say causes them
much
> grief on firmwide shutdown/bootups.
>
> Well, their concerns have fallen on ears of those who can make that
> decision and it now appears as though we must either come up with good
> reasons why we should retain BIND, or a BIND derived product, or
simply
> a plan to allow MSDNS and BIND to coexist at all.
>
> Can anyone provide me, or point me at, any good docs on this subject,
I
> am certain that their a tons of stuff out there, I need simple, to the
> point type of stuff.
>
> Also, can 

RE: Case For Microsoft DNS v. BIND 9 - Or Best Practices For Coexisting

[Jeff Lightner]

I don't see why it is either/or.

Here we have Windoze DNS servers for internal lookups and Linux/BIND 9
DNS servers for external lookups.   The internal servers refer all
queries they aren't authoritative for to the external ones which in turn
refer all queries for domains we don't own to the root servers.

The only "gotcha" is that we have some domains that we want to present
different IPs for internally (10.x.x.x) or externally (12.x.x.x).  On
the Windoze DNS servers they have our primary domain with those internal
addresses and on the BIND DNS servers we have those external addresses.


Of course you could do it all with just BIND servers running views but
this is the way I inherited the BIND servers here.  

We don't seem to have the headaches your Windoze team is moaning about.
Hopefully you are running redundant (master/slave) BIND servers?

Also I'd suggest upgrading to BIND 9 once you've got all the rest of
this quieted down.  

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of
wiskbr...@hotmail.com
Sent: Friday, February 06, 2009 9:25 AM
To: bind-users@lists.isc.org
Subject: Case For Microsoft DNS v. BIND 9 - Or Best Practices For
Coexisting



Hello;

My site is presently using a product derived from BIND-8 for internal
DNS only.

For years our Windows team has been arguing that they want to be
non-dependent on the non-MS DNS servers; which they say causes them much
grief on firmwide shutdown/bootups. 

Well, their concerns have fallen on ears of those who can make that
decision and it now appears as though we must either come up with good
reasons why we should retain BIND, or a BIND derived product, or simply
a plan to allow MSDNS and BIND to coexist at all.

Can anyone provide me, or point me at, any good docs on this subject, I
am certain that their a tons of stuff out there, I need simple, to the
point type of stuff.

Also, can anyone think of any good reason why our internal, non-public
accessible network, should not just be allowed to run either a mixed
BIND/MS-DNs setup?  The slave/cache/whatever-but not master, would have
to be BIND. 


The case the windows team made was ease of adding entries, you simply
add into the MMC, or even easier, when you join a host into a domain, it
adds itself.

Thanks all,

.vp

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
 
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Unexpected error question

[Cherney John-CJC030]

 
Ah! Now I see. Thank you! That has narrowed my search area. I'll post
back when I find the file I need to change. 

Thanks,
jwc
-Original Message-
From: mark_andr...@isc.org [mailto:mark_andr...@isc.org] 
Sent: Thursday, February 05, 2009 4:11 PM
To: Cherney John-CJC030
Cc: bind-us...@isc.org
Subject: Re: Unexpected error question 


In message
, "Ch
erney John-CJC030" writes:
> Yes, I normally use svcadm disable dns/server to stop named. Also, 
> I've modified the dns/server stop method from the usual "kill:" to 
> "/usr/sbin/rndc stop". I did that because I want to make sure the 
> cache gets written to the db files, which an rndc stop does. It seems 
> that named is having a problem with one of the files, but I can't tell

> which one from the first syslog message.

It is only one error split over two messages.

isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
  NS_LOGMODULE_MAIN, ISC_LOG_ERROR,
  "%s:%d: unexpected error:", file, line);
isc_log_vwrite(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
   NS_LOGMODULE_MAIN, ISC_LOG_ERROR,
   format, args);

Mark
 
> jwc
> 
> -Original Message-
> From: Gregory Hicks [mailto:ghi...@hicks-net.net]
> Sent: Thursday, February 05, 2009 10:56 AM
> To: bind-us...@isc.org; Cherney John-CJC030
> Cc: mark_andr...@isc.org
> Subject: RE: Unexpected error question
> 
> 
> > Subject: RE: Unexpected error question
> > Date: Thu, 5 Feb 2009 09:51:05 -0500
> > From: "Cherney John-CJC030" 
> > To: 
> > 
> > I see. I was assuming that the second line was caused by the first
> line,
> > and that if I could get more info on the first line, I could take 
> > care
> 
> > of both of them. I have a "named" user that the named process is run
> as.
> > However, I see these errors even when I use rndc stop as root. 
> > 
> > Is there any resource that recommends what permissions need to be on

> > specific SMF files for DNS? (or in general). Or is this even a 
> > permissioning issue with SMF files?
> 
> The problem comes from the idea that SMF wants to be the 'controller'.
> When the program in question (named in the case) receives a 'stop'
> command from rndc, SMF doesn't know WHY the program stopped, just that

> it DID stop.  Thus the error.
> 
> A better way to stop named might be
> 
> svcadm named disable
> 
> (I think that's the right syntax but could be wrong.  I am NOT an SMF
> expert...)  That should avoid the error message.
> 
> There was some discussion on the smf-disc...@opensolaris.org list last

> month on how to avoid error messages when you don't care if the 
> underlying service stops all by itself.
> 
> Regards,
> Gregory Hicks
> 
> > 
> > Thanks!
> > jwc
> > 
> > -Original Message-
> > From: mark_andr...@isc.org [mailto:mark_andr...@isc.org]
> > Sent: Thursday, February 05, 2009 1:18 AM
> > Cc: Cherney John-CJC030; bind-us...@isc.org
> > Subject: Re: Unexpected error question
> > 
> > 
> > In message <200902050609.n1569ktg082...@drugs.dv.isc.org>, Mark
> Andrews
> > writes:
> > > 
> > > In message
> > , "
> > > Ch
> > > erney John-CJC030" writes:
> > > > I'm seeing the following lines in syslog, which occur when I 
> > > > shut down
> > > > named:
> > > > =20
> > > > general: error: ./main.c:858: unexpected error:
> > > > general: error: smf_disable_instance() failed for 
> > > > svc:/network/dns/server:default : insufficient privileges for
> action
> > 
> > > > =20 I'm running 9.3.5-P1 on Solaris 10 x86 =20 I took a quick 
> > > > look
> 
> > > > at the source code and it looks like there should be a file 
> > > > and/or
> 
> > > > filenumber as part of the unexpected error line. I've noticed 
> > > > the same two lines when I issue an rndc stop. The named process 
> > > > does stop, but I'm worried that there may be data in the cache 
> > > > that
> isn't
> > 
> > > > getting written to the db files. Nothing jumped out at me from 
> > > > my google search. It seems like I have a file permissions issue,

> > > > but
> I
> > > > haven't recently changed any file permissions. I don't see any 
> > > > unusual messages on startup.=20 =20 Can someone point me the 
> > > > right
> 
> > > > direction for this? Is there any other information I 
> > > > should/could provide?
> > > > =20
> > > > Thanks!
> > > > jwc
> > > 
> > >   SMF is Sun's management facility.  The code in question was
> > >   submitted by Sun.  I would be looking at how you have SMF set
> > >   up in particular how to give the user named is running under
> > >   permission to disable itself.
> > 
> > See also
> > 
> > as mentioned in the FAQ.
> > 
> > > 
> > >   Mark
> > > --
> > > Mark Andrews, ISC
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742 INTERNET: 
> mark_andr...@isc.org
> > > 

Re: How to create the TSIG?

[Michelle Konzack]

Hello Chris,

thank you for the "HOWTO"... now it is more clear.

OK, there are some stange things happen to my master DNS @home.  Since I
it seems I had a "nsupdate" from my Laptop,  an  update  from  my  work-
stations was working perfectly and now it comes:

I have never used:

Am 2009-02-05 16:58:27, schrieb Chris Buxton:
> Create a key:
>
> dnssec-keygen -a hmac-md5 -b 512 -n host slave1.key
>
> (Note: Use something better than hmac-md5 if your BIND version supports 
> it.) This creates two files, with similar names. Extract the secret from 
> either of them (it is the same in both) and create a key statement:
>
> key "slave1.key" {
>   algorithm hmac-md5;
>   secret "put here the secret from the file";
> };

and this installed and was not looking into my local DNS  since  several
weeks...  Today I have found

1) a modified file
   /etc/bind/net.tamay-dogan.private

2) two new files
   /etc/bind/net.tamay-dogan.private.njl
   /etc/bind/rndc.key

where the last one has the key enty above.

Q: Does the "nsupdate" create/change this files?

Note:  The rndc.key file is not included in any files, hence I
   asume it is not alive and I have to include it into my.
   /etc/bind/named.conf.local (Debian System)

> Put this statement into named.conf on both the master server and one of 
> your slaves. Then, put this into the master server's named.conf:
>
> server 192.0.2.1 { // use the actual IP address of the slave here
>   keys { slave1.key; };
> };
>
> On the slave:
>
> server 192.0.2.2 { // this should be the IP address of the master
>   keys { slave1.key; };
> };

OK done.

> This will then secure all communication (except forwarded updates)  
> between master and slave1. That includes notifies, SOA queries and  
> responses, and zone transfers.
>
> Repeat the above for each slave. Use a different key for each slave.  
> This means the master will have 5 keys defined (plus an RNDC key,  
> hopefully), and 5 server statements. You may also want to create  
> additional keys (and additional server statements) for use between  
> slaves, just in case you ever need to promote one.

OK, now I have:

key "rndc-key" {
...
};
key "tdnet.key" {
...
};
key "hetzner.key" {
...
};
key "vallendor.key" {
...
};

and 5 entries like

server 192.168.0.194 {
keys { tdnet.key; };
};

> Next, create yet another key for dynamic updates. Put that key's name  
> into your allow-update statement. Turn on update-forwarding on the  

Done but...

> slaves, like this (in each slave zone):
>
> allow-update-forwarding { any; };

OK done.

> Since the master will only permit signed updates, and since the slaves  
> will forward signed updates unmodified (signatures intact), you do not  
> need to secure this ACL.

I have for testing only me second local DNS included and I call the  key
"tdnet.key" since it is under my own control...

I have now (unneccesary lines striped)

[ '/etc/bind/named.conf' ]--
include "/etc/bind/named.conf.options";

zone "." {
type hint;
file "/etc/bind/db.root";
};

zone "localhost" {
type master;
file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};

include "/etc/bind/named.conf.local";


[ '/etc/bind/named.conf.options' ]--
options {
directory "/var/cache/bind";
check-names master fail;
check-names slave warn;
check-names response ignore;
auth-nxdomain no;
listen-on-v6 { any; };
listen-on { 192.168.0.74; };
};


[ '/etc/bind/named.conf.local' ]
key "rndc-key" {
algorithm hmac-md5;
secret " ...very_short_key... ";
};

key "tdnet.key" {
algorithm hmac-md5;
secret " ...very_long_key... ";
};

server 192.168.0.194 {
keys { tdnet.key; };
};

zone "private.tamay-dogan.net" {
typemaster;
file"/etc/bind/net.tamay-dogan.private";
allow-transfer  { 192.168.0.194; };
allow-update{ tdnet.key;  };
//  allow-update{ 192.168.0.91; 192.168.0.92; 192.168.0.93; 
192.168.0.112;  };
};

zone "0.168.192.in-addr.arpa" {
typemaster;
file"/etc/bind/db.192.168.0";
allow-transfer  { 192.168.0.194; };
};


And my Intranet Zone looks like:

[ '/etc/bind/net.tamay.dogan.private' ]-
$ORIGIN .
$TTL 86400  ; 1 day
private.tamay-dogan.net IN SOA  dns.private.tamay-dogan.net. 
hostmas

Re: How to create the TSIG?

[Chris Buxton]

Point 1: The rndc.key file is referenced automatically if its contents  
are not included, because you do not have a controls statement. This  
is confusing, so please read the section of the ARM on the controls  
statement.

__

Point 2: Your 'allow-update' statement is wrong. You have:

allow-update { tdnet.key; };

Problem one is, you forgot the word "key".

allow-update { key tdnet.key; };

Problem two is, you're re-using a server-to-server key for dynamic  
updates. This is bad practice. You should have one key for dynamic  
updates to the zone, and another key for all communication with the  
server at 192.168.0.194.

__

Point 3: Since you have an allow-transfer statement in the zone, you  
should change it to this:


allow-transfer { key tdnet.key; };

Add all 5 slave server keys to that list. Furthermore, you can move  
this list out of the zone statements and into the options statement,  
so that you don't have to duplicate it once per zone.

__

Point 4: The reason your zone has been rewritten, and the reason for  
the .jnl file, is that your zone has received a dynamic update. This  
is normal behavior. nsupdate doesn't directly create the journal file,  
nor does it directly modify the zone file; instead, named does this in  
response to the dynamic update. The .jnl file is created immediately  
upon receiving the first update, while the main zone file is rewritten  
15 minutes later.


You should constrain the size of your journal files, in the options  
statement, with something like this:


max-journal-size 5M;

The rndc.key file was created by the package installer for BIND, as  
part of the post-processing. It was always there; you just didn't  
notice it.

__

Point 5: Whenever you modify named.conf, before you restart named, run  
named-checkconf over it, just to be sure.


Chris Buxton
Professional Services
Men & Mice

On Feb 6, 2009, at 8:47 AM, Michelle Konzack wrote:


Hello Chris,

thank you for the "HOWTO"... now it is more clear.

OK, there are some stange things happen to my master DNS @home.   
Since I
it seems I had a "nsupdate" from my Laptop,  an  update  from  my   
work-

stations was working perfectly and now it comes:

I have never used:

Am 2009-02-05 16:58:27, schrieb Chris Buxton:

Create a key:

dnssec-keygen -a hmac-md5 -b 512 -n host slave1.key

(Note: Use something better than hmac-md5 if your BIND version  
supports
it.) This creates two files, with similar names. Extract the secret  
from

either of them (it is the same in both) and create a key statement:

key "slave1.key" {
algorithm hmac-md5;
secret "put here the secret from the file";
};


and this installed and was not looking into my local DNS  since   
several

weeks...  Today I have found

1) a modified file
  /etc/bind/net.tamay-dogan.private

2) two new files
  /etc/bind/net.tamay-dogan.private.njl
  /etc/bind/rndc.key

where the last one has the key enty above.

Q: Does the "nsupdate" create/change this files?

Note:  The rndc.key file is not included in any files, hence I
  asume it is not alive and I have to include it into my.
  /etc/bind/named.conf.local (Debian System)

Put this statement into named.conf on both the master server and  
one of

your slaves. Then, put this into the master server's named.conf:

server 192.0.2.1 { // use the actual IP address of the slave here
keys { slave1.key; };
};

On the slave:

server 192.0.2.2 { // this should be the IP address of the master
keys { slave1.key; };
};


OK done.


This will then secure all communication (except forwarded updates)
between master and slave1. That includes notifies, SOA queries and
responses, and zone transfers.

Repeat the above for each slave. Use a different key for each slave.
This means the master will have 5 keys defined (plus an RNDC key,
hopefully), and 5 server statements. You may also want to create
additional keys (and additional server statements) for use between
slaves, just in case you ever need to promote one.


OK, now I have:

key "rndc-key" {
...
};
key "tdnet.key" {
...
};
key "hetzner.key" {
...
};
key "vallendor.key" {
...
};

and 5 entries like

server 192.168.0.194 {
keys { tdnet.key; };
};


Next, create yet another key for dynamic updates. Put that key's name
into your allow-update statement. Turn on update-forwarding on the


Done but...


slaves, like this (in each slave zone):

allow-update-forwarding { any; };


OK done.

Since the master will only permit signed updates, and since the  
slaves
will forward signed updates unmodified (signatures intact), you do  
not

need to secure this ACL.


I have for testing only me second local DNS included and I call the   
key

"tdnet.key" since it is under my own control...

I have now (unneccesary lines striped)

[ '/etc/bind/ 
named.conf' ]--

include "/etc/bind/named.conf.options";

zone "." {
   type hint;
   file "/etc/bind/db.root";
};

zone "localhost" {