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.comhttp://www.abc.com
server1 can resolve www.example.comhttp://www.example.com, but can't resolve
ftp.example.comftp://ftp.example.com since the server2 sends the answer which
is www.abc.comhttp://www.abc.com and not the IP, and my server1 can't make
recursion to resolve www.abc.comhttp://www.abc.com.
why?
from server1 when i dig on server2: dig @IP-server2
www.example.comhttp://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,
iharrathi@orange-ftgroup.commailto:iharrathi@orange-ftgroup.com
iharrathi@orange-ftgroup.commailto: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.orgmailto: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
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: 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: 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
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: 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, iharrathi@orange-ftgroup.com
iharrathi@orange-ftgroup.com 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, iharrathi@orange-ftgroup.com
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
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: 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 e...@isc.org To: Khuu, Linh Contractor linh.k...@ssa.gov Cc: Bind Users Mailing List bind-users@lists.isc.org 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: 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 r...@gmx.co.uk 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
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?calculatoradvversion=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 security-offi...@isc.org. -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
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
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 r...@gmx.co.uk 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: DNSSEC submit of DLV vs DNSKEY records?
On Fri, 06 May 2011 12:45 +1000, Mark Andrews ma...@isc.org 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: Problems in views in a zone transfer
2011/5/6 Luis Silva luisfilsi...@gmail.com: 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
