Re: Necessity of DNSSEC Lookaside Validation(DLV)
In message , Chandan Laskar writes: > > Thanks Bill. > > We have authoritative Name Server. Caching is not enable in the Name > Server. > > Also based on website > (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is not an > IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the current > recommended implementation Version. DLV fits into this section of RFC 4035. 5. Authenticating DNS Responses The process for obtaining and authenticating this initial trust anchor is achieved via some external mechanism. For example, a resolver could use some off-line authenticated exchange to obtain a zone's DNSKEY RR or to obtain a DS RR that identifies and authenticates a zone's DNSKEY RR. > So I am still not convince about the necessity of DLV incorporation in our > Setup. For an authoritative only setup I would be using TSIG to validate the zone transfers as you have a existing trust relationship. If you want other people to be able to validate the data you publish you need to sign your zone and publish your SEP's. If you parent zone is not signed you can use DLV as a substitute for the parent zone. Mark > Will grateful if you provide me more suggestion. > > Thanks and regards, > Chandan Laskar > 2nd Floor Data Center, ITC Center, > 4, Russel Street, Kolkata - 700 016 > Phone:(033)-22889900 Extn.: 3944 > (0)-9830057396 (M) > > > > Bill Larson > 04/07/2009 09:30 PM > > To > Chandan Laskar > cc > bind-users@lists.isc.org > Subject > Re: Necessity of DNSSEC Lookaside Validation(DLV) > > > > > > > On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote: > > Hi, > We have deployed DNS on RHEL 5 Update 1. Below are feature of our DNS. > 1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow > passwords, Root Login Console Restricted, Configure SSH as an alternative > of Telnet e.t.c.). > 2. Configured Openssl Version 0.9.8j. > 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not > running as root user. > 4. IPTABLES has been configured to block all the irrelevant ports. > 5. Allow Update Feature in named.conf is not changed. So, by default it is > 'NO' > > After all the above mentioned protection do we really need to incorporate > DNSSEC Lookaside Validation(DLV) in our DNS? > > Suggestion Please. > > Your implementation is protecting the DNS server itself - very good. The > purpose of DLV is to insure that the DNS data that your server provides, > and all DNSSEC data your server processes, is valid. > > The DNSSEC/DLV configuration protects your DNS data from being "spoofed" > on another DNS server. It also insures that the DNS data that your server > may be handing out recursively from being compromised. Protecting both > sides of the DNS service for your users is necessary (at least important). > > > Can you avoid printing this? > Think of the environment before printing the email. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Necessity of DNSSEC Lookaside Validation(DLV)
In message , Chandan Laskar writes: > > Thanks Mark. > > Can somebody provide me list of parent zone which has already signed? or > any website to get this information? You really only need to care if your parent zones are signed or not. The following tld's are currently signed, bg, br, cz, gov, museum, pr, se and th. Other tlds are currently planning to be signed. > Also not understood about SEP. Can you please tell me what is the full > form of that? SEP is a secure entry point. It is the DNSKEY which is identified by the DS / DLV record in the parent / DLV zone. The DS/DNSKEY (or DLV/DNSKEY) pairs provide the cryptographic linkage between the zones that enable a trust path to be made. Inside the zone it is the DNSKEY/RRSIG pairs which do a similar job. Mark > Thanks and regards, > Chandan Laskar > 2nd Floor Data Center, ITC Center, > 4, Russel Street, Kolkata - 700 016 > Phone:(033)-22889900 Extn.: 3944 > (0)-9830057396 (M) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip forwarding DNS 9.6.0
In message <83f1e37b-72bd-4454-8c2d-4fa91d5fc...@cs.moravian.edu>, myron writes
:
> On Apr 7, 2009, at 7:44 PM, Mark Andrews wrote:
>
> >
> > In message ,
> > myron writes:
> >> I started reading up on Kirk's suggestions of the allow-*** settings.
> >> In the global options level
> >> I put
> >> options {
> >> directory "/etc/dns";
> >> allow-query-cache { any; };
> >> allow-query { any; };
> >> auth-nxdomain yes;
> >> };
> >>
> >> and that definitely worked. By no means do I understand the paragraph
> >> below from the README.
> >> I need to mull over it for a while and determine where the options
> >> should go, whether globally or in a view
> >> and whether "any" is the right setting.
> >
> > Basically there are people using recursive DNS servers as
> > amplifiers in DoS attacks by sending forged UDP queries.
> > By restricting who can get access to the cache you reduce
> > the effect of such queries to just anonymising the original
> > query source.
> >
> > The defaults were changed so that only locally connected
> > nets get recursive service and access to the cache. This
> > default is right for a large majority of the users of named.
> > You should expand allow-query-cache to include all the
> > networks you want to offer recursive service to.
> >
> > Mark
>
> I think I got it right. I just changed "any" to my network. It works.
>
> options {
> directory "/etc/dns";
> allow-query-cache { int-net; };
> allow-query { int-net; };
allow-query would normally be "any;" as you are normally
publishing zones to the world.
> auth-nxdomain yes;
> };
>
> >
> >
> >> Thanks for all the help.
> >>
> >> --myron
> >> =
> >> Myron Kowalski
> >> MoCoSIN Network/Systems Administrator
> >> Moravian College
> >> my...@cs.moravian.edu
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Necessity of DNSSEC Lookaside Validation(DLV)
Chandan, Are you more interested in marking off bullet points on some "security compliance checklist", or actual, practical, real-world security? Just wondering... - Kevin Chandan Laskar wrote: Thanks Bill. We have authoritative Name Server. Caching is not enable in the Name Server. Also based on website (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is not an IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the current recommended implementation Version. So I am still not convince about the necessity of DLV incorporation in our Setup. Will grateful if you provide me more suggestion. Thanks and regards, Chandan Laskar 2nd Floor Data Center, ITC Center, 4, Russel Street, Kolkata - 700 016 Phone:(033)-22889900 Extn.: 3944 (0)-9830057396 (M) *Bill Larson * 04/07/2009 09:30 PM To Chandan Laskar cc bind-users@lists.isc.org Subject Re: Necessity of DNSSEC Lookaside Validation(DLV) On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote: Hi, We have deployed DNS on RHEL 5 Update 1. Below are feature of our DNS. * 1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow passwords, Root Login Console Restricted, Configure SSH as an alternative of Telnet e.t.c.). 2. Configured Openssl Version 0.9.8j.* * 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not running as root user.* * 4. IPTABLES has been configured to block all the irrelevant ports. 5. Allow Update Feature in named.conf is not changed. So, by default it is 'NO'* * After all the above mentioned protection do we really need to incorporate DNSSEC Lookaside Validation(DLV) in our DNS?* Suggestion Please. Your implementation is protecting the DNS server itself - very good. The purpose of DLV is to insure that the DNS data that your server provides, and all DNSSEC data your server processes, is valid. The DNSSEC/DLV configuration protects your DNS data from being "spoofed" on another DNS server. It also insures that the DNS data that your server may be handing out recursively from being compromised. Protecting both sides of the DNS service for your users is necessary (at least important). Can you avoid printing this? Think of the environment before printing the email. --- Please visit us at www.itcportal.com ** This Communication is for the exclusive use of the intended recipient (s) and shall not attach any liability on the originator or ITC Ltd./its Subsidiaries/its Group Companies. If you are the addressee, the contents of this email are intended for your use only and it shall not be forwarded to any third party, without first obtaining written authorisation from the originator or ITC Ltd./its Subsidiaries/its Group Companies. It may contain information which is confidential and legally privileged and the same shall not be used or dealt with by any third party in any manner whatsoever without the specific consent of ITC Ltd./its Subsidiaries/its Group Companies. ___ 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: Necessity of DNSSEC Lookaside Validation(DLV)
The .gov TLD is now signed. See http://dotgov.gov/dnssecinfo.aspx for all of the details. Thanks. Vyto Fermi National Accelerator Lab _ From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chandan Laskar Sent: Thursday, April 09, 2009 11:21 AM To: Mark Andrews Cc: mark_andr...@isc.org; bind-users@lists.isc.org Subject: Re: Necessity of DNSSEC Lookaside Validation(DLV) Thanks Mark. Can somebody provide me list of parent zone which has already signed? or any website to get this information? Also not understood about SEP. Can you please tell me what is the full form of that? Thanks and regards, Chandan Laskar 2nd Floor Data Center, ITC Center, 4, Russel Street, Kolkata - 700 016 Phone:(033)-22889900 Extn.: 3944 (0)-9830057396 (M) Mark Andrews Sent by: mark_andr...@isc.org 04/09/2009 05:15 PM To Chandan Laskar cc Bill Larson , bind-users@lists.isc.org Subject Re: Necessity of DNSSEC Lookaside Validation(DLV) In message , Chandan Laskar writes: > > Thanks Bill. > > We have authoritative Name Server. Caching is not enable in the Name > Server. > > Also based on website > (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is not an > IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the current > recommended implementation Version. DLV fits into this section of RFC 4035. 5. Authenticating DNS Responses The process for obtaining and authenticating this initial trust anchor is achieved via some external mechanism. For example, a resolver could use some off-line authenticated exchange to obtain a zone's DNSKEY RR or to obtain a DS RR that identifies and authenticates a zone's DNSKEY RR. > So I am still not convince about the necessity of DLV incorporation in our > Setup. For an authoritative only setup I would be using TSIG to validate the zone transfers as you have a existing trust relationship. If you want other people to be able to validate the data you publish you need to sign your zone and publish your SEP's. If you parent zone is not signed you can use DLV as a substitute for the parent zone. Mark > Will grateful if you provide me more suggestion. > > Thanks and regards, > Chandan Laskar > 2nd Floor Data Center, ITC Center, > 4, Russel Street, Kolkata - 700 016 > Phone:(033)-22889900 Extn.: 3944 > (0)-9830057396 (M) > > > > Bill Larson > 04/07/2009 09:30 PM > > To > Chandan Laskar > cc > bind-users@lists.isc.org > Subject > Re: Necessity of DNSSEC Lookaside Validation(DLV) > > > > > > > On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote: > > Hi, > We have deployed DNS on RHEL 5 Update 1. Below are feature of our DNS. > 1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow > passwords, Root Login Console Restricted, Configure SSH as an alternative > of Telnet e.t.c.). > 2. Configured Openssl Version 0.9.8j. > 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not > running as root user. > 4. IPTABLES has been configured to block all the irrelevant ports. > 5. Allow Update Feature in named.conf is not changed. So, by default it is > 'NO' > > After all the above mentioned protection do we really need to incorporate > DNSSEC Lookaside Validation(DLV) in our DNS? > > Suggestion Please. > > Your implementation is protecting the DNS server itself - very good. The > purpose of DLV is to insure that the DNS data that your server provides, > and all DNSSEC data your server processes, is valid. > > The DNSSEC/DLV configuration protects your DNS data from being "spoofed" > on another DNS server. It also insures that the DNS data that your server > may be handing out recursively from being compromised. Protecting both > sides of the DNS service for your users is necessary (at least important). > > > Can you avoid printing this? > Think of the environment before printing the email. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org Can you avoid printing this? Think of the environment before printing the email. --- Please visit us at www.itcportal.com ** This Communication is for the exclusive use of the intended recipient (s) and shall not attach any liability on the originator or ITC Ltd./its Subsidiaries/its Group Companies. If you are the addressee, the contents of this email are intended for your use only and it shall not be forwarded to any third party, without first obtaining written authorisation from the originator or
Re: Trouble configuring forwarders for reverse zones.
On Apr 9, 2009, at 9:59 AM, M-lists wrote: Much obliged Chris: I'll give that a go. Just out of interest though, how come you can't just specify a netmask? It seems convoluted to have such different ways of specifying reverse forwarders for classfull and classless Subnets. The answer is contained within a several-hour training course on how DNS works (which I have been known to teach now and then). The short version is, standard PTR record names (and the names used in queries looking for PTR records) are based on the IP address, with dots at the octet boundaries. They don't have the subnet mask in them. Chris Buxton Professional Services Men & Mice -Original Message- From: Chris Buxton [mailto:cbux...@menandmice.com] Sent: 08 April 2009 18:20 To: Callum Millard Cc: Bind Users Mailing List Subject: Re: Trouble configuring forwarders for reverse zones. You would create a /16 or /24 parent zone. For example, you could use a zone named 1.1.10.in-addr.arpa. From that zone, you would delegate the /28 reverse zone using a syntax along these lines: 0/28.1.1.10.in-addr.arpa. NS 1.other.name.server. 0/28.1.1.10.in-addr.arpa. NS 2.other.name.server. 1.1.1.10.in-addr.arpa. CNAME 1.0/28.1.1.10.in-addr.arpa. 2.1.1.10.in-addr.arpa. CNAME 2.0/28.1.1.10.in-addr.arpa. [...] 14.1.1.10.in-addr.arpa. CNAME 14.0/28.1.1.10.in-addr.arpa. You can simplify the creation of the CNAME records using a $GENERATE statement: $GENERATE 1-14 1 CNAME 1.0/28 I have omitted the origin here for brevity. Chris Buxton Professional Services Men & Mice On Apr 8, 2009, at 8:45 AM, M-lists wrote: Apologies, I meant 10.1.1.0/28 not /24. The addresses used are arbitrary, as I don't like detailing my network topology unnecessarily. Suffice to say we've had the */28 subnet dished out and have to work with it. Thanks for the suggestions in your last paragraph Chris, but I didn't follow them entirely. Does anyone know the syntax to forward reverse queries for 10.1.1.1/28 on to a given host, or is it a bit more complex than with 10.1.0.0/16, as Chris' last paragraph suggests? Thanks again, C. -Original Message- From: Chris Buxton [mailto:cbux...@menandmice.com] Sent: 08 April 2009 15:24 To: Callum Millard Cc: bind-users@lists.isc.org Subject: Re: Trouble configuring forwarders for reverse zones. On Apr 8, 2009, at 3:00 AM, M-lists wrote: One further thing, I'll be moving things around on our network soon, and this means we'll have a classless subnet soon. So if we moved one of our Windows subnets to 10.1.1.0/24, how would I forward reverse queries for this subnet to say 10.1.1.1? When you say "classless subnet", what do you mean? A /24 is not a classless subnet as I understand the phrase. If you really do mean the same thing I do when I use that phrase, a subnet such as a /25 or /26, the first thing I would ask is why do this? You have 10/8 to work with. If you mean a classless subnet such as a /22 or /21, it's easier to just create the individual /24 reverse zones than to create a classless subnet reverse zone. In general, a classless subnet reverse zone relies on CNAME records to "move" the PTR record owner name to a new name, in an artificial zone. This requires a parent zone to create the CNAME records. (For zones larger than /24, use DNAME records instead of CNAME records.) So your BIND server might need a 10.1/16 zone, or possibly a 10.1.1/24 reverse zone - a parent zone using the standard naming convention that can then delegate artificial subzones elsewhere and can contain the CNAME or DNAME records needed to rename the PTR records into the subzone. Chris Buxton Professional Services Men & Mice ___ 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: Trouble configuring forwarders for reverse zones.
Much obliged Chris: I'll give that a go. Just out of interest though, how come you can't just specify a netmask? It seems convoluted to have such different ways of specifying reverse forwarders for classfull and classless Subnets. C. -Original Message- From: Chris Buxton [mailto:cbux...@menandmice.com] Sent: 08 April 2009 18:20 To: Callum Millard Cc: Bind Users Mailing List Subject: Re: Trouble configuring forwarders for reverse zones. You would create a /16 or /24 parent zone. For example, you could use a zone named 1.1.10.in-addr.arpa. From that zone, you would delegate the /28 reverse zone using a syntax along these lines: 0/28.1.1.10.in-addr.arpa. NS 1.other.name.server. 0/28.1.1.10.in-addr.arpa. NS 2.other.name.server. 1.1.1.10.in-addr.arpa. CNAME 1.0/28.1.1.10.in-addr.arpa. 2.1.1.10.in-addr.arpa. CNAME 2.0/28.1.1.10.in-addr.arpa. [...] 14.1.1.10.in-addr.arpa. CNAME 14.0/28.1.1.10.in-addr.arpa. You can simplify the creation of the CNAME records using a $GENERATE statement: $GENERATE 1-14 1 CNAME 1.0/28 I have omitted the origin here for brevity. Chris Buxton Professional Services Men & Mice On Apr 8, 2009, at 8:45 AM, M-lists wrote: > Apologies, I meant 10.1.1.0/28 not /24. The addresses used are > arbitrary, > as I don't like detailing my network topology unnecessarily. > Suffice to say > we've had the */28 subnet dished out and have to work with it. > > Thanks for the suggestions in your last paragraph Chris, but I > didn't follow > them entirely. Does anyone know the syntax to forward reverse > queries for > 10.1.1.1/28 on to a given host, or is it a bit more complex than with > 10.1.0.0/16, as Chris' last paragraph suggests? > > Thanks again, > > > C. > > -Original Message- > From: Chris Buxton [mailto:cbux...@menandmice.com] > Sent: 08 April 2009 15:24 > To: Callum Millard > Cc: bind-users@lists.isc.org > Subject: Re: Trouble configuring forwarders for reverse zones. > > On Apr 8, 2009, at 3:00 AM, M-lists wrote: >> One further thing, I'll be moving things around on our network soon, >> and >> this means we'll have a classless subnet soon. So if we moved one >> of our >> Windows subnets to 10.1.1.0/24, how would I forward reverse queries >> for this >> subnet to say 10.1.1.1? > > When you say "classless subnet", what do you mean? A /24 is not a > classless subnet as I understand the phrase. > > If you really do mean the same thing I do when I use that phrase, a > subnet such as a /25 or /26, the first thing I would ask is why do > this? You have 10/8 to work with. If you mean a classless subnet such > as a /22 or /21, it's easier to just create the individual /24 reverse > zones than to create a classless subnet reverse zone. > > In general, a classless subnet reverse zone relies on CNAME records to > "move" the PTR record owner name to a new name, in an artificial zone. > This requires a parent zone to create the CNAME records. (For zones > larger than /24, use DNAME records instead of CNAME records.) So your > BIND server might need a 10.1/16 zone, or possibly a 10.1.1/24 reverse > zone - a parent zone using the standard naming convention that can > then delegate artificial subzones elsewhere and can contain the CNAME > or DNAME records needed to rename the PTR records into the subzone. > > Chris Buxton > Professional Services > Men & Mice > > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ip forwarding DNS 9.6.0
On Apr 7, 2009, at 7:44 PM, Mark Andrews wrote:
In message ,
myron writes:
I started reading up on Kirk's suggestions of the allow-*** settings.
In the global options level
I put
options {
directory "/etc/dns";
allow-query-cache { any; };
allow-query { any; };
auth-nxdomain yes;
};
and that definitely worked. By no means do I understand the paragraph
below from the README.
I need to mull over it for a while and determine where the options
should go, whether globally or in a view
and whether "any" is the right setting.
Basically there are people using recursive DNS servers as
amplifiers in DoS attacks by sending forged UDP queries.
By restricting who can get access to the cache you reduce
the effect of such queries to just anonymising the original
query source.
The defaults were changed so that only locally connected
nets get recursive service and access to the cache. This
default is right for a large majority of the users of named.
You should expand allow-query-cache to include all the
networks you want to offer recursive service to.
Mark
I think I got it right. I just changed "any" to my network. It works.
options {
directory "/etc/dns";
allow-query-cache { int-net; };
allow-query { int-net; };
auth-nxdomain yes;
};
Thanks for all the help.
--myron
=
Myron Kowalski
MoCoSIN Network/Systems Administrator
Moravian College
my...@cs.moravian.edu
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Necessity of DNSSEC Lookaside Validation(DLV)
Thanks Mark. Can somebody provide me list of parent zone which has already signed? or any website to get this information? Also not understood about SEP. Can you please tell me what is the full form of that? Thanks and regards, Chandan Laskar 2nd Floor Data Center, ITC Center, 4, Russel Street, Kolkata - 700 016 Phone:(033)-22889900 Extn.: 3944 (0)-9830057396 (M) Mark Andrews Sent by: mark_andr...@isc.org 04/09/2009 05:15 PM To Chandan Laskar cc Bill Larson , bind-users@lists.isc.org Subject Re: Necessity of DNSSEC Lookaside Validation(DLV) In message , Chandan Laskar writes: > > Thanks Bill. > > We have authoritative Name Server. Caching is not enable in the Name > Server. > > Also based on website > (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is not an > IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the current > recommended implementation Version. DLV fits into this section of RFC 4035. 5. Authenticating DNS Responses The process for obtaining and authenticating this initial trust anchor is achieved via some external mechanism. For example, a resolver could use some off-line authenticated exchange to obtain a zone's DNSKEY RR or to obtain a DS RR that identifies and authenticates a zone's DNSKEY RR. > So I am still not convince about the necessity of DLV incorporation in our > Setup. For an authoritative only setup I would be using TSIG to validate the zone transfers as you have a existing trust relationship. If you want other people to be able to validate the data you publish you need to sign your zone and publish your SEP's. If you parent zone is not signed you can use DLV as a substitute for the parent zone. Mark > Will grateful if you provide me more suggestion. > > Thanks and regards, > Chandan Laskar > 2nd Floor Data Center, ITC Center, > 4, Russel Street, Kolkata - 700 016 > Phone:(033)-22889900 Extn.: 3944 > (0)-9830057396 (M) > > > > Bill Larson > 04/07/2009 09:30 PM > > To > Chandan Laskar > cc > bind-users@lists.isc.org > Subject > Re: Necessity of DNSSEC Lookaside Validation(DLV) > > > > > > > On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote: > > Hi, > We have deployed DNS on RHEL 5 Update 1. Below are feature of our DNS. > 1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow > passwords, Root Login Console Restricted, Configure SSH as an alternative > of Telnet e.t.c.). > 2. Configured Openssl Version 0.9.8j. > 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not > running as root user. > 4. IPTABLES has been configured to block all the irrelevant ports. > 5. Allow Update Feature in named.conf is not changed. So, by default it is > 'NO' > > After all the above mentioned protection do we really need to incorporate > DNSSEC Lookaside Validation(DLV) in our DNS? > > Suggestion Please. > > Your implementation is protecting the DNS server itself - very good. The > purpose of DLV is to insure that the DNS data that your server provides, > and all DNSSEC data your server processes, is valid. > > The DNSSEC/DLV configuration protects your DNS data from being "spoofed" > on another DNS server. It also insures that the DNS data that your server > may be handing out recursively from being compromised. Protecting both > sides of the DNS service for your users is necessary (at least important). > > > Can you avoid printing this? > Think of the environment before printing the email. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org Can you avoid printing this? Think of the environment before printing the email. --- Please visit us at www.itcportal.com ** This Communication is for the exclusive use of the intended recipient (s) and shall not attach any liability on the originator or ITC Ltd./its Subsidiaries/its Group Companies. If you are the addressee, the contents of this email are intended for your use only and it shall not be forwarded to any third party, without first obtaining written authorisation from the originator or ITC Ltd./its Subsidiaries/its Group Companies. It may contain information which is confidential and legally privileged and the same shall not be used or dealt with by any third party in any manner whatsoever without the specific consent of ITC Ltd./its Subsidiaries/its Group Companies.___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: about allow-transfer
or
allow-transfers { acl1; acl2; };
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jonathan
Petersson
Sent: Thursday, April 09, 2009 3:20 AM
To: Jeff Pang
Cc: Bind Mailing
Subject: Re: about allow-transfer
allow-transfer { slaveip; };
On Wed, Apr 8, 2009 at 11:42 PM, Jeff Pang
wrote:
> hello,
>
> I have two bind-9.6 (one master one slave) for product application.
> how to set allow-transfer in master's named.conf?
> shall it be:
>
> allow-transfer { none; };
>
> or:
>
> allow-transfer { all; };
>
> thanks.
>
> Regards.
>
> ___
> 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
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Necessity of DNSSEC Lookaside Validation(DLV)
Thanks Bill. We have authoritative Name Server. Caching is not enable in the Name Server. Also based on website (http://www.netwidget.net/books/apress/dns/info/dlv.html), DLV is not an IETF standarized feature and BIND 9.3.2 (We have 9.6.0.-P1) is the current recommended implementation Version. So I am still not convince about the necessity of DLV incorporation in our Setup. Will grateful if you provide me more suggestion. Thanks and regards, Chandan Laskar 2nd Floor Data Center, ITC Center, 4, Russel Street, Kolkata - 700 016 Phone:(033)-22889900 Extn.: 3944 (0)-9830057396 (M) Bill Larson 04/07/2009 09:30 PM To Chandan Laskar cc bind-users@lists.isc.org Subject Re: Necessity of DNSSEC Lookaside Validation(DLV) On Apr 7, 2009, at 9:43 AM, Chandan Laskar wrote: Hi, We have deployed DNS on RHEL 5 Update 1. Below are feature of our DNS. 1. Implemented OS Security Best Practice ( e.g. Enable MD5 and shadow passwords, Root Login Console Restricted, Configure SSH as an alternative of Telnet e.t.c.). 2. Configured Openssl Version 0.9.8j. 3. Configured BIND 9.6.0-P1 with CHROOT Environment. So BIND is not running as root user. 4. IPTABLES has been configured to block all the irrelevant ports. 5. Allow Update Feature in named.conf is not changed. So, by default it is 'NO' After all the above mentioned protection do we really need to incorporate DNSSEC Lookaside Validation(DLV) in our DNS? Suggestion Please. Your implementation is protecting the DNS server itself - very good. The purpose of DLV is to insure that the DNS data that your server provides, and all DNSSEC data your server processes, is valid. The DNSSEC/DLV configuration protects your DNS data from being "spoofed" on another DNS server. It also insures that the DNS data that your server may be handing out recursively from being compromised. Protecting both sides of the DNS service for your users is necessary (at least important). Can you avoid printing this? Think of the environment before printing the email. --- Please visit us at www.itcportal.com ** This Communication is for the exclusive use of the intended recipient (s) and shall not attach any liability on the originator or ITC Ltd./its Subsidiaries/its Group Companies. If you are the addressee, the contents of this email are intended for your use only and it shall not be forwarded to any third party, without first obtaining written authorisation from the originator or ITC Ltd./its Subsidiaries/its Group Companies. It may contain information which is confidential and legally privileged and the same shall not be used or dealt with by any third party in any manner whatsoever without the specific consent of ITC Ltd./its Subsidiaries/its Group Companies.___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.4 acache crashes
On 9/4/2009 10:10 πμ, Sotiris Tsimbonis wrote:
On 7/4/2009 12:09 μμ, Sotiris Tsimbonis wrote:
On 6/4/2009 9:23 μμ, JINMEI Tatuya / 神明達哉 wrote:
At Fri, 03 Apr 2009 18:38:01 +0300,
Sotiris Tsimbonis wrote:
Anyone else seen crashes like these?
FWIW, I've never seen any of these.
Solaris 10, Bind 9.4.3b2
Logfile:
10-Mar-2009 09:14:19.460 general: socket.c:2739: fatal error:
10-Mar-2009 09:14:19.461 general:
RUNTIME_CHECK(((pthread_mutex_unlock(((&sock->lock))) == 0) ? 0 : 34)
== 0) failed
10-Mar-2009 09:14:19.461 general: exiting (due to fatal error in library)
And another one (Solaris 9, bind 9.4.3b2) ...
08-Apr-2009 21:14:39.237 general: acache.c:393: INSIST(result == 0) failed
08-Apr-2009 21:14:39.237 general: exiting (due to assertion failure)
And another one, with core... (Solaris 10, bind 9.4.3b2)
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.10"...
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libsocket.so.1...done.
Loaded symbols for /lib/libsocket.so.1
Reading symbols from /lib/libscf.so.1...done.
Loaded symbols for /lib/libscf.so.1
Reading symbols from /lib/libpthread.so.1...
warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074
done.
Loaded symbols for /lib/libpthread.so.1
Reading symbols from /lib/libthread.so.1...
warning: Lowest section in /lib/libthread.so.1 is .dynamic at 0074
done.
Loaded symbols for /lib/libthread.so.1
Reading symbols from /lib/libc.so.1...done.
Loaded symbols for /lib/libc.so.1
Reading symbols from /lib/libdoor.so.1...done.
Loaded symbols for /lib/libdoor.so.1
Reading symbols from /lib/libuutil.so.1...done.
Loaded symbols for /lib/libuutil.so.1
Reading symbols from /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1...done.
Loaded symbols for /platform/SUNW,Sun-Fire-V240/lib/libc_psr.so.1
Reading symbols from /lib/nss_files.so.1...done.
Loaded symbols for /lib/nss_files.so.1
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
Core was generated by `/opt/bind/sbin/named -u named -t /opt/bind -c
/etc/named.conf'.
Program terminated with signal 11, Segmentation fault.
#0 0xff1b952c in mutex_lock_impl () from /lib/libc.so.1
(gdb) thread apply all bt full
Thread 5 (process 74037):
#0 0xff1c097c in ___sigtimedwait () from /lib/libc.so.1
No symbol table info available.
#1 0xff1b45fc in __sigtimedwait () from /lib/libc.so.1
No symbol table info available.
#2 0xff1ac964 in __posix_sigwait () from /lib/libc.so.1
No symbol table info available.
#3 0x001cf3e8 in isc_app_run () at app.c:504
event = (isc_event_t *) 0x0
next_event = (isc_event_t *) 0xffbffba8
task = (isc_task_t *) 0x0
sset = {__sigbits = {16387, 0, 0, 0}}
strbuf =
"\000\000\b<\000\000\b<\000\000\b<\000\000\000\000\000\000\000\000\000\000\000\000\035Νe\000\000\000\000\000�ΏϋX�\033\234`\000$TΈ\000%Ϋ\200\000$\034\000\000\036\214\000\000$\034L",
'\0' ,
"$\034\000\000$\034$\000\000\000�\000$\034D\000\036oΐ\000%«Ψ�ΏϋΘ\000\003Ϊx\000\000\000\000\000$hp\000\000\000\000\000\000\000"
sig = 329004
#4 0x0003da94 in main (argc=7, argv=0xffbffcc4) at main.c:868
result = 144
instance = 0x0
Thread 4 (process 336181):
#0 0xff1c1058 in ioctl () from /lib/libc.so.1
No symbol table info available.
#1 0x001d9d28 in watcher (uap=0x25ab80) at socket.c:2949
cc = 1
dvp = {dp_fds = 0x2a0bf0, dp_nfds = 256, dp_timeout = -1}
strbuf = '\0'
#2 0xff1c04fc in _lwp_start () from /lib/libc.so.1
No symbol table info available.
#3 0xff1c04fc in _lwp_start () from /lib/libc.so.1
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 3 (process 270645):
#0 0xff1c0598 in __lwp_park () from /lib/libc.so.1
No symbol table info available.
#1 0xff1ba514 in cond_sleep_queue () from /lib/libc.so.1
No symbol table info available.
#2 0xff1ba630 in cond_wait_queue () from /lib/libc.so.1
No symbol table info available.
#3 0xff1baaa8 in cond_wait_common () from /lib/libc.so.1
No symbol table info available.
#4 0xff1bac40 in _cond_timedwait () from /lib/libc.so.1
No symbol table info available.
#5 0xff1bad34 in cond_timedwait () from /lib/libc.so.1
No symbol table info available.
#6 0xff1bad74 in pthread_cond_timedwait () from /lib/libc.so.1
No symbol table info available.
#7 0x001e06ec in isc_condition_waituntil (c=0x258bb8, m=0x258b88,
t=0x258bb0) at condition.c:59
presult = 77
result = 2460600
ts = {tv_sec = 1239261464, tv_nsec = 201782000}
strbuf = "�\000ώ\230\000\034‘ IΫL\203\000\aΩT�\000ώ¨�\0
Re: about allow-transfer
allow-transfer { slaveip; };
On Wed, Apr 8, 2009 at 11:42 PM, Jeff Pang wrote:
> hello,
>
> I have two bind-9.6 (one master one slave) for product application.
> how to set allow-transfer in master's named.conf?
> shall it be:
>
> allow-transfer { none; };
>
> or:
>
> allow-transfer { all; };
>
> thanks.
>
> Regards.
>
> ___
> 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: bind 9.4 acache crashes
On 7/4/2009 12:09 μμ, Sotiris Tsimbonis wrote: On 6/4/2009 9:23 μμ, JINMEI Tatuya / 神明達哉 wrote: At Fri, 03 Apr 2009 18:38:01 +0300, Sotiris Tsimbonis wrote: Anyone else seen crashes like these? FWIW, I've never seen any of these. Solaris 10, Bind 9.4.3b2 Logfile: 10-Mar-2009 09:14:19.460 general: socket.c:2739: fatal error: 10-Mar-2009 09:14:19.461 general: RUNTIME_CHECK(((pthread_mutex_unlock(((&sock->lock))) == 0) ? 0 : 34) == 0) failed 10-Mar-2009 09:14:19.461 general: exiting (due to fatal error in library) And another one (Solaris 9, bind 9.4.3b2) ... 08-Apr-2009 21:14:39.237 general: acache.c:393: INSIST(result == 0) failed 08-Apr-2009 21:14:39.237 general: exiting (due to assertion failure) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
