<br><font size=2 face="sans-serif">Thanks Mark.</font>
<br><font size=2 face="sans-serif">Can somebody provide me list of </font><font size=2><tt> </tt></font><font size=2 face="sans-serif">parent
zone which has already signed? or any website to get this information?</font>
<br>
<br><font size=2 face="sans-serif">Also not understood about SEP. Can you
please tell me what is the full form of that?</font>
<br>
<br><font size=2 face="sans-serif">Thanks and regards, <br>
Chandan Laskar <br>
2nd Floor Data Center, ITC Center, <br>
4, Russel Street, Kolkata - 700 016 <br>
Phone:(033)-22889900 Extn.: 3944       <br>
             (0)-9830057396 (M)    
  </font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mark Andrews <Mark_Andrews@isc.org></b>
</font>
<br><font size=1 face="sans-serif">Sent by: Mark_Andrews@isc.org</font>
<p><font size=1 face="sans-serif">04/09/2009 05:15 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Chandan Laskar <Chandan.Laskar@itc.in></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Bill Larson <wllarso@swcp.com>,
bind-users@lists.isc.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Necessity of DNSSEC Lookaside Validation(DLV)</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2><tt><br>
In message <OFD3C12B6C.284D328A-ON65257592.005EC291-65257593.002C48F5@itc.co.in>,
Chandan Laskar writes:<br>
><br>
> Thanks Bill.<br>
> <br>
> We have authoritative Name Server. Caching is not enable in the Name
<br>
> Server.<br>
> <br>
> Also based on website <br>
> (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is
not an <br>
> IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the
current <br>
> recommended implementation Version. <br>
<br>
                
DLV fits into this section of RFC 4035.<br>
<br>
5.  Authenticating DNS Responses<br>
<br>
                
      The process for obtaining and authenticating this
initial<br>
   trust anchor is achieved via some external mechanism.  For
example, a<br>
   resolver could use some off-line authenticated exchange to obtain
a<br>
   zone's DNSKEY RR or to obtain a DS RR that identifies and<br>
   authenticates a zone's DNSKEY RR.  <br>
                
<br>
> So I am still not convince about the necessity of DLV incorporation
in our <br>
> Setup.<br>
<br>
                
For an authoritative only setup I would be using TSIG to validate<br>
                
the zone transfers as you have a existing trust relationship.<br>
<br>
                
If you want other people to be able to validate the data<br>
                
you publish you need to sign your zone and publish your<br>
                
SEP's.  If you parent zone is not signed you can use DLV<br>
                
as a substitute for the parent zone.<br>
 <br>
                
Mark<br>
> Will grateful if you provide me more suggestion.<br>
> <br>
> Thanks and regards, <br>
> Chandan Laskar <br>
> 2nd Floor Data Center, ITC Center, <br>
> 4, Russel Street, Kolkata - 700 016 <br>
> Phone:(033)-22889900 Extn.: 3944 <br>
>              (0)-9830057396 (M)
<br>
> <br>
> <br>
> <br>
> Bill Larson <wllarso@swcp.com> <br>
> 04/07/2009 09:30 PM<br>
> <br>
> To<br>
> Chandan Laskar <Chandan.Laskar@itc.in><br>
> cc<br>
> bind-users@lists.isc.org<br>
> Subject<br>
> Re: Necessity of DNSSEC Lookaside Validation(DLV)<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote:<br>
> <br>
> Hi, <br>
> We have deployed DNS  on RHEL 5 Update 1. Below are feature of
our DNS. <br>
> <br>
1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow <br>
> passwords, Root Login Console Restricted, Configure SSH as an alternative
<br>
> of Telnet e.t.c.). <br>
> 2. Configured Openssl Version 0.9.8j. <br>
> 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not
<br>
> running as root user. <br>
> 4. IPTABLES has been configured to block all the irrelevant ports.<br>
> 5. Allow Update Feature in named.conf is not changed. So, by default
it is <br>
> 'NO' <br>
>  <br>
> After all the above mentioned protection do we really need to incorporate
<br>
> DNSSEC Lookaside Validation(DLV) in our DNS? <br>
> <br>
> Suggestion Please. <br>
> <br>
> Your implementation is protecting the DNS server itself - very good.
 The <br>
> purpose of DLV is to insure that the DNS data that your server provides,
<br>
> and all DNSSEC data your server processes, is valid. <br>
> <br>
> The DNSSEC/DLV configuration protects your DNS data from being "spoofed"
<br>
> on another DNS server.  It also insures that the DNS data that
your server <br>
> may be handing out recursively from being compromised.  Protecting
both <br>
> sides of the DNS service for your users is necessary (at least important).<br>
> <br>
> <br>
> Can you avoid printing this?<br>
> Think of the environment before printing the email.<br>
-- <br>
Mark Andrews, ISC<br>
1 Seymour St., Dundas Valley, NSW 2117, Australia<br>
PHONE: +61 2 9871 4742              
  INTERNET: Mark_Andrews@isc.org<br>
</tt></font>
<br>
<table><tr><td bgcolor=#ffffff><font color=#000000>Can you avoid printing this?<br>
Think of the environment before printing the email.<br>
-------------------------------------------------------------------------------<br>
Please visit us at www.itcportal.com<br>
******************************************************************************<br>
This Communication is for the exclusive use of the intended recipient (s) and shall<br>
not attach any liability on the originator or ITC Ltd./its Subsidiaries/its Group <br>
Companies. If you are the addressee, the contents of this email are intended for your <br>
use only and it shall not be forwarded to any third party, without first obtaining <br>
written authorisation from the originator or ITC Ltd./its Subsidiaries/its Group <br>
Companies. It may contain information which is confidential and legally privileged<br>
and the same shall not be used or dealt with by any third party in any manner <br>
whatsoever without the specific consent of ITC Ltd./its Subsidiaries/its Group <br>
Companies.<br>
</font></td></tr></table>