From owner-dns-security Tue Jun 3 10:46:13 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17641 for dns-security-outgoing; Tue, 3 Jun 1997 10:44:23 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-as-map-04.txt Date: Tue, 03 Jun 1997 09:55:36 -0400 Message-ID: <9706030955.aa06868@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-04.txt Pages : 8 Date : 06/02/1997 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970602151701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970602151701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Tue Jun 3 10:46:16 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id KAA17634 for dns-security-outgoing; Tue, 3 Jun 1997 10:43:53 -0400 (EDT) To: IETF-Announce@ietf.org cc: dns-security@tis.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnssec-as-map-04.txt Date: Tue, 03 Jun 1997 09:55:36 -0400 Message-ID: <9706030955.aa06868@ietf.org> Sender: owner-dns-security@ex.tis.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Security Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Mapping Autonomous Systems Number into the Domain Name System Author(s) : D. Eastlake Filename : draft-ietf-dnssec-as-map-04.txt Pages : 8 Date : 06/02/1997 One requirement of secure routing is that independent routing entities, such as those identified by Internet Autonomous System Numbers, be able to authenticate messages to each other. Additions have developed to the Domain Name System to enable it to be used for authenticated public key distribution [RFC 2065]. This draft maps all Autonomous System numbers into DNS Domain Names so that the DNS can be used to distribute their public keys. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnssec-as-map-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-as-map-04.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970602151701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnssec-as-map-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnssec-as-map-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970602151701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dns-security Fri Jun 6 16:31:42 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA16026 for dns-security-outgoing; Fri, 6 Jun 1997 16:28:54 -0400 (EDT) Message-Id: <33985A96.11F7@sunoco.nswc.navy.mil> Date: Fri, 06 Jun 1997 14:44:38 -0400 From: David Page X1566 Organization: Naval Surface Warfare Center Dahlgren Division X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5.1 sun4m) Mime-Version: 1.0 To: dns-security@tis.com Subject: simple question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dns-security@ex.tis.com Precedence: bulk I'm trying to implement the DNSSEC (sec_bind-b1.4.0) under Linux. I've successfully compiled and run the simple and complex tests included with the distribution. HOWEVER, I'm confused as to how verification occurs. When I run the dig tool, the output returns the expected RR and SIG. My question is how do I verify the SIG? Or, does dig *automatically* verify everything? What about gethostbyname? --Dave PS I apologize if this question is inappropriate for this group. If so, can you please point me in the right direction? -- David L. Page (dlpage@nswc.navy.mil) Naval Surface Warfare Center, Dahlgren, Virginia 22448 USA N90 office tel: 540.653.1058 fax: 540.653.1596 lab: 540.653.1058 B35 office tel: 540.653.1566 fax: 540.653.8763 lab: 540.653.1520 From owner-dns-security Mon Jun 9 09:19:34 1997 Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id JAA02885 for dns-security-outgoing; Mon, 9 Jun 1997 09:16:45 -0400 (EDT) X-Sender: lewis@pop.hq.tis.com Message-Id: In-Reply-To: <33985A96.11F7@sunoco.nswc.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Jun 1997 09:23:10 -0400 To: David Page X1566 From: Edward Lewis Subject: Re: simple question Cc: dns-security@tis.com Sender: owner-dns-security@ex.tis.com Precedence: bulk At 2:44 PM -0400 6/6/97, David Page X1566 wrote: >My question is how do I verify the SIG? Or, does dig *automatically* >verify everything? What about gethostbyname? dig doesn't verify the SIG. The SIG, created by the signer (which is a source code half-sibling of the name server) is verified by the name server as the master file is read. --------- ---------- ---------- | | Query | | Recurse Query | | | dig |----------->| recurse|-------------->| auth | | | | | Auth answer | | | |<- - - - - -| |<--------------| | --------- ---------- ---------- ^ |-----This is where a verification happens, before answer is cached and sent back to dig Assume you were to have two name servers running, with one being authoritative and the other recursive. Assume a query is issued to the recursive one for data authoritatively belonging to the other server. In this case, the recursive name server will perform a verification as it learns the data. If the verification passes the data is cached and the answer sent to the client (dig). Yes, this means that the line from the local default nameserver to the client machine is 'unprotected' by this. The DNSSEC work secures transfers between any two name servers. Clients may also wish to perform the verification, but it is resource intensive. There is a proposal (TSIG) in the works to 'secure' the link to the client (resolver, e.g., dig). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis Trusted Information Systems Phone: +1 301-854-5794 Email: lewis@tis.com Opinions expressed are property of my evil twin, not my employer.