Re: Problems in views in a zone transfer
2011/5/6 Luis Silva : > Hi all, > > I'm using bind as frontend solution and I have another server as backend and > I'm implementing zone transfer between the two (bind is the slave and my > server is the master). The problem is that I want to use dns views. Bind > supports it but my backend server is currently not supporting. I'm trying to > find a way for distinguish the zone transfer requests for each view. I have > two solutions: > Hi, using TSIG keys for zone transfer for multi-views, that works well. My website, dnsbed.com, currently has two nameservers. One is in Atlanda, another is in Fremont, CA. Each nameserver has four views. The zone transfer between them is run with TSIG keys, all goes well. -- Jeff Pang www.DNSbed.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC submit of DLV vs DNSKEY records?
On Fri, 06 May 2011 12:45 +1000, "Mark Andrews" wrote: > > > [I hope someone will correct me if I'm wrong.] > > > > > > My understanding: if the parent is signed, that is the only way a > > > child zone can be validated, unless of course using trusted-keys. > > > DLV is only done when the parent is unsigned. > > > > > > Off to the registrar you go! > > Once the parent zone is signed and is accepting DS/DNSKEY records for > child zones there shouldn't be any need to add records to DLV. > > Named won't consult DLV unless there is a insecure delegation between > the configured trust anchors and the zone. That being said other > implementations might try DLV if validation fails on the normal > trust path. This is a implementation choice. all clear, now. i did NOT get that from the docs + dlv site info. thanks! for now it's DS/DNSKEY for me (.com, .net & .org only). just did external verifies on my signed zones, and all's working. DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC submit of DLV vs DNSKEY records?
In message <1304628473.25384.1448737...@webmail.messagingengine.com>, dchilton+ b...@bestmail.us writes: > "missed it by THAT much ...". thx! relocating to bind-users. > > On Thu, 05 May 2011 14:37 -0500, "/dev/rob0" wrote: > > FWIW I think you hit the wrong list. Did you mean bind-users@isc? > > > > On Thu, May 05, 2011 at 12:25:27PM -0700, dchilton+b...@bestmail.us > >wrote: > > > after signing my zones with 'dnssec-signzone', i 've got both > > > > > > dsset-domain.com > > > dlvset-domain.com > > > > > > containing DS- and DLV-records, respectively. > > > > > > i know i *can* submit the records to my registrar (DS records) > > > and dlv.isc.org (DLV records), but should I do both? > > > > > > i'm not clear if these are redundant mechs for getting to a > > > 'valid' DNSSEC state, or complementary. > > > > > > can anyone clarify -- both or just one? and if just one, which > > > one? > > > > [I hope someone will correct me if I'm wrong.] > > > > My understanding: if the parent is signed, that is the only way a > > child zone can be validated, unless of course using trusted-keys. > > DLV is only done when the parent is unsigned. > > > > Off to the registrar you go! Once the parent zone is signed and is accepting DS/DNSKEY records for child zones there shouldn't be any need to add records to DLV. Named won't consult DLV unless there is a insecure delegation between the configured trust anchors and the zone. That being said other implementations might try DLV if validation fails on the normal trust path. This is a implementation choice. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Error when trying to make secondary nameserver from copying primary nameserver
Samad Agha wrote:
> 1- found out which version of bind dsn1 is running and installed exactly
> that version on dns2:
> [root@dns1 named]# named -v
> BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5
That version is quite old. In general, just because server 1 has an old
BIND isn't a reason to choose an old BIND on server 2 as well.
> 2- Copied dns1:/etc/named.conf from primary server (dns1) onto dns2 and
> chown it:
> [root@dns2 ~]# ls -l /etc/named.conf
> -rw-r--r-- 1 root named 2876 May 3 09:30 /etc/named.conf
Sure, you can use an existing named.conf as basis for your 2nd nameserver,
but if you want to turn you setup into a normal master/slave setup, you'll
also want to configure one of them with zones of type slave, and telling
BIND who the master is, something like:
zone "my.zonename" {
type slave;
file "path/to/my.zonename-file";
masters {
192.168.1.10; // use proper IP address instead
};
};
You might also want to set up your zonefile transfers, typically by
allowing the slave to transfer from the master (so you might need to
change the configuration on the master), and perhaps disallowing anyone
else from doing transfers.
> 4- I get the "couldn't open pid file '/var/run/named/named.pid':
> Permission
> denied" as follows:
Check the permissions of that directory, and see if there's also a
named.pid file already. I'm not familiar with that old RedHat package, so
I on't know how it expects things to be set up, if you're using the
bundled start script.
If the permissions initially look good, I suggest you look into whether
you have SELinux running, maybe its policies are making problems for you?
Regards
Eivind Olsen
eiv...@aminor.no
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
current downloads ?
Why does "current downloads" on the isc.org homepage report 9.7.3 for bind and ignore 9.8.x entirely. -- Dennis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) failed)
On Thu, May 05, 2011 at 01:07:24PM -0700, Fr34k wrote: > Thanks Evan. > > Should the Community expect a BIND 9.7.3 train update/maintenance release > which, among other things, addresses this mem.c issue? There will be a 9.7.4 release fairly soon--the beta is in the pipeline already. 9.8.1 will be in beta shortly as well. Whether either of them includes a fix for this particular problem I can't say for sure--you may have tripped over a bug that we already fixed, or maybe not. I would need to see the details of your configuration to say for sure, which is why I asked for your conf file and the output of "named -m record" if possible. > Alternatively, I would entertain the idea of rolling out an > update/maintenance release of 9.8 if such an animal may emerge soon. I > mention this in case this is relevant to any recommendations ISC may > have. I can't really make recommendations. (I, of course, think 9.7.4 and 9.8.1 will both be perfect snowflakes of bug-free wonderfulness, but you might not want to trust the opinion of the author on this point. ;) ) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.8.0-P1 is now available for download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 BIND 9.8.0-P1 is now available for download. This release fixes one security related issue. The full up to date advisory regarding this issue is available at: https://www.isc.org/CVE-2011-1907. A text version of the advisory will be provided for ease of use, but this advisory may be updated. The url will have the up to date version. This release, and its OpenPGP-signatures are available now from: ftp://ftp.isc.org/isc/bind9/9.8.0-P1/bind-9.8.0-P1.tar.gz ftp://ftp.isc.org/isc/bind9/9.8.0-P1/bind-9.8.0-P1.tar.gz.sha512.asc ftp://ftp.isc.org/isc/bind9/9.8.0-P1/bind-9.8.0-P1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.8.0-P1/bind-9.8.0-P1.tar.gz.sha1.asc ISC's Release Signing Key can be obtained at: http://www.isc.org/about/openpgp/ BIND 9.8.0-P1 Release Notes: Introduction BIND 9.8.0-P1 is security patch for BIND 9.8.0. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. Security Fixes 9.8.0-P1 * BIND 9.8.0 introduced Response Policy Zones (RPZ), a mechanism for modifying DNS responses returned by a recursive server according to a set of rules which are either defined locally or imported from a reputation provider. In typical configurations, RPZ is used to force negative (NXDOMAIN) responses for untrusted names. However, it can also be used to replace the answer for a given query, returning a positive response defined by local policy. In BIND 9.8.0, when an RPZ was configured to replace the answer RRset for a given name, a query of type RRSIG for that name could trigger an assertion failure and cause the name server process to exit. [RT #24280] [CVE-2011-1907] Known issues in this release * None. Thank You Thank you to everyone who assisted us in making this release possible. If you would like to contribute to ISC to assist us in continuing to make quality open source software, please visit our donations page at http://www.isc.org/supportisc. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNwztnAAoJEBOIp87tasiUv60H/jUwC6PjilOARAYyAH+ahk82 ttROEJm1KjY01ILd7taG52N+HSztBFfVa/+0/3qoN6Q1A3+bbdBu5OJIoNVW0p1X R6IS/m4dekv4/y0o4NtG4TpSTgVJoAIyBB/UsjtIGcbOOqeH9NWZRkEDodCgErA7 PohZtZV6FAbHbggEj4SGDLGKHZxOoeyrLSkZJYrWbAxwfK5RDUUAPrnsjlNifBQv haXsrGm+HAeM3I//5X0h4ZrtS8YJ0b9ndUcjkkkPoxUMITmOqhQxnvnkJNtDXyaN SbFPUPPj5xhxYPF0QAyJ1fCTQBItXYsldVCZLJSLPkFdwcwgAJU0wt3MqI5RgmY= =Glt0 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS BIND Security Advisory: RRSIG Queries Can Trigger Server Crash When Using Response Policy Zones
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Note: https://www.isc.org/CVE-2011-1907 is the authoritative source for this Security Advisory. Please check the source for any updates. Summary: When a name server is configured with a response policy zone (RPZ), queries for type RRSIG can trigger a server crash. CVE: CVE-2011-1907 Posting date: 05 May 2011 Program Impacted: BIND Versions affected: 9.8.0 Severity: High Exploitable: remotely Description: This advisory only affects BIND users who are using the RPZ feature configured for RRset replacement. BIND 9.8.0 introduced Response Policy Zones (RPZ), a mechanism for modifying DNS responses returned by a recursive server according to a set of rules which are either defined locally or imported from a reputation provider. In typical configurations, RPZ is used to force NXDOMAIN responses for untrusted names. It can also be used for RRset replacement, i.e., returning a positive answer defined by the response policy. When RPZ is being used, a query of type RRSIG for a name configured for RRset replacement will trigger an assertion failure and cause the name server process to exit. Workarounds: Install 9.8.0-P1 or higher. Active exploits: None. However, some DNSSEC validators are known to send type=RRSIG queries, innocently triggering the failure. Solution: Use RPZ only for forcing NXDOMAIN responses and not for RRset replacement. CVSS Score: Base 6.1, adjusted for lack of targets, score is 1.5 (AV:N/AC:L/Au:N/C:N/I:N/A:C/E:P/RL:O/RC:C/TD:L) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2 Thank you to Mitsuru Shimamura at Internet Initiative Japan for finding this defect. For more information on support and other services for ISC's software products, please visit https://www.isc.org/community/blog/201102/BIND-support For more information about DNS RPZ, please check security advisory @ https://www.isc.org/CVE-2011-1907 Questions about this Security Advisory should be sent to the ISC Security Officer . -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNwzttAAoJEBOIp87tasiU48AH+wXeeHyJbcwzjRmnRfdQuCAW SavRo+SIV9uxf9ya+5n2YeBVf1b0zShTta1XlY29FuEwB775YLiTHUgPlABoXgz0 Kc2zBUSS5Bx2mbfujMTN8u0AUTTIr3HMGCJtNpN4yygdg0jNF3dTfuRC++Mx9uwg zJ0U1mQlnCKV5pCAjWTuukc8dHeI2tWXrUwECd6NiFV+wPZ7ekf+cnXIuEQu0eEA sZ5ggsEnFZGVODBwsFe/wAnmo6xWHYpU6oXyeZ1SRZ/T3eDX0PO4ZaaQYBebwQbh tTtnFBrUGjfCoZi8RaKfiaK+ZvLlyG77zgAq87jC5ZUZ+MWfpv8fgYOiDGa4t1M= =LFc6 -END PGP SIGNATURE- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Error when trying to make secondary nameserver from copying primary nameserver
I have a working primary nameserver (dns1) and am trying to configure secondary nameserver (dns2) by copying zone files, config file, etc. from dns1 onto dns2. I have performed the following on dns2 server: 1- found out which version of bind dsn1 is running and installed exactly that version on dns2: [root@dns1 named]# named -v BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5 [root@dns1 named]# [root@dns2 ~]# yum list |grep bind bind.x86_64 30:9.3.6-16.P1.el5 installed bind-libs.x86_64 30:9.3.6-16.P1.el5 installed bind-utils.x86_6430:9.3.6-16.P1.el5 installed ypbind.x86_643:1.19-12.el5 installed [root@dns2 named]# named -v BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5 [root@dns2 named]# 2- Copied dns1:/etc/named.conf from primary server (dns1) onto dns2 and chown it: [root@dns2 ~]# ls -l /etc/named.conf -rw-r--r-- 1 root named 2876 May 3 09:30 /etc/named.conf [root@dns2 ~]# chown root:named /etc/named.conf 3- Tried starting named: [root@dns2 ~]# /usr/sbin/named 4- I get the "couldn't open pid file '/var/run/named/named.pid': Permission denied" as follows: [root@dns2 ~]# grep named /var/log/messages May 3 10:13:51 dns2 named[19084]: starting BIND 9.3.6-P1-RedHat-9.3.6-16.P1.el5 May 3 10:13:51 dns2 named[19084]: found 4 CPUs, using 4 worker threads May 3 10:13:51 dns2 named[19084]: using up to 4096 sockets May 3 10:13:51 dns2 named[19084]: loading configuration from '/etc/named.conf' May 3 10:13:51 dns2 named[19084]: max open files (1024) is smaller than max sockets (4096) May 3 10:13:51 dns2 named[19084]: using default UDP/IPv4 port range: [1024, 65535] May 3 10:13:51 dns2 named[19084]: using default UDP/IPv6 port range: [1024, 65535] May 3 10:13:51 dns2 named[19084]: listening on IPv4 interface lo, 127.0.0.1#53 May 3 10:13:51 dns2 named[19084]: listening on IPv4 interface eth0, 206.117.120.26#53 May 3 10:13:51 dns2 named[19084]: command channel listening on 127.0.0.1#953 May 3 10:13:51 dns2 named[19084]: command channel listening on ::1#953 May 3 10:13:51 dns2 named[19084]: couldn't open pid file '/var/run/named/named.pid': Permission denied May 3 10:13:51 dns2 named[19084]: exiting (due to early fatal error) [root@dns2 ~]# Please advise if there more steps to be performed on dns2, if I'm missing something, or if I did something wrong. Many thanks in advance. SA ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC submit of DLV vs DNSKEY records?
On 05/05/11 22:47, dchilton+b...@bestmail.us wrote: > "missed it by THAT much ...". thx! relocating to bind-users. > > On Thu, 05 May 2011 14:37 -0500, "/dev/rob0" wrote: >> FWIW I think you hit the wrong list. Did you mean bind-users@isc? > > >> On Thu, May 05, 2011 at 12:25:27PM -0700, dchilton+b...@bestmail.us >>wrote: >>> after signing my zones with 'dnssec-signzone', i 've got both >>> >>> dsset-domain.com >>> dlvset-domain.com >>> >>> containing DS- and DLV-records, respectively. >>> >>> i know i *can* submit the records to my registrar (DS records) >>> and dlv.isc.org (DLV records), but should I do both? >>> >>> i'm not clear if these are redundant mechs for getting to a >>> 'valid' DNSSEC state, or complementary. >>> >>> can anyone clarify -- both or just one? and if just one, which >>> one? >> >> [I hope someone will correct me if I'm wrong.] >> >> My understanding: if the parent is signed, that is the only way a >> child zone can be validated, unless of course using trusted-keys. >> DLV is only done when the parent is unsigned. DLV can be done anyway, but having a signed parent is better. Consider this situation: you have signed parent, but not a chain to root (i.e. an island of trust). This makes your zone unvalidabe to anyone that doesn't trust that island. now, if you have a DLV record, than anyone trusting it can also validate your zone. If, OTOH, one trusts parent, then why should he bother checking DLV? Having a signed parent won't stop anyone from lookng at DLV (signed != trusted). Anyway, .com is now signed and if you can put DS in .com than putting it in DLV as well is overkill. Torinthiel signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC submit of DLV vs DNSKEY records?
"missed it by THAT much ...". thx! relocating to bind-users. On Thu, 05 May 2011 14:37 -0500, "/dev/rob0" wrote: > FWIW I think you hit the wrong list. Did you mean bind-users@isc? > On Thu, May 05, 2011 at 12:25:27PM -0700, dchilton+b...@bestmail.us >wrote: > > after signing my zones with 'dnssec-signzone', i 've got both > > > > dsset-domain.com > > dlvset-domain.com > > > > containing DS- and DLV-records, respectively. > > > > i know i *can* submit the records to my registrar (DS records) > > and dlv.isc.org (DLV records), but should I do both? > > > > i'm not clear if these are redundant mechs for getting to a > > 'valid' DNSSEC state, or complementary. > > > > can anyone clarify -- both or just one? and if just one, which > > one? > > [I hope someone will correct me if I'm wrong.] > > My understanding: if the parent is signed, that is the only way a > child zone can be validated, unless of course using trusted-keys. > DLV is only done when the parent is unsigned. > > Off to the registrar you go! > -- > Offlist mail to this address is discarded unless > "/dev/rob0" or "not-spam" is in Subject: header > ___ > dhcp-users mailing list > dhcp-us...@lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) failed)
Hello All, Thanks Evan. Should the Community expect a BIND 9.7.3 train update/maintenance release which, among other things, addresses this mem.c issue? If so, any ETA? It is not my intent to sound pushy. Let me explain. We were in the process of rolling 9.7.3 out but we stopped figuring a maintenance release may be available in the near future. We have a sense of urgency as 9.7.3 fixes some things broke in 9.7.2-P2; however, we'd like to deploy the latest/greatest 9.7 version available. Alternatively, I would entertain the idea of rolling out an update/maintenance release of 9.8 if such an animal may emerge soon. I mention this in case this is relevant to any recommendations ISC may have. Thoughts? Thank you. - Original Message > From: Evan Hunt > To: "Khuu, Linh Contractor" > Cc: Bind Users Mailing List > Sent: Tue, April 12, 2011 10:50:05 AM > Subject: Re: named crashed (mem.c:1099: INSIST(ctx->stats[i].gets == 0U) >failed) > > > daemon:crit named[221184]: mem.c:1099: INSIST(ctx->stats[i].gets == 0U) >failed > > daemon:crit named[221184]: exiting (due to assertion failure) > > > > named restarted fine and running without any problem. Does anyone have > > any idea why named crashed with these errors??? Is it a bug in bind?? > > We're running bind 9.7.3. > > Yes, it's definitely a bug (named should never have an assertion failure). > Please send as much information as you can (named -V output, named.conf, > logs, etc) to bind9-b...@isc.org. > > In this case, that doesn't look like a crash to me, though. That's the > error you see when you're shutting down named in the usual way (i.e., > kill -INT or rndc stop) and it detects during shutdown that some memory > had been allocated but not freed. If you run named with the "-m record" > option, it will list in the log exactly where all the unfreed blocks of > memory had been allocated. That record-keeping has an impact on > performance, but it can help a lot with locating the problem. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > 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: how to check if a slave zone is expired
On 05/05/2011 04:35, Chris Thompson wrote: On May 4 2011, Doug Barton wrote: On 05/04/2011 01:22, hugo hugoo wrote: So..no way to check that a zone is expired? You're asking the wrong question. The correct question is, "How can I make sure that a zone is up to date on all of the slaves?" You do that by querying the SOA record for the zone on each slave and compare the serial number to the master. This isn't necessarily the "right question". It is perfectly possible for a slave's copy of a zone to be up to date, but still be about to expire, because the slave has been unable to *confirm* that it is up to date for the expiry period (due to network problems, configuration errors, or whatever). Sorry, I should have said, "Given the precondition you've established that you don't want to look at the logs ..." There is no way to tell if a zone is about to expire on the slave without looking at the logs, so querying for the SOA is the only option available. If the query fails, you know that the zone has expired. :) -- 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/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: forward first: iterative or recursive query
If recursion is disabled, forwarding doesn't happen. I think you've confused
some terms and configurations.
Don't use forwarding from a recursive server to a non-recursive server. Use a
stub zone instead, if you can't rely on the recursion process to find the
correct server to query.
If server 2 is auth-only or otherwise can't resolve the address of www.abc.com,
then forwarding a query to it is not going to work. However, if server 1 is a
caching server and is able to resolve www.abc.com, then using a stub zone for
example.com will work; server 2 will send the CNAME record to server 1, and
then server 1 will resolve the final address record on its own.
Chris Buxton
BlueCat Networks
On May 5, 2011, at 2:15 AM,
wrote:
> Hi,
> i have a server called server1 that is acting as a cache server( recursion
> none). And i forward the zone example.com to server2 which has recursion
> enabled and master on some zone like example.com.
> this is the forwarding zone on server1:
> zone "example.com" {
> type forward;
> forward only;
> forwarders { IP_of server2; };
> };
> and server2 is master of the zone example.com:
>
> zone "example.com" {
> type master;
> file "master/db.example.com";
> };
>
>
> BUT the problem is here:
> db.example.com:
>
> $ORIGIN example.com.
> www A1.2.3.4
> ftp CNAME www.abc.com
>
>
>
> server1 can resolve www.example.com, but can't resolve ftp.example.com since
> the server2 sends the answer which is www.abc.com and not the IP, and my
> server1 can't make recursion to resolve www.abc.com.
>
> why?
> from server1 when i dig on server2: dig @IP-server2 www.example.com it sends
> to me the IP, all is OK!!! but with a forwarding statement it sends only the
> CNAME
>
> server1 is bind9.6-ESV-R4 et server2 bind-9.4.2
>
> Thanks.
> Issam HARRATHI
>
> De : Chris Buxton [mailto:chris.p.bux...@gmail.com]
> Envoyé : mercredi 4 mai 2011 08:49
> À : HARRATHI Issam Ext OLNC/DPS
> Cc : bind-users@lists.isc.org
> Objet : Re: forward first: iterative or recursive query
>
> With a static-stub zone, you would get an iterative query. Forwarding always
> results in a recursive query.
>
> How are you determining that your server is sending an iterative query?
>
> Can we (the list) see your named.conf?
>
> Regards,
> Chris Buxton
> BlueCat Networks
>
> On May 3, 2011, at 5:21 AM,
> wrote:
>
>> Hi
>> from the book DNS and Bind 5th edition [french] (o'reilly)
>> I read that the forward with the mode first sends a recursive query to the
>> servers on the forwarders list, but as i see it only sends an iterative
>> query. Also with forward only it send an itérative query.
>> So forward first send an itérative or recursive query?
>>
>> And how i can send a recursive query with the statement forward ( without
>> using static-stub)
>> I'm using bind-9.6-ESV-R4
>>
>> Thanks.
>> Issam HARRATHI.
>>
>> IMPORTANT.Les informations contenues dans ce message electronique y compris
>> les fichiers attaches sont strictement confidentielles
>> et peuvent etre protegees par la loi.
>> Ce message electronique est destine exclusivement au(x) destinataire(s)
>> mentionne(s) ci-dessus.
>> Si vous avez recu ce message par erreur ou s il ne vous est pas destine,
>> veuillez immediatement le signaler a l expediteur et effacer ce message
>> et tous les fichiers eventuellement attaches.
>> Toute lecture, exploitation ou transmission des informations contenues dans
>> ce message est interdite.
>> Tout message electronique est susceptible d alteration.
>> A ce titre, le Groupe France Telecom decline toute responsabilite notamment
>> s il a ete altere, deforme ou falsifie.
>> De meme, il appartient au destinataire de s assurer de l absence de tout
>> virus.
>>
>> IMPORTANT.This e-mail message and any attachments are strictly confidential
>> and may be protected by law. This message is
>> intended only for the named recipient(s) above.
>> If you have received this message in error, or are not the named
>> recipient(s), please immediately notify the sender and delete this e-mail
>> message.
>> Any unauthorized view, usage or disclosure ofthis message is prohibited.
>> Since e-mail messages may not be reliable, France Telecom Group shall not be
>> liable for any message if modified, changed or falsified.
>> Additionally the recipient should ensure they are actually virus free.
>>
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> IMPORTANT.Les informations contenues dans ce message electronique y compris
> les fichiers attach
Problems in views in a zone transfer
Hi all, I'm using bind as frontend solution and I have another server as backend and I'm implementing zone transfer between the two (bind is the slave and my server is the master). The problem is that I want to use dns views. Bind supports it but my backend server is currently not supporting. I'm trying to find a way for distinguish the zone transfer requests for each view. I have two solutions: My first solution is to distinguish based on the view transfer-source IP:Port address (I think it is going to work). My second solution (which would be great if it worked) is based on the zone address that I'm sending in the request. For example, for view 1, I would insert in the zone id something like this "example.com.view1" and for zone 2 "example.com.view2". My server would detect the zone and remove it answering with just "example.com". Do you think bind would accept this? Many thanks, Luis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.8 for openSUSE / SLES
on Wednesday 04 May 2011 Flex Banana wrote: > Anyone have the link or the software for obtaining (if exist) the rpm > x86_64 compiled for openSUSE-11.4 / SLES-11 of bind-9.8.0 ? > > The last release offered by the community is 9.7.3 as of this writing. I have submitted a 9.8.0 You can download it here: http://download.opensuse.org/repositories/network/ -- ciao, Uwe Gansert Uwe Gansert SUSE LINUX Products GmbH, HRB 16746 (AG Nürnberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer Business: http://www.suse.de/~ug listening to: "The Hunter" by Iced Earth ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to check if a slave zone is expired
On May 4 2011, Doug Barton wrote: On 05/04/2011 01:22, hugo hugoo wrote: So..no way to check that a zone is expired? You're asking the wrong question. The correct question is, "How can I make sure that a zone is up to date on all of the slaves?" You do that by querying the SOA record for the zone on each slave and compare the serial number to the master. This isn't necessarily the "right question". It is perfectly possible for a slave's copy of a zone to be up to date, but still be about to expire, because the slave has been unable to *confirm* that it is up to date for the expiry period (due to network problems, configuration errors, or whatever). If Mark Andrews' "EDNS Expire Option" I-D had taken off, one would be able to use that to test time-to-expiry for a zone from outside the server, rather than messing about with the modification times of the master files. But sadly, it didn't ... -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to check if a slave zone is expired
On 5/4/11 10:22 AM, hugo hugoo wrote:
>
> So..no way to check that a zone is expired?
Hello Hugo,
I recently wrote a small script which mails me about any zones that is due to
expire within the next 24 hours. This works by using the last change time of
the file on disk and the SOA expiry time. It is a bit hackish but produces a
report telling you when a zone will expire, including zones that will expire in
the past. If anyone has any improvements on this i would welcome comments
==
#!/bin/sh
ZONEDIR=/var/named/zones/
EMAIL=em...@example.com
TOMORROW=$(/bin/date --date="tomorrow" +%s)
cd ${ZONEDIR}
for zone in $(/bin/ls -1 | /bin/grep -v \.jnl$);
do
zone_lastupdated=$(/usr/bin/stat -c %Z ${zone});
expiry=$(/usr/bin/dig +short SOA ${zone} @localhost 2>/dev/null|
/usr/bin/awk '{print $6}') ;
zone_expires=$((zone_lastupdated + expiry));
if [ ${zone_expires} -le ${TOMORROW} ]; then
echo ${zone} Expires on $(/bin/date --date "$[$(/bin/date
+%s)-${zone_expires}] seconds ago");
fi
done | /bin/mail -s "Zones which expire in the next 24 hours" ${EMAIL}
==
Regards
John
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: forward first: iterative or recursive query
Hi,
i have a server called server1 that is acting as a cache server( recursion
none). And i forward the zone example.com to server2 which has recursion
enabled and master on some zone like example.com.
this is the forwarding zone on server1:
zone "example.com" {
type forward;
forward only;
forwarders { IP_of server2; };
};
and server2 is master of the zone example.com:
zone "example.com" {
type master;
file "master/db.example.com";
};
BUT the problem is here:
db.example.com:
$ORIGIN example.com.
www A1.2.3.4
ftp CNAME www.abc.com
server1 can resolve www.example.com, but can't resolve
ftp.example.com since the server2 sends the answer which
is www.abc.com and not the IP, and my server1 can't make
recursion to resolve www.abc.com.
why?
from server1 when i dig on server2: dig @IP-server2
www.example.com it sends to me the IP, all is OK!!! but
with a forwarding statement it sends only the CNAME
server1 is bind9.6-ESV-R4 et server2 bind-9.4.2
Thanks.
Issam HARRATHI
De : Chris Buxton [mailto:chris.p.bux...@gmail.com]
Envoyé : mercredi 4 mai 2011 08:49
À : HARRATHI Issam Ext OLNC/DPS
Cc : bind-users@lists.isc.org
Objet : Re: forward first: iterative or recursive query
With a static-stub zone, you would get an iterative query. Forwarding always
results in a recursive query.
How are you determining that your server is sending an iterative query?
Can we (the list) see your named.conf?
Regards,
Chris Buxton
BlueCat Networks
On May 3, 2011, at 5:21 AM,
mailto:iharrathi@orange-ftgroup.com>>
mailto:iharrathi@orange-ftgroup.com>>
wrote:
Hi
from the book DNS and Bind 5th edition [french] (o'reilly)
I read that the forward with the mode first sends a recursive query to the
servers on the forwarders list, but as i see it only sends an iterative query.
Also with forward only it send an itérative query.
So forward first send an itérative or recursive query?
And how i can send a recursive query with the statement forward ( without using
static-stub)
I'm using bind-9.6-ESV-R4
Thanks.
Issam HARRATHI.
IMPORTANT.Les informations contenues dans ce message electronique y compris les
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s)
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine,
veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.
IMPORTANT.This e-mail message and any attachments are strictly confidential and
may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s),
please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be
liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
IMPORTANT.Les informations contenues dans ce message electronique y compris les
fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s)
mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine,
veuillez immediatement le signaler a l expediteur et effacer ce message
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce
message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s
il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.
IMPORTANT.Th
