Debugging configuring TKEY: failure (w/samba4)
I'm attempting to get Bind 9.7.2 (built on openSUSE 11.3) running in
relation to Samba4; this uses GSSAPI authentication to update the Bind
zones. Everything works except this part. I've build bind with
--with-gssapi, verified krb5 is linked in, and verified [at least with
kinit and other trivial krb5 tools] that Kerberos/GSSAPI is working.
But when I add:
options {
tkey-gssapi-credential DNS/ad.mormail.com;
tkey-domain AD.MORMAIL.COM;
...
}
- to my bind configuration bind fails to start with -
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone: D.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
8.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
9.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
A.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
B.E.F.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: automatic empty zone:
8.B.D.0.1.0.0.2.IP6.ARPA
Nov 10 08:43:32 opensuse named[3021]: configuring TKEY: failure
Nov 10 08:43:32 opensuse named[3021]: loading configuration: failure
Nov 10 08:43:32 opensuse named[3021]: exiting (due to fatal error)
I've tried playing with log levels, etc... and I just can seem to dig
any more information out of it. Are there any procedures / tips for
debugging a configuring TKEY: failure message?
--
Adam Tauno Williams awill...@whitemice.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio casey at deccio.net writes: On Tue, Nov 9, 2010 at 8:10 PM, Brian J. Murrell brian at interlinx.bc.ca wrote: $ dig @linux -p 1053 41.70.55.206.sa-trusted.bondedsender.org txt Doh! I forgot the +dnssec. What happens when you run the following queries: dig +dnssec @linux -p 1053 org SOA Do you get a NOERROR response with the AD bit set? Yup: $ dig +dnssec @linux -p 1053 org SOA ; DiG 9.7.1-P2 +dnssec @linux -p 1053 org SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 44657 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;org. IN SOA ;; ANSWER SECTION: org.670 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2009390492 1800 900 604800 86400 org.670 IN RRSIG SOA 7 1 900 20101124135902 20101110125902 61598 org. cqufQ6aorG5AeM7mFR/lwm9TnLwdK9PjTH36lEo4fYBk5jH+sgLM17rG wZD6c4/ZZHuT4ZvcQMa6pR1CgEtBLq1YAIT5zl0ncWs2pbyS2BFr35k5 B9thalfcHAGXFATzCFcVzQTVBSFy5QDPMuHpz2LTvaFc0xiE6sGqF+Fr Q14= ;; AUTHORITY SECTION: org.86175 IN NS a2.org.afilias-nst.info. org.86175 IN NS b0.org.afilias-nst.org. org.86175 IN NS a0.org.afilias-nst.info. org.86175 IN NS d0.org.afilias-nst.org. org.86175 IN NS c0.org.afilias-nst.info. org.86175 IN NS b2.org.afilias-nst.org. org.86175 IN RRSIG NS 7 1 86400 20101123154737 20101109144737 61598 org. KncVCF0Fbp56Cf7xW376cEuGnNL/G19WM0GfXhWwWHuWKn2HDjx7OJMi a0OYeoo/KlUn0pO0ORgT96vurhOkweEfdZXnpdPRRHBStfmpFZYD9wxG FiyGounAQuso/EWSZhmwHXsFieElBQ8+J8sKY+EDo4K92uCZ5QtQAI6S 7m8= ;; Query time: 2 msec ;; SERVER: 10.75.22.3#1053(10.75.22.3) ;; WHEN: Wed Nov 10 09:02:03 2010 ;; MSG SIZE rcvd: 536 dig +dnssec @linux -p 1053 bondedsender.org DS Do you get a NOERROR response with AD bit No AD bit set, however... set and NSEC3 RRs and their covering RRSIGs? I do get NSEC3 and RRSIG RRs: ; DiG 9.7.1-P2 +dnssec @linux -p 1053 bondedsender.org DS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 18923 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;bondedsender.org. IN DS ;; AUTHORITY SECTION: org.590 IN SOA a0.org.afilias-nst.info. noc.afilias-nst.info. 2009390497 1800 900 604800 86400 org.590 IN RRSIG SOA 7 1 900 20101124140403 20101110130403 61598 org. C92vKu2HbiWyt+hgBJD5Arj4egcuL197n0AQWgnKPMQ+XdG90tGG0/5h 81dQZI/xKQQsoTA5I4oKa9qspxXqC1T1Ej7bBzFqnSrgVDpv1fI/GvIt UWbxYL888sn9XE/IP/tHWsbY6aIoSsheYTdJP0oOuunVMkF+i4c25c0v 9Yo= h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN RRSIG NSEC3 7 2 86400 20101124140403 20101110130403 61598 org. qUeV9GSkAD4cY9ftHxclrhrX9tzzZmUJSDXgDab78x8DoBFZ9LNKg+jG Yvqqbk0CqOxAJKE7CGDV6WzcsBQJCdM1+3r3+L660i6jIgubxMwGpWc0 C/GXRhtYZXOuAHpVI0gHPCSoQzLqYU+QxxBepgOUUxSnLS4Zx7tftpqI zAg= h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.org. 590 IN NSEC3 1 1 1 D399EAAB H9PLJ7JCGLSRA48965QFJNJ3D0HC4FP5 NS SOA RRSIG DNSKEY NSEC3PARAM t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN RRSIG NSEC3 7 2 86400 20101124010350 2010111350 61598 org. MLy2iRpF6yKCUfcb0zxow1Dn6ky7BaZQrMZCHsfbFOsV7p5fI13JQJ2r ihceyFt5G3VcJrnzm5E51YVlKKFEJmHIwaTUdHDTcBznqzOk+s3xm1iC o3cBgrMMEOOQwsX7sVMHLg9NuQ395lq2GZtOrvYZWAEpCU9dOmqcSbFO 2+M= t2ei86koq1j2hk8c8m677mgc115vgvu8.org. 590 IN NSEC3 1 1 1 D399EAAB T2GH7ROARI9U6G24CR9QK4J52L88HKPV ;; Query time: 3993 msec ;; SERVER: 10.75.22.3#1053(10.75.22.3) ;; WHEN: Wed Nov 10 09:03:23 2010 ;; MSG SIZE rcvd: 756 The above produced the following in the bind debug log [ sorry for all the line wrapping. Stupid gmane enforces that ]: dnssec: validating @0x20fc49b0: bondedsender.org DS: starting dnssec: validating @0x20fc49b0: bondedsender.org DS: attempting negative response validation dnssec: validating @0x20fc49b0: bondedsender.org DS: nsecvalidate: creating validator for org SOA dnssec: validating @0x20fc7b98: org SOA: starting dnssec: validating @0x20fc7b98: org SOA: attempting positive response validation dnssec: validating @0x20fc7b98: org SOA: keyset with trust 8 dnssec: validating @0x20fc7b98: org SOA: verify rdataset (keyid=61598): success dnssec: validating @0x20fc7b98: org SOA: marking as secure, noqname proof not needed dnssec: validator @0x20fc7b98: dns_validator_destroy dnssec: validating @0x20fc49b0: bondedsender.org DS: in authvalidated dnssec: validating @0x20fc49b0: bondedsender.org DS: resuming nsecvalidate dnssec: validating @0x20fc49b0: bondedsender.org DS:
why one shouldn't use relative hostnames
We are working with a software vendor whose software only works with relative hostnames - they say it can't cope with a fully-qualified domain name. They want us to make sure the necessary domain is in all clients' search lists. Does anyone have any good references for me to explanations of why this is a very bad thing. I would find quick access to thoughtful well-phrased arguments very useful right now. Thanks! Maria ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 10 Operational Requirements Survey: Help shape the future of BIND
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear User Community - BIND 10 is now in its second year of development, and we would like to hear more from current BIND 9 users about operational needs for BIND 10 as we move toward the more user-facing aspects of BIND 10 development. This survey will ask about your specific business and operational environment, what works well for you in BIND 9 and what does not, and then what aspects of BIND 9 would be critical for you to maintain in migrating to BIND 10. This data will be used to develop user-facing aspects of BIND 10 including but not limited to the command line interface. Your responses will be kept confidential. We would like to contact some respondents by phone for further discussion, so please indicate if this is an option for you. Participants in the follow on phone call will receive a BIND 10 t-shirt as a thank you. Thank you for your time, and for your support of ISC and BIND. The survey is at: http://www.isc.org/announcement/give-your-input-future-bind Best, Larissa Larissa Shapiro BIND and DHCP Product Manager -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJM2uvGAAoJEBOIp87tasiULTMIAJrt2WxQrJG2mwFwUc0a5kPJ b/YlFgHuDyO4eMwnbMzFllhGFWLfeePu60chU81AxcVP7Pxs8JC5bX6idLUVK0Y3 vVfETsze4iK3YBLkpSL23oN61f6b31oypn+gdYoIVU13EO1VUG3Dy5CsE0CG95DP tjcwXYdC04da/L/oeQwfCTvwppusfzzvWG92JaABpgmFmy7DkmvWaleq6TZrbqIV orn8ruWVvuZ9S1XfXYkLhLYwus00KG62sJfm9VQQSWng1/W/iA3kHvr5/EUjir50 xUE4NJkmZfi5+GniNhm2el9LjrP3heRtSOA56wlsNLtoNIUO4ib0Y5dp5MV3bzI= =hlIJ -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND View Option
Hi all, we are in a situation here in our company that is: we need to send a internal IP address in a answer of a query when the source is a specific IP. So we created a new view and put the source address of this IP and configured the internal zone file on this view and this is working well. But, this same source address must resolve all the other entrys that exist today on this same zone using the external IPs. We would not like to replicate all the entrys of the external zone file to the internal zone file because in this model every time that we did change an entry on the external zone file we will have to configure this same entry in the internal zone file. Is there a way or option to configure bind to do the following logic: If the bind didnt find a entry in a view 1 (internal view) it will search this entry on the view 2 (external view) ? Thank you very much. Stéphanas Schaden mailto:stephan...@ctbc.com.br stephan...@ctbc.com.br Brazil ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
Is there a way or option to configure bind to do the following logic: If the bind didn’t find a entry in a view 1 (internal view) it will search this entry on the view 2 (external view) ? Not to my knowledge. We had the same problem and ended up with using the hosts file for the special IP addresses. It would have been nice to have been able to use BIND for everything. This just illustrates that the simple view concept in BIND really needs an overhaul as I have been advocating lately about groups of zones where the extended search is just done on zones not on individual resource records. - Jørgen Thomsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
From: St?phanas Schaden stephan...@ctbc.com.br wrote:
Is there a way or option to configure bind to do the following logic:
If the bind didn't find a entry in a view 1 (internal view) it will
search this entry on the view 2 (external view) ?
Place the common piece in a separate include file:
view view1 {
...
include named.conf.non-views;
...
}
view view2 {
...
include named.conf.non-views;
...
}
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RES: BIND View Option
Hi Barry,
I'm sorry but I didn't understand the configuration. Could you give
me an example of the named.conf.non-views ?
Thank you.
Stéphanas Schaden
stephan...@ctbc.com.br
Uberlândia - MG - Brazil
-Mensagem original-
De: bind-users-bounces+stephanass=ctbc.com...@lists.isc.org
[mailto:bind-users-bounces+stephanass=ctbc.com...@lists.isc.org] Em nome de
Barry Finkel
Enviada em: quarta-feira, 10 de novembro de 2010 18:46
Para: bind-users@lists.isc.org
Assunto: Re: BIND View Option
From: St?phanas Schaden stephan...@ctbc.com.br wrote:
Is there a way or option to configure bind to do the following logic:
If the bind didn't find a entry in a view 1 (internal view) it will
search this entry on the view 2 (external view) ?
Place the common piece in a separate include file:
view view1 {
...
include named.conf.non-views;
...
}
view view2 {
...
include named.conf.non-views;
...
}
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/10/2010 3:17 PM, J. Thomsen wrote: Is there a way or option to configure bind to do the following logic: If the bind didn’t find a entry in a view 1 (internal view) it will search this entry on the view 2 (external view) ? Not to my knowledge. We had the same problem and ended up with using the hosts file for the special IP addresses. Hosts file? Special IP addresses? I don't quite understand your solution. The typical way to deal with these situations is to have two different views, internal and external, with the differentiated entries existing separately in their respective versions of the zone, and the entries which are common to both, shared via an $INCLUDE file. Not sure why you felt it necessary to resort to hosts files. The $INCLUDE-file trick is incompatible with Dynamic Update, of course, but if you already -- as we do -- have Dynamic Update and some sort of programmatic front-end on it, why not add just add the logic in the front-end for the updates to go to whichever view(s) in which they need to be visible? What am I missing here? It would have been nice to have been able to use BIND for everything. This just illustrates that the simple view concept in BIND really needs an overhaul as I have been advocating lately about groups of zones where the extended search is just done on zones not on individual resource records. Views in BIND was never meant to provide a general search function. It's an alternative to running -- multiple nameserver instances, listening on different interfaces, or -- completely separate nameserver devices. If you want fancy extended search capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forward after option
What you're suggesting is not really the inverse of forward first. Forward first is basically: (try forwarding) - [TIMEOUT FROM ALL FORWARDERS] - (try iterative resolution) The inverse would be: (try iterative resolution) - [TIMEOUT FROM ALL AUTHORITATIVE NAMESERVERS] - (try forwarding) But you're not talking about timeouts, right? You're talking about perfectly-valid responses that you don't like. This is not found forwarding and in all the years people have been asking for it, it has not been implemented in BIND because (at a minimum) a) there are ambiguities with respect to what constitutes not found (NXDOMAIN only? NODATA? REFUSED? SERVFAIL? DNSSEC validation failure?), and b) it complicates and confuses resolution, and maintenance/troubleshooting of same. In your case, what you might end up having to do is either a) start duplicating all of your external records in the internal version(s) of your zone(s), and have your business partner use that, or b) have your business partner look generally at the external version(s) of your zone(s), and then have them create a zone, with just a single leaf-node entry in it, for each name that they need to access, which does not exist in the external version of the zone, e.g. foo.bar.example.com. This could potentially add up to a lot of zone definitions. c) the inverse of the above: have your business partner look generally at the internal version(s) of your zone(s), and then create individual zones for each external name that they need to access. Note that for browser-based traffic *only*, a slightly-less ugly solution than (b) or (c) above is for your business partner to use a proxy auto-config (PAC) file with their clients (or modify their existing PAC). Then you can selectively control whether the client looks up the DNS itself (DIRECT), or uses a particular proxy, and then co-ordinate that with whether the clients or the proxy/proxies see the internal or external version(s) of the zone(s), respectively. E.g. internal sites go DIRECT and clients resolve the internal version of the zone, while external sites are proxied and the proxy sees the external version of the zone, or external sites go DIRECT and clients resolve the external version of the zone, while internal sites are proxied and the proxy sees the internal version of the zone, or internal sites go to proxyA and proxyA resolves the internal DNS, external sites go to proxyB and proxyB resolves the external DNS - Kevin P.S. If your internal and external DNS are completely distinct from each other, how do your own internal users get to your own external websites? If you're already solved that problem for your own clients, why not just use the same solution with your business partner, if possible? On 11/10/2010 3:08 PM, Stéphanas Schaden wrote: Hi all, we have a situation on our company today that is: We have a external authoritative zone in our public DNS. Have have a partner company that connect to our network and need to use a internal IP address of our company but using the internal link and the name of the FQDN of this access is configured on our external zone. We were looking about the forward configuration on BIND and we found that there is the forward only and forward first option. If our partner configure our external zone on their DNS and configured just this specific entry on the zone and configure the forward of the zone to our public DNS will not work because our public DNS have this entry and this entry is appointing to the public IP. So the entry on our customer DNS will be used just after it query our public DNS. So we were looking for if there is a option on BIND (we did not found anything yet) to do the inverse of the forward first. Something link forward after. So, if our customer DNS receive a query and it have that entry on the zone it will answer to the source. If it did not find this entry in the zone it will do the forward process to our public DNS. There is something that could do this using BIND ? Thank you very much. Stéphanas Schaden stephan...@ctbc.com.br Brazil ___ 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: BIND View Option
Not sure why you felt it necessary to resort to hosts files. Well, I don't know how to configure ressource records in an include file and don't want to waste gigabytes of RAM duplicating zones. What am I missing here? The idea of avoiding front ends ! Views in BIND was never meant to provide a general search function. Alas they should never be changed. If you want fancy extended search capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND. Right, I understand the point. Let us stay in the good old days. No bright ideas here. They may disturb the peace. What I am missing on this list is people, which do not see their primary task as keeping everything as it is and taking an interest in discussing new ideas. - Jørgen Thomsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: why one shouldn't use relative hostnames
On 11/10/2010 1:19 PM, Maria Iano wrote: We are working with a software vendor whose software only works with relative hostnames - they say it can't cope with a fully-qualified domain name. They want us to make sure the necessary domain is in all clients' search lists. Does anyone have any good references for me to explanations of why this is a very bad thing. I would find quick access to thoughtful well-phrased arguments very useful right now. I've looked for such a thing from time to time, with no success. Maybe I need to compose something like that. Main reasons for not using shortnames: a) Security. The problem cited way back in RFC 1535 still exists, in a slightly different form, with respect to shortnames, i.e. they're ambiguous and can cause names to resolve unexpectedly, thus causing connections to be made to unexpected hosts, which might not be trusted. E.g. we have multiple DNS names with the first label of mailroom, one could potentially connect to the wrong mailroom server, depending on the (somewhat arbitrary) ordering of one's searchlist. A less-trusted mailroom server could trojan the more-trusted one. b) Capacity and performance (specifically, query latency). Each searchlist element magnifies query volume, and increases query latency for all queries which don't happen to resolve with the first element in the searchlist. Names which don't resolve at all (typos, obsolete references, etc.) exhaust the *entire* searchlist, which has maximum latency to the invoking application, and uses maximum nameservice-infrastructure, network, logging and/or server resources. c) Undesired dependencies and co-ordination challenges. Shortname resolution depends on the precise configuration of searchlists, but in many organizations the DNS infrastructure experts are not in the same department as those who control the configuration of searchlists (which are often client OS experts rather than in the server or networking areas), so there can be co-ordination challenges between the departments. When using FQDNs, searchlists are unnecessary and therefore the dependencies and co-ordination challenges are minimized d) Inconsistency between internal and Internet environments; future-proofing. Shortnames are, by and large, not used on the Internet, because of the foregoing reasons, writ large because of the sheer scale and diversity of the Internet and its DNS namespace. If shortnames are used on an internal network, there is an inconsistency between the the two environments, internal and Internet, which may cause confusion and interoperability challenges, should a particular function or subsystem be out-hosted and/or attached to an Internet-accessible cloud at some point in the future. Under this heading, it should be noted that some Internet-oriented technologies absolutely require FQDNs as part of their formal specification. To my knowledge, no formal specifications (other than WINS/NETBIOS perhaps) require shortnames. Therefore, to be most flexible and accommodating to changing technologies and environments, it is best to use the naming format -- FQDNs -- which is most likely to be compatible and interoperable going forward. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: no. of Views and Zones
Alans, I think you're mixing up the resolver function with the hosting function. With some development and implementation, you can offer your customers the ability to set up and maintain their own domains on one nameserver instance, and then have another instance set up for them to resolve Internet DNS names. It is that resolving instance for which you may want to set up views, so that you can have per-customer blocking of domains (although in general this is better done in a web proxy than with Stupid DNS Tricks, IMO) but in that case the number of exception zones would presumably be much smaller than the thousands of domains you quoted, which would be in the hosting instance. How many domains would people want to block in this manner? As for per-customer blocking, I'd suggest having just one blocking view, with the specific domains that are to be blocked, as empty or wildcarded zones, running on a separate interface, and have your blocking-subscribed customers point to that. If that's not fine-grained enough, have a small number of blocking levels -- e.g. none, loose, medium, tight, supertight -- running on separate interfaces, and your customers can choose between them. If they want to pick and choose domain-blocks individually, then this doesn't scale (it's 2-to-the-power-of-n, where n is the number of domains blocked or not blocked), so, as another poster here suggested, for such special needs, make them run their own blocking nameserver config, either completely their own, or layered (through forwarding) on top of one of your loose/medium/tight/supertight offerings. You could offer them some sort of template for this local nameserver config, but ultimately it would be their responsibility to set up and run. Make clear to them that blocking domains was never a designed-in function of the DNS, that they're essentially abusing a name-to-address mapping service to enforce policy controls on their respective user communities, enforcement that oftentimes is easily circumvented by using other naming mechanisms (e.g. local hosts files) or IP-address literals. - Kevin On 11/8/2010 1:01 AM, Alans wrote: On 11/08/2010 12:52 AM, Doug Barton wrote: On 10/31/2010 9:41 AM, Alans wrote: On 10/31/2010 05:48 PM, Alan Clegg wrote: On 10/31/2010 4:48 AM, Alans wrote: Instead of saying how many views can I get, I think you would be much better off saying why am I trying to implement more views. I'm trying to implement something similar to OpenDNS in a smaller scale. i.e. letting each customer to create their own blacklist domains. So I was thinking if I can create a view for each customer and let them edit their zones in a web interface and here my concern is the number of views i can create and number of zones/view. I'm not sure you quite understand what zones and views are. Why would you not simply create a single zone per customer, and eliminate views altogether? Well, maybe I'm not, but how to create a zone per customer? Example, customer1 wants to block access to facebook.com while customer2 wants normal access to facebook.com, how a single view can do that? And we are talking about thousands of domains here. Alans ___ 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: BIND View Option
In article mailman.695.1289418925.555.bind-us...@lists.isc.org, Stéphanas Schaden stephan...@ctbc.com.br wrote: Hi all, we are in a situation here in our company that is: we need to send a internal IP address in a answer of a query when the source is a specific IP. So we created a new view and put the source address of this IP and configured the internal zone file on this view and this is working well. But, this same source address must resolve all the other entrys that exist today on this same zone using the external IPs. We would not like to replicate all the entrys of the external zone file to the internal zone file because in this model every time that we did change an entry on the external zone file we will have to configure this same entry in the internal zone file. Is there a way or option to configure bind to do the following logic: If the bind didnt find a entry in a view 1 (internal view) it will search this entry on the view 2 (external view) ? This is a perfect use for $INCLUDE. Put all the common entries in one file, and put $INCLUDE myzone.common.db in the internal and external zone files. Memory is cheap. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
On 11/10/2010 7:23 PM, J. Thomsen wrote: Not sure why you felt it necessary to resort to hosts files. Well, I don't know how to configure ressource records in an include file and don't want to waste gigabytes of RAM duplicating zones. If your main concern is resource consumption, maybe you should focus on developing some clever algorithm by which named could keep track of multiple references to the same data, without actually having to make separate copies of the data. Kind of a specialized compression algorithm. But, all of that could be done behind the scenes without introducing a new layer of configuration complexity. What am I missing here? The idea of avoiding front ends ! What's a front end and what isn't, is largely in the eye of the beholder. I see views as a front end to multiple, disparate data sets within BIND. You want to put more smarts into that front end, whereas I think it's better to put the smarts into the stage of the pipeline just before BIND. Why is your approach inherently better than mine? Views in BIND was never meant to provide a general search function. Alas they should never be changed. If you want fancy extended search capabilities, look elsewhere or, perhaps, figure out a way to implement this as a database backend to BIND. Right, I understand the point. Let us stay in the good old days. No bright ideas here. They may disturb the peace. What I am missing on this list is people, which do not see their primary task as keeping everything as it is and taking an interest in discussing new ideas. To be honest, I don't really see anything new here. Similar ideas have been raised many times before. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Could DNS help solve this?
Hi This is not a bind problem, not really a DNS problem. I still hope that these might be able to help provide the solution. With the growing number of registrars of e.g. .com domains, it becomes difficult or even almost impossible to figure out which whois server you should ask for information about a domain name. Could that information be added by the registrar to the glue as e.g. a txt RR, so that RR tells which whois serer to use for the domain? I guess that either an RFC or some other standards text would be needed to make this happen and happen in a uniform way. I assume I am not the only one feeling lost here? -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Could DNS help solve this?
Hi Sten, With the growing number of registrars of e.g. .com domains, it becomes difficult or even almost impossible to figure out which whois server you should ask for information about a domain name. Use Whois (first under the 'Other software:' heading) from the command prompt. http://www.linux.it/~md/software/ Even compiles ok under OS/2. Cheers Ian Manners http://www.os2site.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
