From owner-dns-security Wed Jan 8 16:01:29 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA19077 for dns-security-outgoing; Wed, 8 Jan 1997 15:56:35 -0500 (EST) Date: Wed, 8 Jan 97 15:58:33 EST From: sandy@tis.com (Sandy Murphy) Message-Id: <9701082058.AA18530@sol.hq.tis.com> To: dns-security@tis.com Subject: RFC 2065 obsoletes RFC1035 ?!?!?!?!? Cc: sandy@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk In the current rfc-index.txt: # RFC INDEX # ------------- 1/7/1997 ... 2065 PS D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", 01/03/1997. (Pages=41) (Format=.txt) (Updates RFC1034) (Obsoletes RFC1035) ^^^^^^^^^ ... 1035 S P. Mockapetris, "Domain names - implementation and specification", 11/01/1987. (Pages=55) (Format=.txt) (Obsoletes RFC0973) (STD 13) (Obsoleted by RFC2065) (Updated by RFC1348, RFC1995, RFC1996) ^^^^^^^^^^^^ This can hardly be right. My guess (:-)) is that the "obsoletes/obsoleted by" is an error. Should be "updates/updated by". --Sandy Murphy (msg already sent to rfc-ed@isi.edu and namedroppers@internic.net) From owner-dns-security Wed Jan 8 16:11:54 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19283 for dns-security-outgoing; Wed, 8 Jan 1997 16:11:07 -0500 (EST) X-Sender: galvin@inside.east.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 16:16:08 -0500 To: namedroppers@internic.net, dns-security@tis.com From: "James M. Galvin" Subject: Joint DNSSEC/DNSIND Meeting Minutes Sender: owner-dns-security@ex.tis.com Precedence: bulk The following minutes were submitted for inclusion in the IETF proceedings. enjoy, Jim -------- The DNSSEC and DNSIND working groups met jointly on wednesday, December 11. The agenda was as follows: Introductions Implementation Status Documents draft-ietf-dnsind-dynDNS-11.txt draft-ietf-dnssec-update-02.txt Although it has been announced on the mailing list for some time, Trusted Information Systems (TIS) announced the global availability of their DNSSEC implementation; it has been approved for export in source code form. Note, the source code does not include the cryptographic functions. These are available separately in the US by acquiring RSAREF and outside the US by acquiring RSAEURO. John Gilmore was thanked for his expertise and advice in assisting TIS during the export application process. TIS reported that their implementation of DNSSEC is currently being integrated with the latest version of bind. The completion of this will permit bind to be distributed with support for secure DNS. In parallel they have begun implementing the secure dynamic update specifications. John Gilmore reported that support for SIG and KEY records is in the current production release of BIND (4.9.5). This support allows the RR's to be published and queried, but does no cryptographic validation. You can generate these records using the offline signer in TIS's beta release. The same support, plus additional support for NXT records is already in BIND 8.x, and he is actively working on merging the rest of TIS's DNSSEC into it. In addition, two of the root/com servers are running 4.9.5 and could publish keys and signatures (the rest will have to upgrade to make it possible for the IANA or the InterNIC to publish keys or signature). Paul Vixie reported that the latest version of bind currently supports the latest version of dynamic update without security. In closing, the working group was asked if there were any serious technical objections to the advancement of the two principal documents before them. The dynamic udpate document (dnsind-dynDNS) is in IETF Last Call pending the advancement of the secure dynamic update document (dnssec-update). A technical issue was raised in the secure dynamic update draft (dnssec-update) as to the infeasibility of the reverse key mapping. Since it is not an essential part of the secure update mechanism, it was decided to defer the issue to the mailing list and to move that section of the document to a separate document, thus permiting the advancement of the base document. With this one editorial change it was the consensus of the working groups to submit the secure dynamic update draft (dnssec-update) to the IESG to be considered for publication as a Proposed Standard. All discussion of future work of the working groups was deferred to their respective mailing lists and the meeting adjourned. ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Wed Jan 8 16:59:52 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA19599 for dns-security-outgoing; Wed, 8 Jan 1997 16:59:39 -0500 (EST) Date: Wed, 8 Jan 1997 16:59:51 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Sandy Murphy Cc: dns-security@tis.com Subject: Re: RFC 2065 obsoletes RFC1035 ?!?!?!?!? In-Reply-To: <9701082058.AA18530@sol.hq.tis.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk It's a typo in the index. If you actually look at RFC 2065, it says "updates." Donald On Wed, 8 Jan 1997, Sandy Murphy wrote: > Date: Wed, 8 Jan 97 15:58:33 EST > From: Sandy Murphy > To: dns-security@tis.com > Cc: sandy@tis.com > Subject: RFC 2065 obsoletes RFC1035 ?!?!?!?!? > > In the current rfc-index.txt: > > # RFC INDEX # > ------------- > > 1/7/1997 > ... > > 2065 PS D. Eastlake, C. Kaufman, "Domain Name System Security Extensions", > 01/03/1997. (Pages=41) (Format=.txt) (Updates RFC1034) > (Obsoletes RFC1035) > ^^^^^^^^^ > ... > > 1035 S P. Mockapetris, "Domain names - implementation and specification", > 11/01/1987. (Pages=55) (Format=.txt) (Obsoletes RFC0973) (STD 13) > (Obsoleted by RFC2065) (Updated by RFC1348, RFC1995, RFC1996) > ^^^^^^^^^^^^ > > This can hardly be right. > > My guess (:-)) is that the "obsoletes/obsoleted by" is an error. Should > be "updates/updated by". > > --Sandy Murphy > > (msg already sent to rfc-ed@isi.edu and namedroppers@internic.net) > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Jan 9 08:47:44 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA24428 for dns-security-outgoing; Thu, 9 Jan 1997 08:45:44 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 9 Jan 1997 08:53:06 -0500 To: dns-security@tis.com From: Edward Lewis Subject: Question on LOC Cc: lewis@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk Ok, I know this is slightly off-topic for this list, but I just minutes ago subscribed to bind-*@vix, and since I don't want to chance missing a response 'cause "I wasn't added right away," and I *know* I'm on this list...I'll ask this here. Does anyone know where the LOC (type=29) is documented? (Wow, four lines to apologize for a 1 line question. ;) ) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Jan 9 10:52:14 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA25520 for dns-security-outgoing; Thu, 9 Jan 1997 10:51:16 -0500 (EST) Message-Id: <3.0.32.19970109075342.00c04100@pop-sb.software.com> X-Sender: WrenP@pop-sb.software.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 07:53:42 -0800 To: Edward Lewis , dns-security@tis.com From: Paul Wren Subject: Re: Question on LOC Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk At 08:53 AM 1/9/97 -0500, Edward Lewis wrote: > >Does anyone know where the LOC (type=29) is documented? > rfc1876.txt From owner-dns-security Thu Jan 9 11:03:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA25621 for dns-security-outgoing; Thu, 9 Jan 1997 11:02:48 -0500 (EST) Date: Thu, 9 Jan 1997 11:02:02 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Edward Lewis Cc: dns-security@tis.com Subject: Re: Question on LOC In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk RFC 1876. Donald On Thu, 9 Jan 1997, Edward Lewis wrote: > Date: Thu, 9 Jan 1997 08:53:06 -0500 > From: Edward Lewis > To: dns-security@tis.com > Cc: lewis@tis.com > Subject: Question on LOC > > Ok, I know this is slightly off-topic for this list, but I just minutes ago > subscribed to bind-*@vix, and since I don't want to chance missing a > response 'cause "I wasn't added right away," and I *know* I'm on this > list...I'll ask this here. > > Does anyone know where the LOC (type=29) is documented? > > (Wow, four lines to apologize for a 1 line question. ;) ) > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis Trusted Information Systems > Phone: 301-854-5794 Email: lewis@tis.com > > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Thu Jan 9 12:17:25 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA26153 for dns-security-outgoing; Thu, 9 Jan 1997 12:16:20 -0500 (EST) X-Sender: galvin@inside.east.commerce.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 9 Jan 1997 12:21:43 -0500 To: iesg-secretary@ietf.org, Jeff Schiller From: "James M. Galvin" Subject: please advance draft-ietf-dnssec-update-03.txt Cc: dns-security@tis.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by portal.ex.tis.com id MAA26150 Sender: owner-dns-security@ex.tis.com Precedence: bulk With this message the DNS Security Working Group is submitting the following internet draft: draft-ietf-dnssec-update-03.txt to the IESG to be considered for publication as a Proposed Standard. Enjoy, Jim ---------------------------------------------------------------------------- James M. Galvin galvin@commerce.net CommerceNet +1 410.203.2707 3209-A Corporate Court FAX +1 410.203.2709 Ellicott City, MD 21042 http://www.commerce.net/ http://www.eff.org/blueribbon http://www.eff.org/goldkey From owner-dns-security Fri Jan 10 09:00:59 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA03291 for dns-security-outgoing; Fri, 10 Jan 1997 08:58:02 -0500 (EST) Date: Fri, 10 Jan 1997 15:01:08 +0100 (MET) From: Pascal SALLOUM To: Pascal SALLOUM Cc: dns-security@tis.com Subject: Re: please advance draft-ietf-dnssec-update-03.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk draft-ietf-dnssec-update-03.txt From owner-dns-security Fri Jan 10 12:40:04 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id MAA05111 for dns-security-outgoing; Fri, 10 Jan 1997 12:36:32 -0500 (EST) To: IETF-Announce cc: dns-security@tis.com From: The IESG Subject: Last Call: Secure Domain Name System Dynamic Update to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 10 Jan 1997 12:21:41 -0500 Message-ID: <9701101221.aa09603@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk The IESG has received a request from the Domain Name System Security Working Group to consider "Secure Domain Name System Dynamic Update" for the status of Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 23, 1997. Files can be obtained via ftp://ds.internic.net/internet-drafts/ From owner-dns-security Wed Jan 15 10:17:05 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11966 for dns-security-outgoing; Wed, 15 Jan 1997 10:11:03 -0500 (EST) Message-ID: <32DCF631.2F1CF0FB@inria.fr> Date: Wed, 15 Jan 1997 16:22:25 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: are there a new release? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk hello does any one know if TIS is preparing a new release of SECDNS? if yes it will based on bind 4.9.5 or bind 8? and when it should be ready. A+ shabou malek From owner-dns-security Wed Jan 15 10:17:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA11989 for dns-security-outgoing; Wed, 15 Jan 1997 10:16:03 -0500 (EST) Message-ID: <32DCF79C.7DE14518@inria.fr> Date: Wed, 15 Jan 1997 16:28:28 +0100 From: Shabou Malek Organization: INRIA X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: dns-security@tis.com Subject: why not IPSEC? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk hello I wonder why DNSSEC do not use IPSEC to make dns secure??? I think that will be sefisant to the server to identifie the client in case of a dynamic update request. and the resolver will be able to authentifie the source of the reponces it gets A+ malek shabou From owner-dns-security Wed Jan 15 11:13:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12409 for dns-security-outgoing; Wed, 15 Jan 1997 11:12:18 -0500 (EST) Date: Wed, 15 Jan 1997 11:12:13 -0500 (EST) From: "Donald E. Eastlake 3rd" To: Shabou Malek Cc: dns-security@tis.com Subject: Re: why not IPSEC? In-Reply-To: <32DCF79C.7DE14518@inria.fr> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dns-security@ex.tis.com Precedence: bulk IPSEC is oriented towards point-to-point security (even though in some cases the points could be complex firewalls). Because of caching, DNS security is actually more like a special type of store and forward message security. In addition, IPSEC is oriented towards being implemented at the kernel level. It is hard to change the OS kernel in many practical situations. Replacing your DNS implementation is usually much easier. (True, there is now a TLS working group working on essentially an application level thing similar in function to IPSEC but (1) the TLS WG didn't exist when DNSSEC was designed and (2) TLS is still point to point oriented rather than oriented towards authenticating data which is stored and forwarded. Note that update requests can also get forwarded. Donald On Wed, 15 Jan 1997, Shabou Malek wrote: > Date: Wed, 15 Jan 1997 16:28:28 +0100 > From: Shabou Malek > To: dns-security@tis.com > Subject: why not IPSEC? > > hello > I wonder why DNSSEC do not use IPSEC to make dns secure??? > > I think that will be sefisant to the server to identifie the client in > case of a dynamic update request. and the resolver will be able to > authentifie the source of the reponces it gets > > > A+ > malek shabou > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-dns-security Wed Jan 15 11:17:20 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12449 for dns-security-outgoing; Wed, 15 Jan 1997 11:17:16 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <32DCF79C.7DE14518@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 11:20:51 -0500 To: Shabou Malek From: Edward Lewis Subject: Re: why not IPSEC? Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:28 AM -0500 1/15/97, Shabou Malek wrote: >hello > I wonder why DNSSEC do not use IPSEC to make dns secure??? IPSEC ensures that what is sent it the same as what is received host to host. DNS uses caching serves, so the client may not be getting the (correct and useable) answer from the true source (authoritative server). The answer may come from a cache, and a cache may become "polluted." True Server \\ \\__________________ Cache_________________ Client // // "Bogus" Server Here's how the Cache may have incorrect information for 'host' even with IPSEC. Assume 'host' is in a zone served by True, and 'name' is in Bogus' zone. The Cache may learn from the Bogus server, e.g., 'name' MX 10 'host.' Bogus may also send along (as additional records) an A record for 'host' which is incorrect. Cache will believe the incorrect 'host' information because it has no other reason to contact the True server, and thus pass on the incorrect info to the Client. Client knows (thru IPSEC) is is in contact with Cache and Cache knows it contacted Bogus. But the information transmitted was wrong. DNSSEC is providing source authentication, meaning that any information can be verified as having been originated at the true source, not slipped into another server. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Jan 15 11:17:24 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA12450 for dns-security-outgoing; Wed, 15 Jan 1997 11:17:17 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <32DCF631.2F1CF0FB@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 Jan 1997 11:05:10 -0500 To: Shabou Malek From: Edward Lewis Subject: Re: are there a new release? Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 10:22 AM -0500 1/15/97, Shabou Malek wrote: >hello > does any one know if TIS is preparing a new release of SECDNS? Olafur has his office doors shut right now, working on it. > if yes it will based on bind 4.9.5 or bind 8? and when it should be >ready. 4.9.5. When - hmmm, real soon now. He's testing the code. > >A+ >shabou malek -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Wed Jan 15 16:34:55 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA14372 for dns-security-outgoing; Wed, 15 Jan 1997 16:31:46 -0500 (EST) Message-Id: <3.0.32.19970115223609.0069499c@gatekeeper.grolier.fr> X-Sender: merlin@gatekeeper.grolier.fr X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 15 Jan 1997 22:36:10 +0100 To: dns-security@tis.com From: Thomas Merlin Subject: What sould we do ? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dns-security@ex.tis.com Precedence: bulk Hello all... I'm not sure this is the appropriate list for my problem but here goes anyway... We are setting up a web site for a governmental institute that needs high security. They don't know yet if they will host their site at their place or at some ISPs. The Nic France is taking care of the domain name which is gouv.fr, and this institute will be a sub-domain, as in institute.gouv.fr If they choose to host the server at home, should they host their DNS server at home too or just rely on the one at there ISPs place ? What are the advantages/disadvantages ? Thanks a lot for your help. Tom. From owner-dns-security Wed Jan 15 18:00:57 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id SAA14854 for dns-security-outgoing; Wed, 15 Jan 1997 18:00:21 -0500 (EST) Message-Id: <199701152300.PAA07920@dns1.ConsumerInfo.Com> Comments: Authenticated sender is From: "Wayne Yu" Organization: ConsumerInfo.Com, Inc. To: dns-security@tis.com, Thomas Merlin Date: Wed, 15 Jan 1997 15:03:14 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: What sould we do ? Reply-to: wyu@ConsumerInfo.Com In-reply-to: <3.0.32.19970115223609.0069499c@gatekeeper.grolier.fr> X-mailer: Pegasus Mail for Win32 (v2.52) Sender: owner-dns-security@ex.tis.com Precedence: bulk > Date: Wed, 15 Jan 1997 22:36:10 +0100 > To: dns-security@tis.com > From: Thomas Merlin > Subject: What sould we do ? > Hello all... > > I'm not sure this is the appropriate list for my problem but here goes > anyway... > > We are setting up a web site for a governmental institute that needs high > security. They don't know yet if they will host their site at their place > or at some ISPs. > > The Nic France is taking care of the domain name which is gouv.fr, and this > institute will be a sub-domain, as in institute.gouv.fr > > If they choose to host the server at home, should they host their DNS > server at home too or just rely on the one at there ISPs place ? > What are the advantages/disadvantages ? > > Thanks a lot for your help. > > Tom. > > They should use more than one DNS servers outside their domain. Normally in their ISP's. Most time, people use three DNS servers to cover different geographic regions, so that if any disaster happend in one region will not impact the site operation. Since they are directly connected to their ISP, the DNS-security is not problem. If they have some computers that are not public accessible in their site, like we do, they may want to maintain couple Internal DNS servers so that the computers within their system can get the name resolved. Just make sure that the external and internal DNS server does not have IP addersses assigned to an empty slot, each IP address must have a computer behind it. Wayne Yu, Director of Technology ConsumerInfo.Com, Inc. Phone (714)978-0078 ext. 1010 Fax (714)978-0059 We provide personal credit information, visit us at http://www.consumerinfo.com From owner-dns-security Thu Jan 16 07:39:48 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id HAA18742 for dns-security-outgoing; Thu, 16 Jan 1997 07:37:58 -0500 (EST) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <3.0.32.19970115223609.0069499c@gatekeeper.grolier.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jan 1997 07:41:27 -0500 To: Thomas Merlin From: Edward Lewis Subject: Re: What sould we do ? Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 4:36 PM -0500 1/15/97, Thomas Merlin wrote: >Hello all... > >I'm not sure this is the appropriate list for my problem but here goes >anyway... Perhaps a better list is bind-users{-request}@vix.com - the list is in the BIND readme. >If they choose to host the server at home, should they host their DNS >server at home too or just rely on the one at their ISPs place ? >What are the advantages/disadvantages ? Each zone should/must/is recommended to have at least two nameservers (I forget the wording). The only criteria for positioning them in the network is that each should be highly available. All you need to achieve is highy availability. From a network technology stance, this is fairly simple. Make sure that nameservers are connected to the public backbone network (e.g., Internet) over dedicated lines. Don't filter traffic away from them. The availablility of the nameserver may be capped by the availability of the hosts for which it serves. I.e., if you site has just one dedicated line to the "net", then it is ok to have the nameservers at your site. If the line goes down, your nameservers are unavailable (to the outside world), but so is your zone. If your zone is spread over many networks behind different dedicated lines, it wouldn't be prudent to have all the nameservers behind just one of the lines. There are logistical issues of operations, which have more bearing. E.g., do you need human intervention for certain events, such as hardware failures or replacements? (Can FedEx deliver a new network card there?) Can you find a suitable environment - humidity, temperature, rack space, spares, and conditioned power? What level of expertise do you need to have a few minutes away? Can you "test" the system/connectivity accurately when you get a user bug report? And there are other "common sense" issues too. I think there is an RFC or draft on requirements for nameservers. I can't locate it off the top of my head. You should check that out too. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: 301-854-5794 Email: lewis@tis.com From owner-dns-security Thu Jan 23 17:26:10 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id RAA26807 for dns-security-outgoing; Thu, 23 Jan 1997 17:22:52 -0500 (EST) Message-Id: <9701232224.AA12289@sol.hq.tis.com> To: dns-security@tis.com Cc: tisdnssec-support@cs.umd.edu Subject: ANNOUNCE: TIS/DNSSEC Beta 1.4 is now available Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <19503.854058310.1@tis.com> Date: Thu, 23 Jan 1997 17:25:16 -0500 From: Olafur Gudmundsson Sender: owner-dns-security@ex.tis.com Precedence: bulk We are pleased to announce the release of the final version of TIS/DNSSEC Beta-1.4. This is a DNS nameserver implementation based upon BIND release 4.9.5-p1, with extensions as described in RFC 2065, "Domain Name System Security Extensions." In particular, support and use of KEY, SIG, and NXT resource records are included in NAMED, and elementary key management executables are included. TIS/DNSSEC requires RSAREF, but does not include it. Our web page (see below) contains a link to a FTP site for RSAREF. This is the final beta release based upon BIND 4.9.5. The functionality of this release will be added to BIND 8. Over time, new features such as support for secure dynamic update will be included - as work in these areas mature. Trusted Information Systems, Inc. has received approval from the United States Government for export and reexport of TIS/DNSSEC software from the United States of America under the provisions of the Export Administration Regulations (EAR) General Software Note (GSN) license exception for mass market software. Under the provisions of this license, this software may be exported or reexported to all destinations except for the embargoed countries of Cuba, Iran, Iraq, Libya, North Korea, Sudan and Syria. Any export or reexport of TIS/DNSSEC software to the embargoed countries requires additional, specific licensing approval from the United States Government. TIS is seeking beta testers for this code. Beta testers are merely requested to share comments and bug reports via the mailing list dns-security@tis.com. Subscribing to the mail list is done through dns-security-request@tis.com. To encourage beta testers, a copy of the security-aware named is running on sd-bogus.hq.tis.com, resolving a zone with the same name. Included in the distribution are new versions of DIG executables for different computing platforms. This version of DIG understands the new resource record formats in RFC 2065. Further information and download instructions are available at: http://www.tis.com/docs/dns.html The package is available at: ftp://ftp.tis.com/pub/DNSSEC/sec_bind-b1.4.0.tar.gz MD5 checksum (sec_bind-b1.4.0.tar.gz) = 17ab57125aacacb4f77492ddbc24731a IMPORTANT: To access the FTP server, a DNS reverse name query must be possible for the client's host. Executable versions of DIG that support DNSSEC are available for sunos4.x, FreeBSD and Linux. ftp://ftp.tis.com/pub/DNSSEC/sdig.sunos.gz ftp://ftp.tis.com/pub/DNSSEC/sdig.freebsd.gz ftp://ftp.tis.com/pub/DNSSEC/sdig.linux.gz Other versions will be made available as ftp:/ftp.tis.com/pub/DNSSEC/sdig..gz If you have any questions or problems obtaining or installing the software, you may send e-mail to tisdnssec-support@tis.com. If you compile DIG on a platform we have not covered, please let us know. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Olafur Gudmundsson ogud@tis.com (301)-854-5700(phone) (301)-854-5363 FAX