Query Refused problem

[Sven Eschenberg]

Dear list,

I have one client with a specific zone. When the client does a query for 
localhost on the nameserver, or a reverse lookup for 127.0.0.1, 
everything seems perfectly okay. As soon, as the client tries to lookup 
i.e. google.de or any external ip, I am getting query refused errors.


Sep 30 14:21:40 gw named[28715]: client #1039: 
view watchdog: query (cache) 'www.google.de/A/IN' denied
Sep 30 14:21:40 gw named[28715]: client #1040: 
view watchdog: query (cache) 'www.google.de/A/IN' denied


The DNS-Server works as a recursor for the client.

What puzzles me most is: I cloned another internal view, which works 
perfectly well for the clients matched by it.


What might I be missing here, what can trigger a query refused answer 
like this?


Regards

-Sven


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

Re: Query Refused problem

[Sven Eschenberg]

I got it fixxed with an allow-query statement.

But this arises another question: Does bind implicitly add allow-queries 
for locally attached interfaces and the networks configured for these?


I am asking, because it used to work for all the subnets directly 
attached to the machine.


Regards

-Sven

Sven Eschenberg schrieb:

Dear list,

I have one client with a specific zone. When the client does a query for 
localhost on the nameserver, or a reverse lookup for 127.0.0.1, 
everything seems perfectly okay. As soon, as the client tries to lookup 
i.e. google.de or any external ip, I am getting query refused errors.


Sep 30 14:21:40 gw named[28715]: client #1039: 
view watchdog: query (cache) 'www.google.de/A/IN' denied
Sep 30 14:21:40 gw named[28715]: client #1040: 
view watchdog: query (cache) 'www.google.de/A/IN' denied


The DNS-Server works as a recursor for the client.

What puzzles me most is: I cloned another internal view, which works 
perfectly well for the clients matched by it.


What might I be missing here, what can trigger a query refused answer 
like this?


Regards

-Sven


___
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: DHCP3-Server doesn't request a zone update

[Holger Honert]

Hi Markus,

check the dhcpd.log for the following messages:

I.e.

adding:

Sep 30 15:13:06 ns1 dhcpd: Added new forward map from
172-17-111-249.example.net to 172.17.111.2
49
Sep 30 15:13:06 ns1 dhcpd: added reverse map from
249.111.17.172.in-addr.arpa. to 172-17-111-249.
example.net


removing:

Sep 30 15:20:04 ns1 dhcpd: if NB4711.example.net. IN TXT
"315bd896018c77e02f3f9f43a6fb4e5fe1
" rrset exists and NB4711.example.net. IN A 172.27.13.158 rrset exists
delete NB4711.example.net. IN A 172.27.13.158: success.
Sep 30 15:20:04 ns1 dhcpd: if NB4711.example.net. IN A rrset doesn't
exist delete NB4711
.example.net. IN TXT "315bd896018c77e02f3f9f43a6fb4e5fe1": success.
Sep 30 15:20:04 ns1 dhcpd: removed reverse map on
158.13.27.172.in-addr.arpa.


And depending on your logging of the DNS-Server the corresponding entries:

30-Sep-2009 15:13:06.111 update: info: client 172.17.111.16#58580:
updating zone 'example.net/IN': update unsuccessful:
172-17-111-249.example.net: 'name not in use' prerequisite not satisfied
(YXDOMAIN)
30-Sep-2009 15:13:06.131 update: info: client 172.17.111.16#58581:
updating zone 'example.net/IN': deleting rrset at
'172-17-111-249.example.net' A

Where the 172.17.111.16 is the address of the dhcp-server


Regards

Holger


Markus Feldmann schrieb:
> How can i check whether or not my DHCP Server tries to update my zone
> ifrom my DNS Server ?
>
> regards Markus
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>


SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
<>___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Query Refused problem

[Sven Eschenberg]

Dear list,

This seems more tricky, then I thought.

When I had no allow-query statement at all in my config, everything 
worked find (includign recursion) for all clients, that were in subnets 
directly attached to the server. The external view (authoriative, non 
recursive) did work for every client as supposed to.
Now a client on a not directly attached subnet, with it's own view, 
could not resolve anything, except local zones on the server. (Though 
recursion was turned on for the view).
External view's clients could nto recurse, though recursion was turned 
on, obviously to realyl recurse I'd need an allow-query statement.


Adding an allow-query statement to the general config, limitied to the 
campus network made all local views work, but with the result, that no 
client matching the external view could looks up the authoriative zones.


Now, I am wondering if I did set uop everything right afterall, here's 
what I did do:


External view, no recursion, allow-query {any;}
Not directly attached client with internal view: match on client's ip, 
allow recursion, allow query for the client's ip.
all other internal views, matched by locally attached netowrks, no 
allow-query statement, allow recursion.


This seems to work.

I am wondering: Would it be harmfull to allow queries by any host 
(globally) as long as external clients (in their view) are not allowed 
any recursion? Would that be more feasible?


Regards

-Sven


Sven Eschenberg schrieb:

I got it fixxed with an allow-query statement.

But this arises another question: Does bind implicitly add allow-queries 
for locally attached interfaces and the networks configured for these?


I am asking, because it used to work for all the subnets directly 
attached to the machine.


Regards

-Sven

Sven Eschenberg schrieb:

Dear list,

I have one client with a specific zone. When the client does a query 
for localhost on the nameserver, or a reverse lookup for 127.0.0.1, 
everything seems perfectly okay. As soon, as the client tries to 
lookup i.e. google.de or any external ip, I am getting query refused 
errors.


Sep 30 14:21:40 gw named[28715]: client #1039: 
view watchdog: query (cache) 'www.google.de/A/IN' denied
Sep 30 14:21:40 gw named[28715]: client #1040: 
view watchdog: query (cache) 'www.google.de/A/IN' denied


The DNS-Server works as a recursor for the client.

What puzzles me most is: I cloned another internal view, which works 
perfectly well for the clients matched by it.


What might I be missing here, what can trigger a query refused answer 
like this?


Regards

-Sven


___
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


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

Re: DNSSEC

[Chris Thompson]

On Sep 30 2009, Mark Andrews wrote:


In message ,
Chris Thompson writes:

DNSSEC certainly adds to the aggravation of having lots of piddling little
reverse zones. Some people may just decide not to bother signing reverse
zones ("reverse lookup results should only be treated as a hint, anyway").


DNSSEC makes no difference to the count of reverse zones unless you
are depending on the nameserver filtering out records that shouldn't
be loaded into a zone.


Of course it doesn't affect the number of reverse zones. But if you already
have more of them than you want, managing keys for each of them is that much
extra hassle.

But maybe BIND 9.7 will make key management such a doddle that we won't care ...

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

FW: Blocking top level domain

[Apisa, Kathy (US - MABS)]

 



From: Apisa, Kathy (US - MABS) 
Sent: Wednesday, September 30, 2009 10:23 AM
To: 'bind-users@lists.isc.org'
Subject: Blocking top level domain

 

Greetings everyone

 

I would like to know how to implement the blocking of a top level domain
in Bind 9

 

For example, I want to block access to any domain that ends in .cn

 

 

Thanks,

Kathy Apisa



Information Technology

330-796-5963 

kathy.ap...@meggitt.com

 



This email may contain proprietary information and/or copyright
material. This email is intended for the use of the addressee only.
Any unauthorized use may be unlawful. If you receive this email by
mistake, please advise the sender immediately by using the reply
facility in your email software.

Information contained in and/or attached to this document may be
subject to export control regulations of the European Community, USA,
or other countries. Each recipient of this document is responsible to
ensure that usage and/or transfer of any information contained in
this document complies with all relevant export control regulations.
If you are in any doubt about the export control restrictions that
apply to this information, please contact the sender immediately.

Be aware that Meggitt may monitor incoming and outgoing emails to
ensure compliance with the Meggitt IT User policy.

This transmittal and any attached documents may contain technical
data, the use of which may be restricted by the U.S. Arms Export
Control Act and/or the Export Administration Act.  By accepting such
data, the recipient agrees to comply with the International Traffic
in Arms Regulations (ITAR) and/or the Export Administration
Regulations, as applicable.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: FW: Blocking top level domain

[Kevin Darcy]

Define "block".

Return "query refused"?

Return "name does not exist"?

Return a wildcard entry pointing to a "helpful" web page, explaining why 
you don't like Chinese domains?


Whatever you're trying to do, it's probably better done in a proxy, than 
in DNS.



 - Kevin


Apisa, Kathy (US - MABS) wrote:


 




*From:* Apisa, Kathy (US - MABS)
*Sent:* Wednesday, September 30, 2009 10:23 AM
*To:* 'bind-users@lists.isc.org'
*Subject:* Blocking top level domain

 


Greetings everyone

 

I would like to know how to implement the blocking of a top level 
domain in Bind 9


 


For example, I want to block access to any domain that ends in .cn

 

 


Thanks,

Kathy Apisa



Information Technology

330-796-5963

kathy.ap...@meggitt.com 

 



This email may contain proprietary information and/or copyright 
material. This email is intended for the use of the addressee only. 
Any unauthorized use may be unlawful. If you receive this email by 
mistake, please advise the sender immediately by using the reply 
facility in your email software.


Information contained in and/or attached to this document may be 
subject to export control regulations of the European Community, USA, 
or other countries. Each recipient of this document is responsible to 
ensure that usage and/or transfer of any information contained in this 
document complies with all relevant export control regulations. If you 
are in any doubt about the export control restrictions that apply to 
this information, please contact the sender immediately.


Be aware that Meggitt may monitor incoming and outgoing emails to 
ensure compliance with the Meggitt IT User policy.


This transmittal and any attached documents may contain technical 
data, the use of which may be restricted by the U.S. Arms Export 
Control Act and/or the Export Administration Act. By accepting such 
data, the recipient agrees to comply with the International Traffic in 
Arms Regulations (ITAR) and/or the Export Administration Regulations, 
as applicable.




___
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: FW: Blocking top level domain

[Trey Darley]

Hi, Kathy -

Put a firewall in front of your DNS server.

:-)

Cheers,
--Trey

>
>
> 
>
> From: Apisa, Kathy (US - MABS)
> Sent: Wednesday, September 30, 2009 10:23 AM
> To: 'bind-users@lists.isc.org'
> Subject: Blocking top level domain
>
>
>
> Greetings everyone
>
>
>
> I would like to know how to implement the blocking of a top level domain
> in Bind 9
>
>
>
> For example, I want to block access to any domain that ends in .cn
>
>
>
>
>
> Thanks,
>
> Kathy Apisa
>
> 
>
> Information Technology
>
> 330-796-5963
>
> kathy.ap...@meggitt.com
>
>
>
>
>
> This email may contain proprietary information and/or copyright
> material. This email is intended for the use of the addressee only.
> Any unauthorized use may be unlawful. If you receive this email by
> mistake, please advise the sender immediately by using the reply
> facility in your email software.
>
> Information contained in and/or attached to this document may be
> subject to export control regulations of the European Community, USA,
> or other countries. Each recipient of this document is responsible to
> ensure that usage and/or transfer of any information contained in
> this document complies with all relevant export control regulations.
> If you are in any doubt about the export control restrictions that
> apply to this information, please contact the sender immediately.
>
> Be aware that Meggitt may monitor incoming and outgoing emails to
> ensure compliance with the Meggitt IT User policy.
>
> This transmittal and any attached documents may contain technical
> data, the use of which may be restricted by the U.S. Arms Export
> Control Act and/or the Export Administration Act.  By accepting such
> data, the recipient agrees to comply with the International Traffic
> in Arms Regulations (ITAR) and/or the Export Administration
> Regulations, as applicable.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


++-++
Trey Darley - Brussels
++-++
"Svensson," I say, "kindly remember this most banal of truisms: the most
incredible comedies are written by life."
"My life is more like a railway timetable."
"Just wait till time intervenes. The alchemy of time transforms everything
into comedy. Everything..."
[J. Skvorecky, The Engineer of Human Souls]
++-++


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

Re: FW: Blocking top level domain

[Ben Croswell]

Easiest way would probably be to load the .cn domain and just not put
anything in it.


On Wed, Sep 30, 2009 at 11:12 AM, Apisa, Kathy (US - MABS) <
kathy.ap...@meggitt.com> wrote:

>
>   --
>
> *From:* Apisa, Kathy (US - MABS)
> *Sent:* Wednesday, September 30, 2009 10:23 AM
> *To:* 'bind-users@lists.isc.org'
> *Subject:* Blocking top level domain
>
>
>
> Greetings everyone
>
>
>
> I would like to know how to implement the blocking of a top level domain in
> Bind 9
>
>
>
> For example, I want to block access to any domain that ends in .cn
>
>
>
>
>
> Thanks,
>
> Kathy Apisa
>
> 
>
> Information Technology
>
> 330-796-5963
>
> kathy.ap...@meggitt.com
>
>
>
> This email may contain proprietary information and/or copyright material.
> This email is intended for the use of the addressee only. Any unauthorized
> use may be unlawful. If you receive this email by mistake, please advise the
> sender immediately by using the reply facility in your email software.
>
> Information contained in and/or attached to this document may be subject to
> export control regulations of the European Community, USA, or other
> countries. Each recipient of this document is responsible to ensure that
> usage and/or transfer of any information contained in this document complies
> with all relevant export control regulations. If you are in any doubt about
> the export control restrictions that apply to this information, please
> contact the sender immediately.
>
> Be aware that Meggitt may monitor incoming and outgoing emails to ensure
> compliance with the Meggitt IT User policy.
>
> This transmittal and any attached documents may contain technical data, the
> use of which may be restricted by the U.S. Arms Export Control Act and/or
> the Export Administration Act. By accepting such data, the recipient agrees
> to comply with the International Traffic in Arms Regulations (ITAR) and/or
> the Export Administration Regulations, as applicable.
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



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

Zone File Permission Question

[Jim Williams]

Hello,
 
I have what seems to be a very basic question that I have been unable to find 
an answer for. What determines the settings of the file permissions (and how 
can I change those default settings) on zone files created during a zone 
transfer, BIND or the OS (Solaris)? 
 
thanks - jw




Hotmail® has ever-growing storage! Don’t worry about storage limits. Check it 
out.
  
_
Insert movie times and more without leaving Hotmail®.
http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=TXT_TAGLM_WL_HM_Tutorial_QuickAdd_062009___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

update-policy restricting to a subnet

[Nicholas F Miller]

Is it possible to restrict user machines to only be able to update  
their 'A' records on a specific subnet? We would like to allow DDNS  
but restrict it to specific subnets and only allow the machines to  
update their 'A' records. Allow-updates will not get us the record  
restrictions we would need to implement this and it doesn't appear  
that update-policy has any understanding of subnet scoping.

_
Nicholas Miller, ITS, University of Colorado at Boulder



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

socket is not connected error on bind 9.5.1-P3

[Louis Luciano (qipman)]

Greetings.

 

Does anyone know what might be causing these messages?

 

30-Sep-2009 08:20:56.071 client 10.10.10.10#44554: transfer of
'domain.com/IN': send: socket is not connected

 

Thanks,

Lou

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

Re: Query Refused problem

[Mark Andrews]

Have you read the documentation that describes what allow-query does?


  allow-query
  

  Specifies which hosts are allowed to ask ordinary
  DNS questions. allow-query may
  also be specified in the zone
  statement, in which case it overrides the
  options allow-query statement.
  If not specified, the default is to allow queries
  from all hosts.


  
allow-query-cache is now
used to specify access to the cache.
  

  



  allow-query-cache
  

  Specifies which hosts are allowed to get answers
  from the cache.  If allow-query-cache
  is not set then allow-recursion
  is used if set, otherwise allow-query
  is used if set unless recursion no; is
  set in which case none; is used,
  otherwise the default (localnets;
  localhost;) is used.

  


Mark

In message <4ac36444.9000...@whgl.uni-frankfurt.de>, Sven Eschenberg writes:
> Dear list,
> 
> This seems more tricky, then I thought.
> 
> When I had no allow-query statement at all in my config, everything 
> worked find (includign recursion) for all clients, that were in subnets 
> directly attached to the server. The external view (authoriative, non 
> recursive) did work for every client as supposed to.
> Now a client on a not directly attached subnet, with it's own view, 
> could not resolve anything, except local zones on the server. (Though 
> recursion was turned on for the view).
> External view's clients could nto recurse, though recursion was turned 
> on, obviously to realyl recurse I'd need an allow-query statement.
> 
> Adding an allow-query statement to the general config, limitied to the 
> campus network made all local views work, but with the result, that no 
> client matching the external view could looks up the authoriative zones.
> 
> Now, I am wondering if I did set uop everything right afterall, here's 
> what I did do:
> 
> External view, no recursion, allow-query {any;}
> Not directly attached client with internal view: match on client's ip, 
> allow recursion, allow query for the client's ip.
> all other internal views, matched by locally attached netowrks, no 
> allow-query statement, allow recursion.
> 
> This seems to work.
> 
> I am wondering: Would it be harmfull to allow queries by any host 
> (globally) as long as external clients (in their view) are not allowed 
> any recursion? Would that be more feasible?
> 
> Regards
> 
> -Sven
> 
> 
> Sven Eschenberg schrieb:
> > I got it fixxed with an allow-query statement.
> > 
> > But this arises another question: Does bind implicitly add allow-queries 
> > for locally attached interfaces and the networks configured for these?
> > 
> > I am asking, because it used to work for all the subnets directly 
> > attached to the machine.
> > 
> > Regards
> > 
> > -Sven
> > 
> > Sven Eschenberg schrieb:
> >> Dear list,
> >>
> >> I have one client with a specific zone. When the client does a query 
> >> for localhost on the nameserver, or a reverse lookup for 127.0.0.1, 
> >> everything seems perfectly okay. As soon, as the client tries to 
> >> lookup i.e. google.de or any external ip, I am getting query refused 
> >> errors.
> >>
> >> Sep 30 14:21:40 gw named[28715]: client #1039: 
> >> view watchdog: query (cache) 'www.google.de/A/IN' denied
> >> Sep 30 14:21:40 gw named[28715]: client #1040: 
> >> view watchdog: query (cache) 'www.google.de/A/IN' denied
> >>
> >> The DNS-Server works as a recursor for the client.
> >>
> >> What puzzles me most is: I cloned another internal view, which works 
> >> perfectly well for the clients matched by it.
> >>
> >> What might I be missing here, what can trigger a query refused answer 
> >> like this?
> >>
> >> Regards
> >>
> >> -Sven
> >>
> >>
> >> ___
> >> 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
> 
> ___
> 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: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC

[Mark Andrews]

In message , Chris Thomp
son writes:
> On Sep 30 2009, Mark Andrews wrote:
> 
> >In message ,
> > Chris Thompson writes:
> >> DNSSEC certainly adds to the aggravation of having lots of piddling little
> >> reverse zones. Some people may just decide not to bother signing reverse
> >> zones ("reverse lookup results should only be treated as a hint, anyway").
> >
> >DNSSEC makes no difference to the count of reverse zones unless you
> >are depending on the nameserver filtering out records that shouldn't
> >be loaded into a zone.
> 
> Of course it doesn't affect the number of reverse zones. But if you already
> have more of them than you want, managing keys for each of them is that much
> extra hassle.
> 
> But maybe BIND 9.7 will make key management such a doddle that we won't care .
> ..

People, not just ISC, are working on trying to automate delegation
management which is crying out to be automated and would be simple
to do via UPDATE except for stupid contracts between registries and
registrars which make some registries think that they can't accept
UPDATEs.  The contracts really just need to be re-written to allow
this.  This is really the tail wagging the dog at the moment.
 
> -- 
> Chris Thompson
> Email: c...@cam.ac.uk
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Zone File Permission Question

[Mark Andrews]

In message , Jim Williams writes:
> Hello=2C
> =20
> I have what seems to be a very basic question that I have been unable to fi=
> nd an answer for. What determines the settings of the file permissions (and=
>  how can I change those default settings) on zone files created during a zo=
> ne transfer=2C BIND or the OS (Solaris)?=20
> =20
> thanks - jw

As with any other process the umask() is used.
 
> Hotmail=AE has ever-growing storage! Don=92t worry about storage limits. Ch=
> eck it out.
> =0A=
> _=0A=
> Insert movie times and more without leaving Hotmail=AE.=0A=
> http://windowslive.com/Tutorial/Hotmail/QuickAdd?ocid=3DTXT_TAGLM_WL_HM_Tut=
> orial_QuickAdd_062009=
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Zone File Permission Question

[Joseph S D Yao]

On Wed, Sep 30, 2009 at 01:12:17PM -0400, Jim Williams wrote:
...
> I have what seems to be a very basic question that I have been unable to find 
> an answer for. What determines the settings of the file permissions (and how 
> can I change those default settings) on zone files created during a zone 
> transfer, BIND or the OS (Solaris)? 
>  
...


Try adding 'umask 027' - or whatever you desire - to the shell command
file that kicks off 'named', which is often /etc/init.d/named or
/etc/init.d/bind, depending on who installed it.  ;-)  Put the call to
'umask' immediately before the execution of 'named'.


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users