Re: About root zones
2011/12/20 Matus UHLAR - fantomas : >> 2011/12/20 Mark Andrews : >>> >>> Named has a compiled in set of root hints. It is used if >>> a root zone is not defined in named.conf. > > > On 20.12.11 17:37, Peter Andreev wrote: >> >> Whether it means that without hint zone named still can perform >> iterative lookups for its internal purposes? > > > yes. This fact is really disappointing. Anyway thank you, Matus, for answer > > -- > 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. > Despite the cost of living, have you noticed how popular it remains? > ___ > > 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 -- -- AP ___ 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: About root zones
2011/12/20 Mark Andrews : Named has a compiled in set of root hints. It is used if a root zone is not defined in named.conf. On 20.12.11 17:37, Peter Andreev wrote: Whether it means that without hint zone named still can perform iterative lookups for its internal purposes? 2011/12/20 Matus UHLAR - fantomas : yes. On 21.12.11 12:17, Peter Andreev wrote: This fact is really disappointing. well, it's needed for proper functionality. What exactly seems to be your problem? Note that - only clients that are allowed to recurse are able to see date the "type hint" zone - only clients from local networks are allowed to recurse by default. You can tune this by configuring the "allow-recursion" option. -- 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. Atheism is a non-prophet organization. ___ 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: load-balancing in DNS using two A records
In message <2011122018.ga3...@fantomas.sk>, Matus UHLAR - fantomas writes: Long time ago when we were trying to have multiple web servers for redundancy and balancing, we have found that multiple IP's is not a good solution (parts of web pages didn't load). We selected L3 switches then... On 21.12.11 09:26, Mark Andrews wrote: Which is really the result of badly designed clients. Clients are getting better with address affinity and fast failover on unreachable servers. It's been long time ago (~10 years). And even if they did failover, 30s (tcp connection timeout) delays are very ugly when loading a web page. -- 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. Eagles may soar, but weasels don't get sucked into jet engines. ___ 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: About root zones
2011/12/21 Matus UHLAR - fantomas : 2011/12/20 Mark Andrews : > > Named has a compiled in set of root hints. It is used if > a root zone is not defined in named.conf. > > >>> On 20.12.11 17:37, Peter Andreev wrote: Whether it means that without hint zone named still can perform iterative lookups for its internal purposes? > > >> 2011/12/20 Matus UHLAR - fantomas : >>> >>> yes. > > > On 21.12.11 12:17, Peter Andreev wrote: >> >> This fact is really disappointing. > > > well, it's needed for proper functionality. What exactly seems to be your > problem? Well, we run a bunch of authoritative-only slave servers and obviously they don't have to perform any kind of lookups. Some time ago user complained that one of these slave servers responses with wrong data. My colleague tried to investigate this issue, but without any success. Just in case we disabled "additional-from-cache". That's why any sort of internal lookups looks very suspicious for me. > > Note that > - only clients that are allowed to recurse are able to see date > the "type hint" zone > - only clients from local networks are allowed to recurse by default. > You can tune this by configuring the "allow-recursion" option. > > -- > 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. > Atheism is a non-prophet organization. > ___ > > 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 -- -- AP ___ 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
[no subject]
Hello, list!
I have split view on my name-servers (master and slave), for internal
and external clients i have zone with similar names, but different content.
Part of config named.conf on master:
view "internal" {
match-clients { myclients; };
recursion yes;
match-recursive-only yes;
allow-recursion { myclients; };
...
zone "10.168.192.in-addr.arpa" {
type master;
file "10.168.192.in-addr.arpa.db";
allow-transfer {transfer_acl;};
allow-update {none;};
};
...
}
view "external" {
match-clients { "any"; };
recursion no;
...
[here descriptions of zone]
}
Well, then i have "match-recursive-only yes" directive in "internal"
view, slave name-server report: "zone
10.168.192.in-addr.arpa/IN/internal: refresh: non-authoritative answer
from master xx.xx.136.2#53 (source xx.xx.140.26#0). If
match-recursive-only no, zone transfer to slave all right. There i have
wrong? Thx.
--
WBR, Konstantin V. Krotov
mailto: k...@insysnet.ru
___
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: I specify subject: split view, match-recursive-only, non-authoritative answer from master
21.12.2011 13:54, Konstantin V. Krotov пишет:
Hello, list!
I have split view on my name-servers (master and slave), for internal
and external clients i have zone with similar names, but different content.
Part of config named.conf on master:
view "internal" {
match-clients { myclients; };
recursion yes;
match-recursive-only yes;
allow-recursion { myclients; };
...
zone "10.168.192.in-addr.arpa" {
type master;
file "10.168.192.in-addr.arpa.db";
allow-transfer {transfer_acl;};
allow-update {none;};
};
...
}
view "external" {
match-clients { "any"; };
recursion no;
...
[here descriptions of zone]
}
Well, then i have "match-recursive-only yes" directive in "internal"
view, slave name-server report: "zone
10.168.192.in-addr.arpa/IN/internal: refresh: non-authoritative answer
from master xx.xx.136.2#53 (source xx.xx.140.26#0). If
match-recursive-only no, zone transfer to slave all right. There i have
wrong? Thx.
--
WBR, Konstantin V. Krotov
CJSs "Information Systems"
mailto: k...@insysnet.ru
phone: +7 (8332) 51-35-95
___
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: I specify subject: split view, match-recursive-only, non-authoritative answer from master
Hi,
Maybe this can help you.
First you need two network interfaces with diferent ip.
At the internal view declaration add transfer-source 192.168.11.x; ( has to
be different from your public/external)
In the zone statement, you must specify the private IP address of your
slaves, at allow-transfer clause
I hope you worth something.
regards.
Gelo
2011/12/21 Konstantin V. Krotov
> 21.12.2011 13:54, Konstantin V. Krotov пишет:
>
>> Hello, list!
>> I have split view on my name-servers (master and slave), for internal
>> and external clients i have zone with similar names, but different
>> content.
>> Part of config named.conf on master:
>>
>> view "internal" {
>> match-clients { myclients; };
>> recursion yes;
>> match-recursive-only yes;
>> allow-recursion { myclients; };
>> ...
>> zone "10.168.192.in-addr.arpa" {
>> type master;
>> file "10.168.192.in-addr.arpa.db";
>> allow-transfer {transfer_acl;};
>> allow-update {none;};
>> };
>> ...
>> }
>>
>> view "external" {
>> match-clients { "any"; };
>> recursion no;
>> ...
>> [here descriptions of zone]
>> }
>>
>> Well, then i have "match-recursive-only yes" directive in "internal"
>> view, slave name-server report: "zone
>> 10.168.192.in-addr.arpa/IN/**internal: refresh: non-authoritative answer
>> from master xx.xx.136.2#53 (source xx.xx.140.26#0). If
>> match-recursive-only no, zone transfer to slave all right. There i have
>> wrong? Thx.
>>
>>
> --
> WBR, Konstantin V. Krotov
> CJSs "Information Systems"
> mailto: k...@insysnet.ru
> phone: +7 (8332) 51-35-95
> __**_
> Please visit
> https://lists.isc.org/mailman/**listinfo/bind-usersto
> 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: load-balancing in DNS using two A records
In message <20111221083337.gb5...@fantomas.sk>, Matus UHLAR - fantomas writes: > >In message <2011122018.ga3...@fantomas.sk>, Matus UHLAR - fantomas write > s: > >> Long time ago when we were trying to have multiple web servers for > >> redundancy and balancing, we have found that multiple IP's is not a > >> good solution (parts of web pages didn't load). We selected L3 > >> switches then... > > On 21.12.11 09:26, Mark Andrews wrote: > >Which is really the result of badly designed clients. Clients are getting > >better with address affinity and fast failover on unreachable servers. > > It's been long time ago (~10 years). And even if they did failover, 30s > (tcp connection timeout) delays are very ugly when loading a web page. Indeed. 150-250ms [1] is a more realistic timeout for starting a second connection attempt. You use the connection which completes first and close the others if they complete. Mark [1] http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: load-balancing in DNS using two A records
In article , Matus UHLAR - fantomas wrote: > On 20.12.11 19:37, Martin T wrote: > >I have seen setups where one domain name has two address records. > >First IP address is in the ISP-A network and the other one is in the > >ISP-B network. In case I execute "host www..com", I always > >get two IP addresses as a reply and they always appear by turns. Am I > >correct, that setup like this provides redundancy as well as > >load-balancing? > > Kind of. It's much better to have real load-balancing and vailover by > multiple links or L3 load balancers. If you're really cheapskate and have a little scripting expertise you can do what we did before we went to hardware load balancing. Give your systems names with short TTLs in a dynamic zone. Have a watchdog process monitor the systems and remove any that don't respond. It's not generally fast enough to help individual clients but it can help the overall availability of a system. It's victim to browsers ignoring TTLs, of course, though I've never been able to verify such browser behaviour myself. Sam ___ 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: About root zones
"if a root zone is not defined in named.conf" I wonder if you really do NOT want to ever hit root zones you could make your own entry in named.conf that points to localhost for root zone and thereby avoid hitting any real root? -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Peter Andreev Sent: Wednesday, December 21, 2011 4:05 AM To: bind-users@lists.isc.org Subject: Re: About root zones 2011/12/21 Matus UHLAR - fantomas : 2011/12/20 Mark Andrews : > >Named has a compiled in set of root hints. It is used if >a root zone is not defined in named.conf. > > >>> On 20.12.11 17:37, Peter Andreev wrote: Whether it means that without hint zone named still can perform iterative lookups for its internal purposes? > > >> 2011/12/20 Matus UHLAR - fantomas : >>> >>> yes. > > > On 21.12.11 12:17, Peter Andreev wrote: >> >> This fact is really disappointing. > > > well, it's needed for proper functionality. What exactly seems to be your > problem? Well, we run a bunch of authoritative-only slave servers and obviously they don't have to perform any kind of lookups. Some time ago user complained that one of these slave servers responses with wrong data. My colleague tried to investigate this issue, but without any success. Just in case we disabled "additional-from-cache". That's why any sort of internal lookups looks very suspicious for me. > > Note that > - only clients that are allowed to recurse are able to see date > the "type hint" zone > - only clients from local networks are allowed to recurse by default. > You can tune this by configuring the "allow-recursion" option. > > -- > 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. > Atheism is a non-prophet organization. > ___ > > 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 -- -- AP ___ 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 Athena®, Created for the Cause(tm) Making a Difference in the Fight Against Breast Cancer - 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: About root zones
On 20.12.11 17:37, Peter Andreev wrote: Whether it means that without hint zone named still can perform iterative lookups for its internal purposes? On 21.12.11 13:05, Peter Andreev wrote: Well, we run a bunch of authoritative-only slave servers and obviously they don't have to perform any kind of lookups. If they don't have to, they won't. Some time ago user complained that one of these slave servers responses with wrong data. My colleague tried to investigate this issue, but without any success. Just in case we disabled "additional-from-cache". Disabling recursion should do the same afaik. However, disabling additional-from-cache is OK and afaik disabled by default. That's why any sort of internal lookups looks very suspicious for me. server needs to resolve names if it's supposed to send NOTIFY messages. -- 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. I drive way too fast to worry about cholesterol. ___ 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: About root zones
2011/12/21 Matus UHLAR - fantomas : > On 20.12.11 17:37, Peter Andreev wrote: >> >> Whether it means that without hint zone named still can perform >> iterative lookups for its internal purposes? > > > On 21.12.11 13:05, Peter Andreev wrote: >> >> Well, we run a bunch of authoritative-only slave servers and obviously >> they don't have to perform any kind of lookups. > > > If they don't have to, they won't. I hope so. > > >> Some time ago user complained that one of these slave servers >> responses with wrong data. My colleague tried to investigate this >> issue, but without any success. Just in case we disabled >> "additional-from-cache". > > > Disabling recursion should do the same afaik. However, disabling > additional-from-cache is OK and afaik disabled by default. No, it is enabled by default. > > >> That's why any sort of internal lookups looks very suspicious for me. > > > server needs to resolve names if it's supposed to send NOTIFY messages. All these servers are slaves. They don't send notifies. So while I'm really confused about described issue, I'd like to not speculate on it, because it happened only once. What I don't like at all is the impossibility to disable these lookups. Of course I can follow Jeff's advice and redirect these lookups to localhost, but it is not a solution, it only transfers problem to another area. Ok, may be I'm a paranoid and worrying about trifles, but news about compiled in hints astonished me. > > > -- > 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. > I drive way too fast to worry about cholesterol. > ___ > > 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 -- -- AP ___ 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: About root zones
2011/12/21 Matus UHLAR - fantomas : Disabling recursion should do the same afaik. However, disabling additional-from-cache is OK and afaik disabled by default. On 21.12.11 19:21, Peter Andreev wrote: No, it is enabled by default. server needs to resolve names if it's supposed to send NOTIFY messages. All these servers are slaves. They don't send notifies. they do, unless you have turned it off... So while I'm really confused about described issue, I'd like to not speculate on it, because it happened only once. What I don't like at all is the impossibility to disable these lookups. Do you think if server needed to resolve something, and you would disable it, it would work better? I think just the oposite. If a server does lookups only when needed, then disabling required lookups would make it not working. Ok, may be I'm a paranoid and worrying about trifles, but news about compiled in hints astonished me. since it only happened once and you weren't able to find out what really happened (did you at least make sure your customer is right?), it should not be an issue to care about this much... -- 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. If Barbie is so popular, why do you have to buy her friends? ___ 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:
Zone refresh checks and zone transfer requests are not recursive queries. With
match-recursive-only, the view cannot act as a master to any slave. You might
want to consider a hidden master that does not have this option set.
Regards,
Chris Buxton
BlueCat Networks
On Dec 21, 2011, at 1:54 AM, Konstantin V. Krotov wrote:
> Hello, list!
> I have split view on my name-servers (master and slave), for internal and
> external clients i have zone with similar names, but different content.
> Part of config named.conf on master:
>
> view "internal" {
>match-clients { myclients; };
>recursion yes;
>match-recursive-only yes;
>allow-recursion { myclients; };
> ...
>zone "10.168.192.in-addr.arpa" {
>type master;
>file "10.168.192.in-addr.arpa.db";
>allow-transfer {transfer_acl;};
>allow-update {none;};
>};
> ...
> }
>
> view "external" {
>match-clients { "any"; };
>recursion no;
> ...
> [here descriptions of zone]
> }
>
> Well, then i have "match-recursive-only yes" directive in "internal" view,
> slave name-server report: "zone 10.168.192.in-addr.arpa/IN/internal: refresh:
> non-authoritative answer from master xx.xx.136.2#53 (source xx.xx.140.26#0).
> If match-recursive-only no, zone transfer to slave all right. There i have
> wrong? Thx.
>
> --
> WBR, Konstantin V. Krotov
> mailto: k...@insysnet.ru
> ___
> 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: I specify subject: split view, match-recursive-only, non-authoritative answer from master
No, that's not correct. You can use TSIG keys to differentiate between views,
without using separate interfaces. However, this will not solve the problem --
removing match-recursive-only will solve the problem.
Regards,
Chris Buxton
BlueCat Networks
On Dec 21, 2011, at 2:23 AM, Gelo wrote:
> Hi,
>
> Maybe this can help you.
>
> First you need two network interfaces with diferent ip.
>
> At the internal view declaration add transfer-source 192.168.11.x; ( has to
> be different from your public/external)
>
> In the zone statement, you must specify the private IP address of your
> slaves, at allow-transfer clause
>
> I hope you worth something.
>
>
> regards.
> Gelo
>
> 2011/12/21 Konstantin V. Krotov
> 21.12.2011 13:54, Konstantin V. Krotov пишет:
> Hello, list!
> I have split view on my name-servers (master and slave), for internal
> and external clients i have zone with similar names, but different content.
> Part of config named.conf on master:
>
> view "internal" {
> match-clients { myclients; };
> recursion yes;
> match-recursive-only yes;
> allow-recursion { myclients; };
> ...
> zone "10.168.192.in-addr.arpa" {
> type master;
> file "10.168.192.in-addr.arpa.db";
> allow-transfer {transfer_acl;};
> allow-update {none;};
> };
> ...
> }
>
> view "external" {
> match-clients { "any"; };
> recursion no;
> ...
> [here descriptions of zone]
> }
>
> Well, then i have "match-recursive-only yes" directive in "internal"
> view, slave name-server report: "zone
> 10.168.192.in-addr.arpa/IN/internal: refresh: non-authoritative answer
> from master xx.xx.136.2#53 (source xx.xx.140.26#0). If
> match-recursive-only no, zone transfer to slave all right. There i have
> wrong? Thx.
>
>
> --
> WBR, Konstantin V. Krotov
> CJSs "Information Systems"
> mailto: k...@insysnet.ru
> phone: +7 (8332) 51-35-95
> ___
> 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
___
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: About root zones
On Wed, 21 Dec 2011, Peter Andreev wrote: Ok, may be I'm a paranoid and worrying about trifles, but news about compiled in hints astonished me. The test shown here may calm you (if it shows refusal): https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful Dave -- David Forrest St. Louis, Missouri ___ 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: DLZ provider other than a database?
On 12/20/2011 10:06 PM, SM wrote: > At 17:53 20-12-2011, Doug Barton wrote: >> I've been given an interesting challenge that I doubt I'm the first one >> to face, so I thought I'd ask. :) I have an internal project for which >> I have a large'ish number of hostnames that I want to return a fairly >> standard set of RRs for, but (for a variety of reasons) I'd rather not >> create any sort of static data set for (e.g., zone file, actual db >> entries, etc.). > > https://github.com/jpmens/dlz_lua Thanks, I'll take a look at that. Any other ideas? :) Doug -- [^L] 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: About root zones
David, thank you, I checked and all seems good :). 2011/12/21 Matus UHLAR - fantomas : >> 2011/12/21 Matus UHLAR - fantomas : >>> >>> Disabling recursion should do the same afaik. However, disabling >>> >>> additional-from-cache is OK and afaik disabled by default. > > > On 21.12.11 19:21, Peter Andreev wrote: >> >> No, it is enabled by default. > > >>> server needs to resolve names if it's supposed to send NOTIFY messages. >> >> >> All these servers are slaves. They don't send notifies. > > > they do, unless you have turned it off... Of course I turned it off, it's normal practice for slaves, I assume. > > >> So while I'm really confused about described issue, I'd like to not >> speculate on it, because it happened only once. >> What I don't like at all is the impossibility to disable these >> lookups. > > > Do you think if server needed to resolve something, and you would disable > it, it would work better? I think just the oposite. If a server does lookups > only when needed, then disabling required lookups would make it not working. > I think that if server is authoritative - and - slave-only it should use system resolver rather than querying by itself. Where can I find information about what causes queries for internal duties? If it can be found in ARM, could you please point me to the right chapter. May be I missed something while reading it. The only mention I have met is that additional resolving is needed for sending notifies (And will this resolving be performed in case of list of slaves' ip addresses is written in named.conf?). > >> Ok, may be I'm a paranoid and worrying about trifles, but news about >> compiled in hints astonished me. > > > since it only happened once and you weren't able to find out what really > happened (did you at least make sure your customer is right?), it should not > be an issue to care about this much... > > -- > 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. > If Barbie is so popular, why do you have to buy her friends? > ___ > > 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 -- -- AP ___ 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
