Re: BIND and DNSSEC
Thank you for this. Had a look and it seems fairly easy. Not sure if that is a flippant remark. A question: is implementing dnssec a good enough reason to abandon split horizon DNS? Kobus Sent from my iPhone On 1 Nov 2012, at 02:01, Feng He wrote: > 于 2012-10-31 23:05, Kobus Bensch 写道: >> Can anybody point me in the direction of a good guide on setting up BIND >> split horizon DNS and DNSSEC? > > Take a look at: > http://www.dnssec.lk/docs/DNSSEC_in_6_minutes.pdf > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using BIND-DLZ for a hidden master [was: Re: dns master-slave transfer]
2012/11/1 Chris Thompson : > On Oct 29 2012, Feng He wrote: > >> 于 2012-10-29 9:58, kavin 写道: >>> >>> Now，I want transfer the zone data from the master dns serverto slave >>> dns server ,the master dns use bind-dlz+mysql and the slave dns server >>> use bind+file. >> >> >> AFAIK, BIND DLZ doesn't send a notify message to slave, so both your >> master and slave should be able to use the DLZ backend and run a mysql >> replication for data sync. > > > That exchange prompts me to ask whether anyone has managed to use > BIND-DLZ in something like the following scenario. > > We have a hidden master for vanity zones (we call them something else > for the punters) that runs in a small footprint virtual machine > together with the web server providing the updating interface. The > latter stores the data in a MySQL database. > > At the moment there is a crontab that extracts data from that database > and updates zone files (if they need changing - there are some neat-o > optimisations) and does an "rndc reload" on the hidden master daemon. > That NOTIFYs the public nameservers for the zones, which are are in fact > our regular authoritative-only ones. > > It seems that one ought to be able to use BIND-DLZ to cut out a step > there, but none of the how-to's for it seem to address this sort of > scenario, and the NOTIFY issue is particularly relevant. Fast responses > from the hidden master to queries are certainly *not* a requirement here, > and indeed we expect to be able to operate with it (and its MySQL database) > down for significant periods. > > On the other hand, there is also a possibility that we might want to sign > the vanity zones (we use JANET, Nominet and Gandi for their registrations, > who all support signed delegations now), and how that would interact with > BIND-DLZ might also be an issue. Can one use BIND 9.9 "inline signing" > with the unsigned version provided by a DLZ interface? In our case (big zones, distant servers) we have found DLZ very inefficient because of huge overhead due to AXFRs. Another problem is absence of NOTIFIes. As for me the way your system is working now is much more simple, predictable and reliable than DLZ. > > -- > Chris Thompson > Email: c...@cam.ac.uk > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- AP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
In article ,
Mark Andrews wrote:
> In message <5091adef.1040...@dougbarton.us>, Doug Barton writes:
> > On 10/31/2012 03:56 PM, Mark Andrews wrote:
> > > You are equating a practice that was techically wrong, and known
> > > to be wrong from the get go, with one that has never been techically
> > > wrong.
> >
> > Yes, I'm making exactly the same judgment that typical users make. "It
> > works, so it must be Ok."
> >
> > The fact that we ("experts") can get away with something, whether it's
> > technically right/wrong/indifferent not withstanding, doesn't mean that
> > it's good advice for the average user.
> >
> > Doug
>
> Putting in delegations where they are not needed introduces additional
> work and more places that can go wrong.
And also (he said very quietly indeed after delurking) increases the
granularity of management. Being able to reload or work on a small
(sub)zone rather than a large one can have advantages, which of course
have to be balanced with the extra effort involved in setting such a
system up. YPYMAYTYP.
Sam
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 3:02 AM, Kobus Bensch wrote: > Thank you for this. Had a look and it seems fairly easy. Not sure if that is > a flippant remark. As the author of this document, I must say thanks. Deploying DNSSEC is not hard. It's the care and feeding after-the-fact (key rollover) that you must be extremely careful with. > A question: is implementing dnssec a good enough reason to abandon split > horizon DNS? I'd find any excuse to abandon views/split-horizon. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
> YPYMAYTYP Zero results from my favorite search engine -- congratulations. ;-) -JP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
In article , Jan-Piet Mens wrote: > > YPYMAYTYP > > Zero results from my favorite search engine -- congratulations. ;-) Thank you. Try YPYMAYTYC but I was thinking pick. Sam -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
Hi Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Kobus - Original Message - From: "Alan Clegg" To: "Kobus Bensch" Cc: "Feng He" , bind-users@lists.isc.org Sent: Thursday, 1 November, 2012 11:08:10 AM Subject: Re: BIND and DNSSEC On Nov 1, 2012, at 3:02 AM, Kobus Bensch wrote: > Thank you for this. Had a look and it seems fairly easy. Not sure if that is > a flippant remark. As the author of this document, I must say thanks. Deploying DNSSEC is not hard. It's the care and feeding after-the-fact (key rollover) that you must be extremely careful with. > A question: is implementing dnssec a good enough reason to abandon split > horizon DNS? I'd find any excuse to abandon views/split-horizon. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com -- Fullnet Solutions Limited 7 Marlborough Close Maidenhead Berkshire SL6 4LP United Kingdom Telephone: +44 (07703) 503 733 Kobus Bensch: kben...@fullnet.co.uk Information: i...@fullnet.co.uk WWW: http://www.fullnet.co.uk Registered in England & Wales. Company Number: 3568937 VAT registration number: UK 714 7309 42 E & O.E. All prices exclude VAT & Carriage unless otherwise specified. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator by emailing ad...@fullnet.co.uk with the subject "eMail Confidentiality Query!" . The content of this email does not necessarily reflect the views or opinions of Fullnet Solutions Limited. If you have any queries or complaints please email i...@fullnet.co.uk with the subject "eMail Comment/Complaint Query!". This footnote also confirms that this email message has been scanned for the presence of computer viruses. Fullnet Solutions Limited can however not be held responsible for any virus infections on the recipients or any other systems. For more information regarding the solutions Fullnet has to offer please email i...@fullnet.co.uk with the subject "Sales Query!". ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:14 AM, Kobus Bensch wrote: > Is that because split horizon doubles admin or because its bad all together? > > I have been using split horizon for many years now and found it very useful. > Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the "one-question, one-answer" concept that was foundational for DNS. My recommendation is that for "internal" addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at "www.internal.example.com" since you know that the only people able to resolve/route "internal.example.com" are the ones that should be able to). The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that "www.example.com" can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
Feng He wrote: > > Take a look at: > http://www.dnssec.lk/docs/DNSSEC_in_6_minutes.pdf I recommend using "auto-dnssec maintain" so named keeps the zone signed, instead of dnssec-signzone. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
Thanks. All makes sense and definitely something to think about in the new network design. Also wanted to say, I did like the doc and will be using that, but as you say, will make particular note about the maintenance side of things. Thanks Kobus - Original Message - From: "Alan Clegg" To: "Kobus Bensch" Cc: bind-users@lists.isc.org Sent: Thursday, 1 November, 2012 11:26:31 AM Subject: Re: BIND and DNSSEC On Nov 1, 2012, at 7:14 AM, Kobus Bensch wrote: > Is that because split horizon doubles admin or because its bad all together? > > I have been using split horizon for many years now and found it very useful. > Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the "one-question, one-answer" concept that was foundational for DNS. My recommendation is that for "internal" addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at "www.internal.example.com" since you know that the only people able to resolve/route "internal.example.com" are the ones that should be able to). The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that "www.example.com" can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com -- Fullnet Solutions Limited 7 Marlborough Close Maidenhead Berkshire SL6 4LP United Kingdom Telephone: +44 (07703) 503 733 Kobus Bensch: kben...@fullnet.co.uk Information: i...@fullnet.co.uk WWW: http://www.fullnet.co.uk Registered in England & Wales. Company Number: 3568937 VAT registration number: UK 714 7309 42 E & O.E. All prices exclude VAT & Carriage unless otherwise specified. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator by emailing ad...@fullnet.co.uk with the subject "eMail Confidentiality Query!" . The content of this email does not necessarily reflect the views or opinions of Fullnet Solutions Limited. If you have any queries or complaints please email i...@fullnet.co.uk with the subject "eMail Comment/Complaint Query!". This footnote also confirms that this email message has been scanned for the presence of computer viruses. Fullnet Solutions Limited can however not be held responsible for any virus infections on the recipients or any other systems. For more information regarding the solutions Fullnet has to offer please email i...@fullnet.co.uk with the subject "Sales Query!". ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > I recommend using "auto-dnssec maintain" so named keeps the zone signed, > instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > I recommend using "auto-dnssec maintain" so named keeps the zone signed, > instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > I recommend using "auto-dnssec maintain" so named keeps the zone signed, > instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > I recommend using "auto-dnssec maintain" so named keeps the zone signed, > instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > I recommend using "auto-dnssec maintain" so named keeps the zone signed, > instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
> I do as well, and this will be documented in the next version of this > document. I believe you've mentioned that here before. Several times. Today. ;-) -JP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1 2012, Jan-Piet Mens wrote: I do as well, and this will be documented in the next version of this document. I believe you've mentioned that here before. Several times. Today. ;-) "What I tell you three times is true.” The Bellman, pp Lewis Carroll -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
Jan-Piet Mens wrote on 11/01/2012 07:09:14 AM: > > YPYMAYTYP > > Zero results from my favorite search engine -- congratulations. ;-) Yeah, and bing didn't find it either! :) Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On 01/11/12 12:26, Alan Clegg wrote: On Nov 1, 2012, at 7:14 AM, Kobus Bensch wrote: Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the "one-question, one-answer" concept that was foundational for DNS. My recommendation is that for "internal" addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at "www.internal.example.com" since you know that the only people able to resolve/route "internal.example.com" are the ones that should be able to). I believe that thinking is no longer valid with laptops moving around. I assume you don't have enough public addresses to give everything its own address, I don't, my servers work through a NAT. They are behind NAT partly for lack of IPs and partly because I want to keep their other ports away from accidental exposure to script kiddies, I know more concerted efforts will do more harm. The typical server setup (for own servers) is that one name is used for setting up e.g. the mail server, the ideal situation for everybody is that whether I am in house or visiting you, if I have any internet access, I can read and send mail. Now if there is an internal zone with a different name, how will you set up the mail client? internal name is not accessible from outside and external name is not present in internal name space. -> two mail clients? changing setups when moving between networks? My solution is to have the exactly same names internally and externally, any client SW will just ask for the same server but the IP will differ with the network segment. IPv6 will change all that of course. The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that "www.example.com" can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
On Oct 31, 2012, at 4:02 PM, Doug Barton wrote:
> On 10/31/2012 03:56 PM, Mark Andrews wrote:
>> You are equating a practice that was techically wrong, and known
>> to be wrong from the get go, with one that has never been techically
>> wrong.
>
> Yes, I'm making exactly the same judgment that typical users make. "It
> works, so it must be Ok."
>
> The fact that we ("experts") can get away with something, whether it's
> technically right/wrong/indifferent not withstanding, doesn't mean that
> it's good advice for the average user.
I must disagree with my learned colleague here.
Introducing the extra subzone for the current subdomain also introduces extra
work if DNSSEC is later introduced. It can also cause as many problems as it
solves even in the absence of DNSSEC.
As for the possibility of administrator error in the future, and making things
futureproof, I would assert that stumbling when bad assumptions cause problems
is the quickest way to learn the proper rules of DNS. Designing a system to
match the possible wrong-headed assumptions of future admins results in a
system akin to Microsoft's DNS snap-in for MMC, whereby users then develop
mistakes in their thinking about how DNS works and therefore are unable to
properly troubleshoot and fix real problems when they occur.
I would prefer to promote a correct understanding of the actual rules of DNS.
Chris Buxton
BlueCat Networks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegations
On Oct 31, 2012, at 2:31 PM, Kevin Darcy wrote: > I know of at least 2 commerically-available DNS maintenance systems that, by > default, do not allow what they call "dotted hostnames", by which they mean a > name which is at least 2 labels below a zone cut, e.g. "foo.bar" in the > "example.com" zone. Their underlying assumption seems to be that *every* > level of the hierarchy will, in the usual/typical/default case, be delegated. As an employee of a company that makes a DNS management product, I can say that there is a strong temptation to think this way when designing such a product. We have mostly managed to avoid this type of stupidity, but I still get tripped up by it occasionally. When I find it, it gets logged as a bug report, of course, because we have plenty of customers who rely on "dotted records". Chris Buxton BlueCat Networks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind 9.9.2 Clarification
Should I install bind 9.9.0 first and then update to bind 9.9.1 then update to bind 9.9.2? This excerpt from the README file is a little confusing: BIND 9.9.2 BIND 9.9.2 is a maintenance release and patches the security flaw described in CVE-2012-4244. BIND 9.9.1 BIND 9.9.1 is a maintenance release. BIND 9.9.0 BIND 9.9.0 includes a number of changes from BIND 9.8 and earlier releases. Thanks John Manson CAO/HIR/NAF Data-Communications | U.S. House of Representatives | Washington, DC 20515 Desk: 202-226-4244 | TCC: 202-226-6430 | john.man...@mail.house.gov ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind 9.9.2 Clarification
You can install 9.9.2 directly. Doug On 11/01/2012 01:30 PM, Manson, John wrote: > Should I install bind 9.9.0 first and then update to bind 9.9.1 then > update to bind 9.9.2? > This excerpt from the README file is a little confusing: > > BIND 9.9.2 > > BIND 9.9.2 is a maintenance release and patches the security > flaw described in CVE-2012-4244. > > BIND 9.9.1 > > BIND 9.9.1 is a maintenance release. > > BIND 9.9.0 > > BIND 9.9.0 includes a number of changes from BIND 9.8 and earlier > releases. > > Thanks > > John Manson > CAO/HIR/NAF Data-Communications | U.S. House of Representatives | > Washington, DC 20515 > Desk: 202-226-4244 | TCC: 202-226-6430 | john.man...@mail.house.gov > > > > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On Nov 1, 2012, at 7:45 AM, Alan Clegg wrote: > > On Nov 1, 2012, at 7:34 AM, Tony Finch wrote: > >> I recommend using "auto-dnssec maintain" so named keeps the zone signed, >> instead of dnssec-signzone. > > I do as well, and this will be documented in the next version of this > document. Sorry for the spammage. Bad failure mode of mail.app under OSX, it seems. :( AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On 11/1/2012 3:31 PM, Sten Carlsen wrote: The typical server setup (for own servers) is that one name is used for setting up e.g. the mail server, the ideal situation for everybody is that whether I am in house or visiting you, if I have any internet access, I can read and send mail. Now if there is an internal zone with a different name, how will you set up the mail client? internal name is not accessible from outside and external name is not present in internal name space. -> two mail clients? changing setups when moving between networks? In this case, either 1) you have one mail server at the external border and one mail server internal, or 2) the same MX record in the external and internal view. You can have a common records file that you $INCLUDE in both views. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND and DNSSEC
On 02/11/12 2:08, Barry S. Finkel wrote: > On 11/1/2012 3:31 PM, Sten Carlsen wrote: >> The typical server setup (for own servers) is that one name is used for >> setting up e.g. the mail server, the ideal situation for everybody is >> that whether I am in house or visiting you, if I have any internet >> access, I can read and send mail. >> >> Now if there is an internal zone with a different name, how will you set >> up the mail client? internal name is not accessible from outside and >> external name is not present in internal name space. -> two mail >> clients? changing setups when moving between networks? > In this case, either 1) you have one mail server at the external border > and one mail server internal, or 2) the same MX record in the external > and internal view. You can have a common records file that you > $INCLUDE in both views. > --Barry Finkel This will work for smtp service, I see a host of interesting issues with IMAP service. Two mail servers that must be synchronized within a minute, I don't think that is standard. The simple solution (small scale) is to have one server, sitting internally or in DMZ, the internal address record points to the 192.168.x.x address and the external address record points to the public address of the router, which then has a virtual server set up for it. This works flawless, I never consider if I am in or out of the house. -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
