Update-Policy ms-self for reverse zone dont work - please help
Hello,
I am running bind 9.8 with GSS-TSIG on a SuSE Enterprise 11 PL 1 Server.
For my forward zones I have the following rules:
zonecp.test {
type master;
file forward/cp.test;
notify yes;
update-policy {
grant MSADC40T$@CP.TEST wildcard * ANY;
grant Key_TEST wildcard * ANY;
grant CP.TEST ms-self * A;
};
};
The last line only allows Microsoft Client to set their A-Record. Works
perfect.
-
Now I try the same for the reverse zone and it should make the client only
to update its PTR-Record.
Example 1:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant Key_TEST wildcard * ANY; --
(Test-Local-Key works)
grant CP.TEST ms-self * PTR; --- DONT
WORK
};
notify yes;
};
Example 2:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant Key_TEST wildcard * ANY;
grant CP.TEST wildcard * PTR; --- DONT
WORK
};
notify yes;
Example 3:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant MSADC40T$@CP.TEST ms-self * PTR; -- DONT
WORK
grant Key_TEST wildcard * ANY;
grant CP.TEST wildcard * PTR; --- DONT
WORK
};
notify yes;
};
Only solution that works is:
grant MSADC40T$@CP.TEST wildcard * PTR;
So it looks like that in reverse zone its only possible to exactly name the
host that should update its own record and only use it with the wildcard
command.
Am i right? Or what am i doing wrong?
Thanx a lot for all your help.
Wish you a nice weekend.
cheers,
Juergen
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9 enum hack
On Jun 22, 2011 4:35 PM, Stefan Certic ste...@routotelecom.com wrote:
zone 4.6.1.8.3.e164enum {
type forward;
forwarders {127.0.0.1 port 5200;};
};
zone e164enum {
type master;
file /etc/bind/enum.conf;
};
...
What i am trying to achieve, is:
- Match everything that begins with 4.6.1.8.3.e164enum and forward query to
remote server.
- But if there is no forward zone defined, respond from enum.conf
Note that the forward will only work for clients that have recursion
allowed.
if i do: dig 4.5.4.6.1.8.3.e164enum NAPTR :
Bind always match query from e164enum zone, and never ask forwarder
althrough 4.6.1.8.3.e164enum is defined.
Any hints how to make bind match zones from left to right?
On Wednesday, June 22, 2011 10:38:31 pm Ben Croswell wrote:
Is the child domain you want to forward delegated in the parent you load?
If it isn't the forward will be ignored.
No, bind does not check if the subdomain is delegated. If it has configured
the domain, BIND provides it.
On 23.06.11 00:50, Stefan Certic wrote:
No, i tried with delegation but got the same results. The thing is that all
child subdomains must match wildcard queries. Im not sure how to delegate
wildcard subdomains.
you can not delegate wildcard.
In the fact, it should work as you did it, unless
- a bug in the BIND
- a bug in your configuration, maybe you have missed something.
Do you use zones? Are you using correct bind server?
Note that if you slave e164enum to another server, the another server
knows NOTHING about 4.6.1.8.3.e164enum, and that's why you SHOULD have the
delegation.
However, since you can not delegate to different port than 53, for these
cases you will need delegate to your bind with forward zone (or maybe
static-stub), therefore clients will need recursion allowed.
--
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.
Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Logging Response Results
Unfortunately not, since billing is per query based, and each zone can have different pricing. Also, results per query are very important for analytical purposes in order to be able to spot problems in case some of forward zones stop wroking and/or provide unacceptable sucess rates. Anyway, i am goiing to try to patch the code to get the results, since query log work perfectly for the first part of process. Thanks for your help. On Friday, June 24, 2011 12:16:09 am Chuck Swiger wrote: On Jun 23, 2011, at 2:28 PM, Stefan Certic wrote: It is Enum server, and logging is taking care of billing process. I don't see why you need to preserve queries and responses, unless you plan to charge differently for different DNS requests. Can't you just track traffic per client using netflow records, firewall counters, etc? Also, it's hard to beat free-- and there are plenty of freely available DNS servers around. Regards, -- Stefan Certic RoutoMessaging 48 Charlotte Street London, W1T 2NS United Kingdom http://www.routomessaging.com GSMA Associate Member Switchboard +44 (0) 870 231 Fax + 44 (0) 870 231 7775 Email : ste...@routotelecom.com MSN ID : ste...@routotelecom.com DISCLAIMER This email contains information provided by Routo Telecommunications Ltd, which may be privileged or confidential. It is meant only for the individual(s) or entity named above. If you are not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you have received this email in error, please let me know immediately on the email address above. Routo Telecommunications Ltd may not be held responsible for the content of this email as it may reflect the personal view of the sender and not that of the company. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. We monitor our email system and may record your emails. Routo Telecommunications Ltd Registration Number 04546322 has its principal place of business at 48 Charlotte Street, London, W1T 2NS, United Kingdom. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Logging Response Results
On Thu, Jun 23, 2011 at 10:27:31PM +0200, Stefan Certic ste...@routotelecom.com wrote a message of 65 lines which said: stored into database (matching the initial query from query log). This may help: http://www.dnsmezzo.net/ We monitor our email system and may record your emails. Don't! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Logging Response Results
On Thu, Jun 23, 2011 at 02:31:22PM -0700, Ray Van Dolson rvandol...@esri.com wrote a message of 37 lines which said: If you're handy with Python, pcapy[1] Quite limited. and impacket[2] No IPv6 support. And, anyway, neither pcapy nor impacket parses the DNS (if you read French, see http://www.bortzmeyer.org/libpcap-python.html). would likely be a more efficient way to parse DNS traffic for query responses than working with tcpdump output natively (unless you're skilled with C). It exists several DNS parsers written in C in free software (I mentionbed one before but there is also dns2db, the one in dnscap, and of course the ones in tcpdump and wireshark, etc) so there is no need to write a C parser from scratch. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Update-Policy ms-self for reverse zone dont work - please help
If I'm not mistaken, ms-self means that the client's hostname must match the
name of the record being updated. This is not the case in the reverse space,
where record names end in in-addr.arpa instead of cp.test.
Your DHCP server should own the reverse space. I don't know how else to manage
this.
Regards,
Chris Buxton
BlueCat Networks
On Jun 24, 2011, at 1:13 AM, Juergen Dietl wrote:
Hello,
I am running bind 9.8 with GSS-TSIG on a SuSE Enterprise 11 PL 1 Server.
For my forward zones I have the following rules:
zonecp.test {
type master;
file forward/cp.test;
notify yes;
update-policy {
grant MSADC40T$@CP.TEST wildcard * ANY;
grant Key_TEST wildcard * ANY;
grant CP.TEST ms-self * A;
};
};
The last line only allows Microsoft Client to set their A-Record. Works
perfect.
-
Now I try the same for the reverse zone and it should make the client only to
update its PTR-Record.
Example 1:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant Key_TEST wildcard * ANY; --
(Test-Local-Key works)
grant CP.TEST ms-self * PTR; --- DONT
WORK
};
notify yes;
};
Example 2:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant Key_TEST wildcard * ANY;
grant CP.TEST wildcard * PTR; --- DONT
WORK
};
notify yes;
Example 3:
zone10.in-addr.arpa {
type master;
file reverse/10.in-addr.arpa;
update-policy {
grant MSADC40T$@CP.TEST ms-self * PTR; -- DONT
WORK
grant Key_TEST wildcard * ANY;
grant CP.TEST wildcard * PTR; --- DONT
WORK
};
notify yes;
};
Only solution that works is:
grant MSADC40T$@CP.TEST wildcard * PTR;
So it looks like that in reverse zone its only possible to exactly name the
host that should update its own record and only use it with the wildcard
command.
Am i right? Or what am i doing wrong?
Thanx a lot for all your help.
Wish you a nice weekend.
cheers,
Juergen
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind restart needed to reflect changes to dynamic zone in multiple views
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic update to a common
zone, only the internal view sees that change. External queries still
return the data prior to the update. If I restart the server, then
external queries get the updated data.
To provide an (excerpted, for brevity) example...
zones.common
zone rbl.interlinx.bc.ca {
type master;
file /etc/bind/master/rbl.interlinx.bc.ca.zone;
allow-update { ... };
allow-transfer { ... };
allow-query { any; };
};
zones.common
named.conf
view trusted {
match-clients { trusted_networks; }; // our internal networks
...
include /etc/bind/zones.common;
...
zone interlinx.bc.ca {
type master;
file /etc/bind/master/interlinx.bc.ca.zone;
allow-update { ... };
allow-query { ... };
allow-transfer { ... };
};
...
};
view greatunwashed {
match-clients { any; }; // all others hosts
...
include /etc/bind/zones.common;
allow-query { great_unwashed_allowed_query; };
zone interlinx.bc.ca {
type slave;
file /etc/bind/slave/interlinx.bc.ca.zone;
masters { ... };
allow-query { any; };
};
};
named.conf
To demonstrate, given the above configuration:
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca. not found: 3(NXDOMAIN)
dns_server $ nsupdate
server localhost
zone rbl.interlinx.bc.ca.
update add 1.2.3.4.rbl.interlinx.bc.ca 60 A 127.0.0.2
send
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # /usr/sbin/rndc reload
server reload successful
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # service bind9 restart
* Stopping domain name service... bind9
...done.
* Starting domain name service... bind9
...done.
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
As you can see, it took a complete server restart for the greatunwashed
view to get the zone update.
Is this expected behavior or a (known?) bug?
Cheers,
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/11 08:22, Brian J. Murrell wrote:
I am using BIND 9.7.2-P2.
I have two views, one internal and one for external queries. In
both of those views I have some zones which are common so I put them
into their own file zones.common and include that file in both of the
views.
The problem I am having is that when I make a dynamic update to a common
zone, only the internal view sees that change. External queries still
return the data prior to the update. If I restart the server, then
external queries get the updated data.
To provide an (excerpted, for brevity) example...
zones.common
zone rbl.interlinx.bc.ca {
type master;
file /etc/bind/master/rbl.interlinx.bc.ca.zone;
allow-update { ... };
allow-transfer { ... };
allow-query { any; };
};
zones.common
named.conf
view trusted {
match-clients { trusted_networks; }; // our internal networks
...
include /etc/bind/zones.common;
...
zone interlinx.bc.ca {
type master;
file /etc/bind/master/interlinx.bc.ca.zone;
allow-update { ... };
allow-query { ... };
allow-transfer { ... };
};
...
};
view greatunwashed {
match-clients { any; }; // all others hosts
...
include /etc/bind/zones.common;
allow-query { great_unwashed_allowed_query; };
zone interlinx.bc.ca {
type slave;
file /etc/bind/slave/interlinx.bc.ca.zone;
masters { ... };
allow-query { any; };
};
};
named.conf
To demonstrate, given the above configuration:
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca. not found: 3(NXDOMAIN)
dns_server $ nsupdate
server localhost
zone rbl.interlinx.bc.ca.
update add 1.2.3.4.rbl.interlinx.bc.ca 60 A 127.0.0.2
send
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # /usr/sbin/rndc reload
server reload successful
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
Host 1.2.3.4.rbl.interlinx.bc.ca not found: 3(NXDOMAIN)
dns_server # service bind9 restart
* Stopping domain name service... bind9
...done.
* Starting domain name service... bind9
...done.
trusted_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
greatunwashed_host $ host 1.2.3.4.rbl.interlinx.bc.ca.
1.2.3.4.rbl.interlinx.bc.ca has address 127.0.0.2
As you can see, it took a complete server restart for the greatunwashed
view to get the zone update.
Is this expected behavior or a (known?) bug?
Cheers,
b.
It's expected behavior in a way. You are probably making this change in
the internal view and the internal named process knows about the change
and reloads the zone.
The external view's process is unaware of the change and does not reload.
1) You could send a periodic rndc reload to the external view process.
2) Since this appears to be an rbl zone, use rbldnsd instead of named to
serve this zone. Rbldnsd has code in it to auto-detect a change in the
zone file and will auto-reload. Rbldnsd is a tighter piece of code
designed not to be a general purpose piece of software, but a
specialized service. It takes fewer system resources for this purpose.
FYI, I have an internal rbl that I use here. I store the zone data in a
postgres sql database and do the updates to it there. The two hosts
that serve the data run rbldnsd. I have written perl scripts to
periodicly pull a copy of the database and parse that into text files
compatible with rbldnsd and move them into place. rbldnsd automagically
reloads the updated zone files.
Lyle Giese
LCR Computer Services, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 24/06/11 14:22, Brian J. Murrell wrote: I am using BIND 9.7.2-P2. I have two views, one internal and one for external queries. In both of those views I have some zones which are common so I put them into their own file zones.common and include that file in both of the views. The problem I am having is that when I make a dynamic update to a common zone, only the internal view sees that change. External queries still return the data prior to the update. If I restart the server, then external queries get the updated data. That's not supported. You will need to transfer the zone from the the internal view to the external view, and store them in different files. This kind of things gets discussed on the list often - you can find more info in the archives. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: bind restart needed to reflect changes to dynamic zone in multipleviews
I wonder if pointing to different file names with one being a symbolic link to the other would work? That way you'd only have to create and update the one file but the transfer would transfer two separate files. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Brian J. Murrell Sent: Friday, June 24, 2011 10:21 AM To: bind-us...@isc.org Subject: Re: bind restart needed to reflect changes to dynamic zone in multipleviews On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. Proud partner. Susan G. Komen for the Cure. 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. -- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/11 09:21, Brian J. Murrell wrote: On 11-06-24 09:57 AM, Lyle Giese wrote: It's expected behavior in a way. Given your explanation, indeed. :-) You are probably making this change in the internal view and the internal named process knows about the change and reloads the zone. The external view's process is unaware of the change and does not reload. A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. 1) You could send a periodic rndc reload to the external view process. Except that I only have the one process. Any thoughts on how to do this in such a case? 2) Since this appears to be an rbl zone, use rbldnsd instead of named to serve this zone. Yeah, I suppose I could. It would solve this specific use case, but I don't know that this RBL zone is the extent of this problem. I'd have to examine further where there are zones shared by multiple views. I'm guessing though that rbldnsd doesn't support remote update, yes? That would be limiting for my purposes here. Cheers, b. rbldnsd does not support dynamic updates like bind. But there is no reason you can not create a script in any language to update the zone file. When rbldnsd detects that the zone file has been changed, it auto reloads it. In my situation, when I place a new zone file in place, rbldnsd auto loads the new one. Lyle ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
A. I guess I had not considered how BIND handles views and that it's done with a separate process per view. But I only have one named process, so I suppose it's threading for each view. No, the views will all share the same process and thread(s), but they are separate chunks of memory, and simulate being separate servers. Except that I only have the one process. Any thoughts on how to do this in such a case? You can specify the view in the reload command: $ rndc reload example.com in external You can also configure the zone in one view as a master and the one in the other view as a slave; then reloading the master will automatically send a notify to the slave. This involves tsig keys and is kind of fiddly, but works quite well (I run several zones that way on my home server). -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 12:39 PM, Evan Hunt wrote: You can specify the view in the reload command: $ rndc reload example.com in external But reload doesn't work for dynamic zones: # rndc reload rbl.interlinx.bc.ca in greatunwashed rndc: 'reload' failed: dynamic zone and since I want the same zone definition file to be included in both views, I can't (without separating and mostly duplicating) easily do that. I don't think I can even point a non-dynamic zone definition at a dynamic zone file because of the journal and all that, right? You can also configure the zone in one view as a master and the one in the other view as a slave; then reloading the master will automatically send a notify to the slave. Yeah, so I've been hearing about. I suppose in this case I am creating separate definitions for the zones also. :-( This all seems like a pretty serious deficiency in BIND9. That it exists I suppose attests to the difficulty in fixing it though. :-( Cheers, b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Better solution than making a recursive nameserver authoritative?
Currently the two recursive caching nameservers for clients on our network are also authoritative for a few zones. In particular, they are authoritative for: 1) our main forward zone (columbia.edu) in order to provide an internal view of the zone 2) RFC 1918 reverse zones (e.g., 10.in-addr.arpa) I would like to follow best practices by separating authoritative recursive functionality. Also, when I sign these zones, I would like the recursive nameservers to respond with the AD bit set instead of AA. But I'm struggling to find a way to do this with some of the constraints I'm facing: a) I can't move the internal-only RRs into a separate subdomain/zone b) Some of our authoritative secondaries are provided by other institutions that I cannot expect to configure views c) The zones include delegations for subdomains to other nameservers One solution suggested to me is to have our clients point to nameservers that are authoritative for the internal zones forward all other queries to a new pair of recursive-only caching nameservers. Is this actually better/more secure than our current setup to justify the additional hardware? Also, as best I can tell, when the clients query for data in the internal zones they would still receive responses with the AA bit set instead of the AD bit. I've also considered configuring the internal zones as type forward on the recursive nameservers forwarding to authoritative-only nameservers for the internal zones. The concern I have with this is if I configure a zone on the authoritative nameserver with a delegation to another set of nameservers. If the forward zone on the recursive nameserver is configured with forward only, it will only get the delegation NS RRset therefore returns a SERVFAIL. If I configure the zone as forward first, the recursive nameserver gets back the NS delegation then uses that to perform an iterative query against the authoritative nameserver for the subdomain. This actually seems like it might solve my issues. Are there any problems with this setup I'm not seeing (other than the quirk of sending a recursive query to the forwarder when it is authoritative only)? There have been a few other, slightly crazier, ideas I've thought of or have been suggested to me. But I figured I would start with these as they are likely the simplest. However, other recommended solutions are always appreciated. Thanks, Dave C. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
But reload doesn't work for dynamic zones:
Do the internal and external versions *both* need to be dynamic?
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
The master/slave approach really works better, though. Something like
this:
view internal {
match-clients { !key example-key; localnets; };
zone example.com {
type slave;
masters { localhost key example-key; }
};
};
view external {
match-clients { any; };
zone example.com {
type master;
file filename;
update-policy { grant example-key zonesub ANY; };
also-notify { 127.0.0.1; };
};
};
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 01:47 PM, Evan Hunt wrote:
Do the internal and external versions *both* need to be dynamic?
No, only the internal in fact.
I'd expect it to work okay if you had only one of them dynamic, and
sent periodic reload commands to the other one.
Yeah. I got the master/slave approach working with your suggestion
below as a model. I reversed the master/slave relationship however to
reflect that changes come from internal only.
I guess it's hoping for too much though to have the master sent notifies
to the slave given that master and slave are both on the same host, yes?
Hence your suggestion of periodic reload commands?
The data really does need to be quite in sync though. I'm not sure a
period of less than a second or two is going to be acceptable. :-(
The master/slave approach really works better, though. Something like
this:
view internal {
match-clients { !key example-key; localnets; };
zone example.com {
type slave;
masters { localhost key example-key; }
};
};
view external {
match-clients { any; };
zone example.com {
type master;
file filename;
update-policy { grant example-key zonesub ANY; };
also-notify { 127.0.0.1; };
};
};
Cheers, and thanx much for all of that.
b.
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Better solution than making a recursive nameserver authoritative?
On 06/24/2011 10:39, David Coulthart wrote: Currently the two recursive caching nameservers for clients on our network are also authoritative for a few zones. In particular, they are authoritative for: 1) our main forward zone (columbia.edu) in order to provide an internal view of the zone 2) RFC 1918 reverse zones (e.g., 10.in-addr.arpa) I would like to follow best practices by separating authoritative recursive functionality. TMK that concept applies to authoritative servers queried by _others_ (i.e., listed in NS records). I have always configured my internal resolvers in the manner you describe, and have never had any problems with it. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 6/24/2011 2:51 PM, Brian J. Murrell wrote: The data really does need to be quite in sync though. I'm not sure a period of less than a second or two is going to be acceptable.:-( Do you have control of the update process. You could potentially send and update to both views (in other words, send two updates). I think you'd need separate zone files on the server, too. -- Dave ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
EDNS request problem on TTL=0 data
Hi, I'm investigating an outage that happened on a bind server. It was configured as a caching resolving name server. It was forwarding for one specific zone. This zone had two nameservers/forwarders of which one at some point was unreachable due to a cable cut. The other nameserver turned out to be dropping any requests with the DO bit set. What seems to have happened is: 1 the bind nameserver would send 3 queries 1s apart with ENDS0+DO bit, which were dropped. 2 bind sends out a query without the DO bit, it gets a response with TTL=0 3 a burst of queued up queries for that exact query gets rushed through for 1s (prob not more then max-clients-per-query though, which was set at 100) 4 goto 1 This not only caused resolving failures for the forwarding data, but within the hour caused the entire server to collapse under load. The number of clients asking for this data was higher then the max-clients-per-query setting. My questions: 1 Is this problem happening because EDNS failure is not remembered for forwarders? 2 Is this problem happening because EDNS failure is forgotten once there is no more data cached that used the specified nameserver? 3 Does max-clients-per-query apply to forward zone queries too, or is this ignored? 4 Can this behaviour be changed via a configuration option so we can remember this EDNS failure so that we're not unable to anser queries for 3 out of 4 seconds? Paul ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Better solution than making a recursive nameserver authoritative?
On 06/24/2011 06:39 PM, David Coulthart wrote:
configure the zone as forward first, the recursive nameserver gets
back the NS delegation then uses that to perform an iterative query
against the authoritative nameserver for the subdomain. This
actually seems like it might solve my issues. Are there any problems
with this setup I'm not seeing (other than the quirk of sending a
recursive query to the forwarder when it is authoritative only)?
forward first is the wrong tool; if the upstream nameservers are down
(or fail to answer) it'll go to the internet, which you don't want.
static-stub, introduced in bind 9.8 are what you want (see below)
There have been a few other, slightly crazier, ideas I've thought of
or have been suggested to me. But I figured I would start with these
as they are likely the simplest. However, other recommended
solutions are always appreciated.
type static-stub. These are designed for this purpose - they send
non-recursive queries to the server-{addresses,names} you define, and
will honour delegations, as opposed to forward zones that send recursive
queries and expect a full reply.
I didn't really understand why you needed or thought you needed views,
so if you can expand, possibly people can give you a fuller answer.
Cheers,
Phil
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: EDNS request problem on TTL=0 data
Hi Paul, Which version of named are you running? You've likely run into an issue that we've seen before - basically, as you have surmised, your server has to retry each query and never gets a response regarding edns (so it can't remember). Let me know which version you are running and I'll get back to you regarding the availability of a fix. You can mitigate this issue by using edns-udp-size 512 in the appropriate server clause or use edns no to turn off edns altogether. Thanks, -Scott On 06/24/2011 01:22 PM, Paul Wouters wrote: Hi, I'm investigating an outage that happened on a bind server. It was configured as a caching resolving name server. It was forwarding for one specific zone. This zone had two nameservers/forwarders of which one at some point was unreachable due to a cable cut. The other nameserver turned out to be dropping any requests with the DO bit set. What seems to have happened is: 1 the bind nameserver would send 3 queries 1s apart with ENDS0+DO bit, which were dropped. 2 bind sends out a query without the DO bit, it gets a response with TTL=0 3 a burst of queued up queries for that exact query gets rushed through for 1s (prob not more then max-clients-per-query though, which was set at 100) 4 goto 1 This not only caused resolving failures for the forwarding data, but within the hour caused the entire server to collapse under load. The number of clients asking for this data was higher then the max-clients-per-query setting. My questions: 1 Is this problem happening because EDNS failure is not remembered for forwarders? 2 Is this problem happening because EDNS failure is forgotten once there is no more data cached that used the specified nameserver? 3 Does max-clients-per-query apply to forward zone queries too, or is this ignored? 4 Can this behaviour be changed via a configuration option so we can remember this EDNS failure so that we're not unable to anser queries for 3 out of 4 seconds? Paul ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 11-06-24 03:19 PM, David Sparro wrote: Do you have control of the update process. Sure. You could potentially send and update to both views (in other words, send two updates). How do I, with nsupdate, specify which view's zone I want to update? I think you'd need separate zone files on the server, too. Sure, that's not hard. The hard (or rather, unknown) part is how to tell nsupdate which view to interact with? b. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind restart needed to reflect changes to dynamic zone in multiple views
On 06/24/2011 10:47 PM, Brian J. Murrell wrote:
On 11-06-24 03:19 PM, David Sparro wrote:
Do you have control of the update process.
Sure.
You could potentially send
and update to both views (in other words, send two updates).
How do I, with nsupdate, specify which view's zone I want to update?
Use two separate TSIG keys to secure the updates (-y argument to
nsupdate). Set match-clients { key xxx; } in the view.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
