Re: DNSSEC for recursive server

2010-05-21 Thread Stephane Bortzmeyer 
On Fri, May 21, 2010 at 09:54:01AM +0300,
 Techi  wrote 
 a message of 46 lines which said:

> I have a Centos 5.x with Bind 9.3.6-4. 

That's an extremely old version. Even Debian :-) has a more recent
one. For instance, you won't be able to validate the root (which uses
SHA256) or .ORG (which uses NSEC3).

> dnssec-enable yes;
> dnssec-validation yes;
> 
> Is that correct?

You also need to configure trust anchors:

trusted-keys {
   # Not yet published 
   . 257 3 5 "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lL...";

and/or:

dnssec-lookaside . trust-anchor dlv.isc.org.;

> If not so, then what DLV should I use? That if ISC, IANA's, RIPE, what? And 
> how?

As far as I know, IANA and RIPE do not manage a DLV. For ISC, see the
line above.

> So, the specific server is DNSSEC aware and I will not face any
> issues with the root zones signing at 01/07/2010. Correct?

The root is already completely signed for one week (the key is not yet
published). You do not need to enable DNSSEC to work with the signed
root, it is a separate issue.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Web forwarding in BIND

2010-05-21 Thread Stephane Bortzmeyer 
On Thu, May 20, 2010 at 05:18:10PM -0700,
 Hoover Chan  wrote 
 a message of 15 lines which said:

> A pointer please to information on how to use BIND to "translate" a
> domain name to a target URL. For example, www.domain ->
> http://www.someother.domain/folder1/folder2/index.html.

Unlike what many people said, there is an existing solution to do so,
it is called NAPTR, and is specified in RFC
3403. 

Like what many people said, it is not usable in practice since the
regular Web browser does not use it (and I assume it is your target).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC for recursive server

2010-05-21 Thread Adam Tkac 
On Fri, May 21, 2010 at 09:54:01AM +0300, Techi wrote:
> Hallo,
> I try to setup (=prepare) the our DNS servers for the DNSSEC era.
> I have a Centos 5.x with Bind 9.3.6-4. I have one problem and 2 questions.
> The problem is that the specific version seems to lack support for DNSSEC 
> validation! named-checkconf returns the following error:
> /etc/named.conf:212: unknown option 'dnssec-validation'
> 
> !!!
> Now the questions:
> 1. I try to understand the concepts of DNSSEC and the signing of root zones. 
> As far as I understand, all I need to add in my bind's configuration are the 
> following lines:
> 
> dnssec-enable yes;
> dnssec-validation yes;
> 
> Is that correct?

DNSSEC validation & serving is controlled by one "global" DNSSEC
option in 9.3.X series:

options {
...
dnssec yes;
...
};

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Web forwarding in BIND

2010-05-21 Thread Chris Buxton 

On May 21, 2010, at 4:27 AM, Stephane Bortzmeyer wrote:

> On Thu, May 20, 2010 at 05:18:10PM -0700,
> Hoover Chan  wrote 
> a message of 15 lines which said:
> 
>> A pointer please to information on how to use BIND to "translate" a
>> domain name to a target URL. For example, www.domain ->
>> http://www.someother.domain/folder1/folder2/index.html.
> 
> Unlike what many people said, there is an existing solution to do so,
> it is called NAPTR, and is specified in RFC
> 3403. 
> 
> Like what many people said, it is not usable in practice since the
> regular Web browser does not use it (and I assume it is your target).

Another such solution (and simpler) would be SRV records, but again, browsers 
don't support it.

Chris Buxton
BlueCat Networks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Web forwarding in BIND

2010-05-21 Thread Stephane Bortzmeyer 
On Fri, May 21, 2010 at 08:30:47AM -0400,
 Chris Buxton  wrote 
 a message of 26 lines which said:

> Another such solution (and simpler) would be SRV records, 

It maps a domaine name to a set of {domain name, port}, not to URL
(with the path and so on) :-) So, no, you still need NAPTR if you want
the whole thing to be done in the DNS.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec zone signing problem

2010-05-21 Thread Sergiu Bivol 
We have a similar issue. And this is my understanding of it:

>From briefly looking at the source, it seems that as of 9.6.2-P1 the
dnssec-signzone tool performs some additional validation after the
signing is complete.

Previously, it could only verify the signatures it generated, if "-a" is
used on the command line.

More recently though, dnssec-signzone also performs some higner level
validation after it's done signing. This is called "post signing
validation". 

We were invoking the dnssec-signzone tool once with each key. We'd start
by signing with KSK, then sign with ZSK. When we upgraded to 9.6.2-P1,
dnssec-signzone started failing with errors when signing with KSK: 
---
Verifying the zone using the following algorithms: RSASHA1.
no signatures for example.com/NSEC
no signatures for example.com/SOA
no signatures for example.com/NS
no signatures for subzone.example.com/NSEC
no signatures for subzone.example.com/A
---

Then we tried signing with both KSK and ZSK at the same time, but got
some other error (no self signed KSK found). Without spending more time
on this we found a workaround - to disable post signing validation with
the newly introduced paratmeter "-P".

This is what BIND ARM says:

-P Disable post sign verification tests.
The post sign verification test ensures that for each algorithm in use
there is at least one non
revoked self signed KSK key, that all revoked KSK keys are self signed,
and that all records in the
zone are signed by the algorithm. This option skips these tests.

At some point we will revisit this issue to understand how to sign the
zone so that it passes the post signing validation.

Regards
Sergiu
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec zone signing problem

2010-05-21 Thread Torsten 
Am Fri, 21 May 2010 09:35:31 -0400
schrieb "Sergiu Bivol" :

> We were invoking the dnssec-signzone tool once with each key. We'd
> start by signing with KSK, then sign with ZSK. When we upgraded to
> 9.6.2-P1, dnssec-signzone started failing with errors when signing
> with KSK: ---
> Verifying the zone using the following algorithms: RSASHA1.
> no signatures for example.com/NSEC
> no signatures for example.com/SOA
> no signatures for example.com/NS
> no signatures for subzone.example.com/NSEC
> no signatures for subzone.example.com/A
> ---
> 
> Then we tried signing with both KSK and ZSK at the same time, but got
> some other error (no self signed KSK found). Without spending more
> time on this we found a workaround - to disable post signing
> validation with the newly introduced paratmeter "-P".
> 


Hmm... dnssec-signzone (version 9.7.0-P1) seems to work perfectly well:

dnssec-signzone -k Kexample.com.+008+53749.key -N INCREMENT -g -o
example.com example.com Kexample.com.+008+41979 
Verifying the zone using the following algorithms: RSASHA256. 
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked 
  ZSKs: 1 active, 1 stand-by, 0 revoked 
example.com.signed



Ciao
Torsten
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Split domain for forwarders or both

2010-05-21 Thread Prashant Ramhit 

Hi All,
I have a query:
I have example.com setup on a public dns and example.com set up on a 
local dns.
If a record is not found in the local, how can I force it to look for a 
record in the public dns, for the same domain.


Could some one please let me know the options to add to bind9 please.

Kind Regards,
Prashant
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Split domain for forwarders or both

2010-05-21 Thread Todd Snyder 
>From my experience, there is no way to do this.  Once an answer is made 
>authoritatively from your internal server, you can't tell it to go somewhere 
>else.  Authoritative is authoritative, and even if you know there's a better 
>answer somewhere else, you're stuck with what you've gone.

What I've had to do in the past is add entries from external to internal, so 
that you don't need the "if it fails, try here" functionality.  It doubles the 
administrative overhead and maintenance, and can cause some headaches when 
something is missed, but it's the best solution I've found so far.

Cheers,

Todd.

-Original Message-
From: bind-users-bounces+tsnyder=rim@lists.isc.org 
[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of Prashant 
Ramhit
Sent: Friday, May 21, 2010 10:37 AM
To: bind-users@lists.isc.org
Subject: Split domain for forwarders or both

Hi All,
I have a query:
I have example.com setup on a public dns and example.com set up on a 
local dns.
If a record is not found in the local, how can I force it to look for a 
record in the public dns, for the same domain.

Could some one please let me know the options to add to bind9 please.

Kind Regards,
Prashant
___
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: dnssec dlv

2010-05-21 Thread itservices88 
I heard that root zone will be signed (or is already signed), so what
changes would be required with respect to the current additions of adding
dlv.isc.org as trust anchor and its associated trusted key ? Do we need to
keep the isc dlv ? or add a new key for the root ?

Thanks
-dani

On Thu, May 20, 2010 at 10:07 PM, itservices88 wrote:

> I missed the trusted key .. Thanks
>
> Here is the other output
>
>
> # dig +cd +dnssec dlv.isc.org dnskey @localhost
>
> ; <<>> DiG 9.6.2-P1-RedHat-9.6.2-3.P1.fc12 <<>> +cd +dnssec dlv.isc.orgdnskey 
> @localhost
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63788
> ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;dlv.isc.org.   IN  DNSKEY
>
> ;; ANSWER SECTION:
> dlv.isc.org.6752IN  DNSKEY  256 3 5
> BEOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAaGPT+Q0kpiN+7
> GviFh+nIazoB8e2Yv7mupgqkmIjObdcbGstYpUltdECdNpNmBvASKB9S
> BdtGeRvXXpORi3Qyxb9kHGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBF tCibp/mkhw==
> dlv.isc.org.6752IN  DNSKEY  257 3 5
> BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
> brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
> 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
> ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
> Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
> QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh
> dlv.isc.org.6752IN  RRSIG   DNSKEY 5 3 7200
> 20100620033002 20100521033002 19297 dlv.isc.org.
> eEHtGjgatqIgxeCCcXJrZpaS5KzlWHbL/uNL9oqd/KnQwyVsqdZKhVR2
> U9xcGmtu0GAUTdogSQvhzK92y1qF9FuLlmlBDc9pvLBCf5dc7kIJ61ey
> vOZi18iZIv9+MyoE2ex/KfAHdHZUp3TUzgen7iGxba/yt9/dcJE6iFhz
> Kk2FSxxG7PFgHRZZJl9aVxuPlNjCnm1gwnuvdKame73tZrlzAK3GBbTo
> IEE2QSKs47glxhF5/Xka4UqYZ7wSvuCPG/xFn67FXVOHFQvZjNBxWX3V
> H1jmoJhyLmpCI4JdwGBr7jwPDURDsL2iAUkfpPIuparlq6DwII3lzrqC gA1M6w==
> dlv.isc.org.6752IN  RRSIG   DNSKEY 5 3 7200
> 20100620033002 20100521033002 64263 dlv.isc.org.
> TbUCfqArddr/0K7NVhL+UNQuM2dDremcvzLbWz6odZzIwdC/MqHzzAj6
> rbgHT+uwGZ6t+4ec5Hts9VWh+BEyx5pi6lnhKJjwcFwrXiBauppce11P
> uWG3AiJZeiYoCWu2E4CqhpW96ZrycRQYehWfsmDsR1BCglVytxJwYUhT WMg=
>
> ;; Query time: 4 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu May 20 21:52:59 2010
> ;; MSG SIZE  rcvd: 936
>
>
>   On Thu, May 20, 2010 at 6:45 PM, Mark Andrews  wrote:
>
>>
>> In message ,
>> itse
>>  rvices88 writes:
>> > Hi,
>> >
>> > Whenever i enable:
>> >
>> > dnssec-lookaside "." trust-anchor "DLV.ISC.ORG ";
>> >
>> > in the named.conf, restart bind, the dns resolution stops. One the same
>> FC12
>> > machine, dig using an outside dns server has no issues resolving with
>> > +dnssec option. I am using bind 9.6.2 that came with FC12.
>> >
>> > Any thoughts ?
>> >
>> > -dani
>>
>> Have you added the trusted-keys clause for dlv.isc.org?
>>
>> trusted-keys {
>>dlv.isc.org. 257 3 5
>> "BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URkY62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboMQKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VStTDN0YUuWrBNh";
>> };
>>
>> Does "dig +cd +dnssec dlv.isc.org dnskey" return RRSIGS.
>>
>> e.g.
>> ; <<>> DiG 9.3.6-P1 <<>> +cd +dnssec dlv.isc.org dnskey
>> ;; global options:  printcmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14675
>> ;; flags: qr rd ra ad cd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 4096
>> ;; QUESTION SECTION:
>> ;dlv.isc.org.   IN  DNSKEY
>>
>> ;; ANSWER SECTION:
>> dlv.isc.org.2077IN  DNSKEY  256 3 5
>> BEOlYGw53D+f01yCL5JsP0SB6EjYrnd0JYRBooAaGPT+Q0kpiN+7
>> GviFh+nIazoB8e2Yv7mupgqkmIjObdcbGstYpUltdECdNpNmBvASKB9S
>> BdtGeRvXXpORi3Qyxb9kHGG7SpzyYbc+KDVKnzYHB94pvqu3ZZpPFPBF tCibp/mkhw==
>> dlv.isc.org.2077IN  DNSKEY  257 3 5
>> BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
>> brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
>> 1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
>> ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
>> Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
>> QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh
>> dlv.isc.org.2077IN  RRSIG   DNSKEY 5 3 7200
>> 20100619164502 20100520164502 19297 dlv.isc.org.
>> OKURcBkX5iiDC1q87HsSs2xDcDrMm5aPAlYHkPqkHCy7UyTOnCr6cwwN
>> W42mdG4nmpURR4aDGiPlfc1lomE5kA5wOcXASgfMO8eQoOOIyZcBngOb
>> WaE0KY+e/xU37kf7Ms7g6UxTnL+hcjbYgZf2rwN7J1RXf0Z5PfyyASXi
>> ybf3iYGs7GusXgLZ0ZEWQh0zglo2ym56CVt2TbIljJFB0lzAvezos36R
>> SWA

Re: dnssec dlv

2010-05-21 Thread Chris Thompson 

On May 21 2010, itservices88 wrote:


I heard that root zone will be signed (or is already signed),


It's in DURZ mode. Read all about it at http://www.root-dnssec.org/


 so what
changes would be required with respect to the current additions of adding
dlv.isc.org as trust anchor and its associated trusted key ? Do we need to
keep the isc dlv ? or add a new key for the root ?


I don't know whether ISC are planning to add a DLV record for the
root to the isc.dlv.org zone. (When I asked on another list whether
that would work, Mark Andrews told me "of course it would".) If
not, then it will certainly be desirable to add a trust anchor
for the root zone, as (for example) the IANA ITAR will  stop being
imported into dlv.isc.org at some point, as it will cease to exist.

But large parts of the DNS tree will remain disconnected from the
root vis-a-vis DNSSEC, for quite a while, so you should plan to keep
using dlv.isc.org as well. (I am assuming you are not opposed to DLV
in principle if you are already using it...] I would plan to review
the situation in mid-2011 after "com" has been signed for a decent
length of time.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Web forwarding in BIND

2010-05-21 Thread Hoover Chan 
Thanks for this and all the other input.

When you say "regular Web browser", it's safe to conclude that Firefox, IE and 
Safari are all included in this category? If so, then yes, that is the target 
audience.

I have an odd (and frustrating) situation where I manage the DNS for a Web 
service that's housed outside of my institution who for some reason doesn't 
want to configure virtual hosting. A workaround was (actually in place at this 
moment) to point DNS to a Web server I manage and do the appropriate virtual 
hosting config and redirect. However, the group that manages the content for 
that Web server somehow doesn't want to it this way.

Oh well.

-
Hoover Chanhc...@mail.ewind.com  -or-  hc...@well.com
Eastwind Associates
P.O. Box 16646 voice: 415-731-6019  -or-  415-565-8936
San Francisco, CA 94116

- "Stephane Bortzmeyer"  wrote:

> On Thu, May 20, 2010 at 05:18:10PM -0700,
>  Hoover Chan  wrote 
>  a message of 15 lines which said:
> 
> > A pointer please to information on how to use BIND to "translate" a
> > domain name to a target URL. For example, www.domain ->
> > http://www.someother.domain/folder1/folder2/index.html.
> 
> Unlike what many people said, there is an existing solution to do so,
> it is called NAPTR, and is specified in RFC
> 3403. 
> 
> Like what many people said, it is not usable in practice since the
> regular Web browser does not use it (and I assume it is your target).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec dlv

2010-05-21 Thread itservices88 
Thanks for details.

-dani

On Fri, May 21, 2010 at 9:04 AM, Chris Thompson  wrote:

> On May 21 2010, itservices88 wrote:
>
> I heard that root zone will be signed (or is already signed),
>>
>
> It's in DURZ mode. Read all about it at http://www.root-dnssec.org/
>
>
> so what
>> changes would be required with respect to the current additions of adding
>> dlv.isc.org as trust anchor and its associated trusted key ? Do we need
>> to
>> keep the isc dlv ? or add a new key for the root ?
>>
>
> I don't know whether ISC are planning to add a DLV record for the
> root to the isc.dlv.org zone. (When I asked on another list whether
> that would work, Mark Andrews told me "of course it would".) If
> not, then it will certainly be desirable to add a trust anchor
> for the root zone, as (for example) the IANA ITAR will  stop being
> imported into dlv.isc.org at some point, as it will cease to exist.
>
> But large parts of the DNS tree will remain disconnected from the
> root vis-a-vis DNSSEC, for quite a while, so you should plan to keep
> using dlv.isc.org as well. (I am assuming you are not opposed to DLV
> in principle if you are already using it...] I would plan to review
> the situation in mid-2011 after "com" has been signed for a decent
> length of time.
>
> --
> Chris Thompson
> Email: c...@cam.ac.uk
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dnssec zone signing problem

2010-05-21 Thread Sergiu Bivol 
>Hmm... dnssec-signzone (version 9.7.0-P1) seems to work perfectly well:
>
>dnssec-signzone -k Kexample.com.+008+53749.key -N INCREMENT -g -o
example.com example.com Kexample.com.+008+41979 Verifying the zone using
the following algorithms: RSASHA256. 
>Zone signing complete:
>Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked 
> ZSKs: 1 active, 1 stand-by, 0 revoked
example.com.signed

Did some more digging with dnssec-signzone (v9.7.0-P2 and 9.6.2-P2). It
works if:
a) both KSK and ZSK are specified on the command line
b) their DNSKEY records are in the zone file
c) their key files exist on disk.

If only KSK is specified in a), it also works if b) and c) are met.
However, if in c) only KSK key files are on disk, but ZSK key files are
not, dnssec-signzone fails with the errors mentioned earlier.

Prior to 9.6.2-P1, instead of failing, dnssec-signzone would sign only
the DNSKEY RRset with KSK. Then we'd invoke dnssec-signzone with ZSK to
sign everything else.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Split domain for forwarders or both

2010-05-21 Thread Chris Buxton 
>>> I have example.com setup on a public dns and example.com set up on a 
>>> local dns.
>>> If a record is not found in the local, how can I force it to look for a 
>>> record in the public dns, for the same domain.
>> 
>> From my experience, there is no way to do this.  Once an answer is made 
>> authoritatively from your internal server, you can't tell it to go somewhere 
>> else.  Authoritative is authoritative, and even if you know there's a better 
>> answer somewhere else, you're stuck with what you've gone.
> 
> What I've had to do in the past is add entries from external to internal, so 
> that you don't need the "if it fails, try here" functionality.  It doubles 
> the administrative overhead and maintenance, and can cause some headaches 
> when something is missed, but it's the best solution I've found so far.

In the absence of some extra application that manages both copies and handles 
this replication for you, this double entry is the only solution.

Chris Buxton
BlueCat Networks

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Split domain for forwarders or both

2010-05-21 Thread Prashant Ramhit 
Title: Blue Barracuda




Hi All,
Thank you very much, your reply is very much appreciated.

Regards,
Prashant


On 21/05/10 19:52, Chris Buxton wrote:

  

  
I have example.com setup on a public dns and example.com set up on a 
local dns.
If a record is not found in the local, how can I force it to look for a 
record in the public dns, for the same domain.

  
  
>From my experience, there is no way to do this.  Once an answer is made authoritatively from your internal server, you can't tell it to go somewhere else.  Authoritative is authoritative, and even if you know there's a better answer somewhere else, you're stuck with what you've gone.
  


What I've had to do in the past is add entries from external to internal, so that you don't need the "if it fails, try here" functionality.  It doubles the administrative overhead and maintenance, and can cause some headaches when something is missed, but it's the best solution I've found so far.

  
  
In the absence of some extra application that manages both copies and handles this replication for you, this double entry is the only solution.

Chris Buxton
BlueCat Networks

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

  



-- 



  

   Prashant Ramhit | Systems
Administrator
  
   
  
  


  


   prash...@bluebarracuda.com
d: +44 (0)207 4000 982
t:  +44 (0)207 4000 950
f:  +44 (0)207 4000 951
  www.bluebarracuda.com
  

  




___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec dlv

2010-05-21 Thread Mark Andrews 

In message , itse
rvices88 writes:
> 
> I heard that root zone will be signed (or is already signed), so what
> changes would be required with respect to the current additions of adding
> dlv.isc.org as trust anchor and its associated trusted key ? Do we need to
> keep the isc dlv ? or add a new key for the root ?
> 
> Thanks
> -dani

When the signed root goes operational you should add a managed
trusted key for it as I believe that the root will be following the
rules in RFC 5011.  Managed trusted keys were introduced in BIND
9.7.0.  You will still need to use DLV for the parts of the tree
which are not connected to the root.  The root's trust anchors will
be added to DLV so there is no need to rush to do this.  As far as
DLV is concerned the root is just another zone.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Web forwarding in BIND

2010-05-21 Thread Barry Margolin 
In article ,
 Hoover Chan  wrote:

> Thanks for this and all the other input.
> 
> When you say "regular Web browser", it's safe to conclude that Firefox, IE 
> and Safari are all included in this category? If so, then yes, that is the 
> target audience.

Right.  I think the only place where NAPTR is used is in Internet 
telephony.  The design allows for using it for web URL rewriting, but 
it's not used for that in practice.

> 
> I have an odd (and frustrating) situation where I manage the DNS for a Web 
> service that's housed outside of my institution who for some reason doesn't 
> want to configure virtual hosting. A workaround was (actually in place at 
> this moment) to point DNS to a Web server I manage and do the appropriate 
> virtual hosting config and redirect. However, the group that manages the 
> content for that Web server somehow doesn't want to it this way.
> 
> Oh well.

Tell them "too fucking bad".  This is how DNS and the web work.  DNS 
translates names to IPs, not to URLs.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users