Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 06:06:16AM +,
 Evan Hunt  wrote 
 a message of 22 lines which said:

> Is there a requirement that Dr. Bernstein must personally do the dancing?
> Let someone else write the RFC, if it needs writing.

Also, there are not only RFCs. Standards can be described by other
means. DNScurve does not even have a stable public specification. (Not
to mention a reference implementation in free software.)

> But what helps a lot more is evidence that the thing in question is
> getting widespread use, or that there's significant user demand for
> it.

As a demanding :-) user, yes, there are many things to fix/improve in
BIND before devoting resources to Bernstein's personal projects.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Stephane Bortzmeyer]

On Tue, Feb 23, 2010 at 07:28:48PM -0800,
 Michael Sinatra  wrote 
 a message of 34 lines which said:

> While I think the OpenDNS people (especially David U., their
> founder) have a huge amount of clue, I think they're barking up the
> wrong tree here.

On the other hand, they are crystal-clear:

http://blog.opendns.com/2010/02/23/opendns-dnscurve/

> It [DNSSEC] also fundamentally hampers services like OpenDNS, which
> use DNS to provide content filtering and search services.

So, DNSSEC is bad because it prevents OpenDNS from lying... ("Search
services" is a code word for "legitimate response modification".)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Blacklisting private address range

[Stephane Bortzmeyer]

On Tue, Feb 23, 2010 at 09:56:55PM -0500,
 Diosney Sarmiento Herrera  wrote 
 a message of 20 lines which said:

> Have any sense to blacklist the private address ranges on a server
> that is facing Internet?

I am not sure I parse your sentence correctly but may be you refer to
the "Rebinding prevention feature" which appeared in 9.7.0?

deny-answer-addresses { 10.0.0.0/8; } 
deny-answer-addresses { 172.16.0.0/12; } 
deny-answer-addresses { 192.168.0.0/16; } 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 11:32:35AM +1100,
 Mark Andrews  wrote 
 a message of 35 lines which said:

> Turn the debugging up to 3. 

With 'severity debug 30', all I get is:

24-Feb-2010 10:17:01.047 update: debug 8: client ::1#45986: updating zone 
'toto.fr/IN': prerequisites are OK
24-Feb-2010 10:17:01.047 update: debug 8: client ::1#45986: updating zone 
'toto.fr/IN': update section prescan OK
24-Feb-2010 10:17:01.047 update: info: client ::1#45986: updating zone 
'toto.fr/IN': adding an RR at 'toto.fr' DNSKEY
24-Feb-2010 10:17:01.048 update: debug 3: client ::1#45986: updating zone 
'toto.fr/IN': checking for NSEC3PARAM changes
24-Feb-2010 10:17:01.057 update: error: client ::1#45986: updating zone 
'toto.fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space
24-Feb-2010 10:17:01.057 update: debug 8: client ::1#45986: updating zone 
'toto.fr/IN': rolling back

I log 'dnssec' events:

logging {
  channel debugging {
 file "/tmp/bind-dnssec.log" versions 2 size 5m;
 severity debug 30;
 print-time yes;
 print-severity yes;
 print-category yes;
   };
  category update {
debugging;
  };
  category dnssec {
debugging;
  };
};


But I do not see them in the log.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Blacklisting private address range

[Bill Larson]

On Feb 23, 2010, at 7:56 PM, Diosney Sarmiento Herrera wrote:


Hi!

   Have any sense to blacklist the private address ranges on a server
that is facing Internet? I mean, this address ranges is not even  
routed

on the Internet.

   There is a trick about this?


No trick, it is commonly done.  For a good example of this (and many  
other things), see the Secure BIND Template at http://www.cymru.com/Documents/secure-bind-template.html 
.


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

Re: Differences between 9.3 and later versions

[Matus UHLAR - fantomas]

> On Feb 23 2010, Matus UHLAR - fantomas wrote:
>> since 9.5, the default for allow-recursion is { localhost; localnets; 
>> }; previous versions used iirc { all; }; 

On 23.02.10 16:48, Chris Thompson wrote:
> Actually, that change was made in 9.4. (Some of the cross-inheritance of
> the different query-* access controls wasn't there until 9.4.2, though).

sorry, I was looking at ChangeLog provided in debian's bind 9.5.1 (not the
debian changelog, the bind), and I didn't see any mention of releases
between 9.5a* and 9.2...

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: hosts or subnet number in delegation?

[Matus UHLAR - fantomas]

On 23.02.10 23:01, sasa sasa wrote:
> for a 192.168.199.64/26 in zone file to delegate to a customer;
> should i put subnet number:
> 
> 64/26 IN NS ns1.example.com.
> 64/26 IN NS ns2.example.com.
> 
> or host ranges:
> 
> 64-126 IN NS ns1.example.com.
> 64-126 IN NS ns2.example.com.
> 
> .
> .
> $GENERATE 65-126 $ CNAME $.65-126 

Note that addresses .64 and .127 belong to that range too (someone might
want to have record for them)

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Christian Science Programming: "Let God Debug It!".
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Modifying a response

[Peter Andreev]

Hello, everybody.

Is it possible to modify responses on caching server side?

For example: if user asks for non-existent domain, caching server replies
with some address and no-error rcode.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Modifying a response

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 01:28:09PM +0300,
 Peter Andreev  wrote 
 a message of 31 lines which said:

> Is it possible to modify responses on caching server side?

Not with BIND (short of modifying the source code). Other name servers
may do it
.

> For example: if user asks for non-existent domain, caching server
> replies with some address and no-error rcode.

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

Re: Fwd: IPv6 client and negative cache - some doubts

[Sam Wilson]

In article ,
 Michal Wesolowski  wrote:

> My server is caching only, I don't administer ns*.az.pl servers. I'm just
> trying to understand if binds copes well with such an external error. As you
> pointed out both servers fails in some (different) way but second one does
> this only when queried for something other than A record. For A everything
> is ok. THERE IS A record for virtual.jasnet.pl. Why bad response from
> external server for  record affects subsequent queries for A? Which
> entry of cache is responsible for this:

These:

> virtual.jasnet.pl.  3597A   85.202.208.254
> 3597CNAME   jasnet.pl.

You can't have both a CNAME and an A record for the same name.  I'm not 
sure which version of BIND you're using for your cache, but I'm slightly 
surprised it retains both records.

> Is it a case that unexpected response to  query from ns10.az.pl marks
> virtual.jasnet.pl invalid even for A queries?

It looks like it.  

> Sorry for my persistence

Keep it up.  Now you need to talk to the az.pl people and persuade them 
their server is broken.

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

Re: Fwd: IPv6 client and negative cache - some doubts

[Sam Wilson]

In article ,
 Mark Andrews  wrote:

> In message , 
> Micha
> l Wesolowski writes:
> > 
> > After some reading my present understanding is that correct response to 
> > 
> > query when there is such record in the zone and there exists another record
> > of different type for the same name - is to reply with empty answer and no
> > error (this applies to authoritative NS). So what ns10.az.pl does is not
> > consistent with specification.

That's correct.

> > However I'm still not sure if bind shouldn't cope with this somehow. I
> > understand that if it applied to final query for "www.goliszew.pl" than it
> > would be correct for bind to cache it as negative for all types of records.
> > But if it concerns bad respond for NS? - I don't know.

I don't either.

> Well one of the nameservers does not exist and the other is a CNAME.
> Both of these are fatal errors for the particular nameserver and
> as there are only two nameservers for the zone lookups fail.

I hesitate to take issue with you Mark, but the problem is also that one 
of the nameservers has either an A record or a CNAME depending on how 
you look it up (A or  query), and his caching server is keeping them 
both.

> Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl
> and virtual.jasnet.pl respectively.

As the OP has pointed out that's not under his control, and if the same 
misbehaving servers are responsible there's the chance that both will be 
screwed up.

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

Re: Modifying a response

[Peter Andreev]

2010/2/24 Stephane Bortzmeyer 

> On Wed, Feb 24, 2010 at 01:28:09PM +0300,
>  Peter Andreev  wrote
>  a message of 31 lines which said:
>
> > Is it possible to modify responses on caching server side?
>
> Not with BIND (short of modifying the source code). Other name servers
> may do it
> .


I hoped there is something like plugin which isn't mentioned in manual.

> For example: if user asks for non-existent domain, caching server
> > replies with some address and no-error rcode.
>
> _Extremely_ bad idea.
>

Yes, I know, but boss is boss and task is task :).

Thank you very much for your answer.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Modifying a response

[Alan Clegg]

Peter Andreev wrote:

> > For example: if user asks for non-existent domain, caching server
> > replies with some address and no-error rcode.
> 
> _Extremely_ bad idea.
> 
> 
> Yes, I know, but boss is boss and task is task :).
> 
> Thank you very much for your answer.

You might want to talk to your boss about DNSSEC and how it insures that
"answer modification" is not allowed -- and how it keeps your customers
safe and secure and is a good selling point (see the Comcast
announcement that was made yesterday).

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Modifying a response

[Peter Andreev]

2010/2/24 Alan Clegg 

> Peter Andreev wrote:
>
> > > For example: if user asks for non-existent domain, caching server
> > > replies with some address and no-error rcode.
> >
> > _Extremely_ bad idea.
> >
> >
> > Yes, I know, but boss is boss and task is task :).
> >
> > Thank you very much for your answer.
>
> You might want to talk to your boss about DNSSEC and how it insures that
> "answer modification" is not allowed -- and how it keeps your customers
> safe and secure and is a good selling point (see the Comcast
> announcement that was made yesterday).
>
> AlanC
>
> Oh, DNSSSEC is another headache. These two tasks doesn't influence each
other.

Thank you for advice

>
> ___
> 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: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 10:18:31AM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 39 lines which said:

> With 'severity debug 30', all I get is:

And, for a successful dynamic update (it works with A records):

24-Feb-2010 14:31:44.803 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': prerequisites are OK
24-Feb-2010 14:31:44.803 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': update section prescan OK
24-Feb-2010 14:31:44.803 update: info: client ::1#13202: updating zone 
'toto.fr/IN': adding an RR at 'created-dyn-1267018304-26805.toto.fr' A
24-Feb-2010 14:31:44.803 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': checking for NSEC3PARAM changes
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': updated data signatures
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': removed any orphaned NSEC records
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': rebuilding NSEC3 chains
24-Feb-2010 14:31:44.806 update: debug 3: client ::1#13202: updating zone 
'toto.fr/IN': signing rebuilt NSEC3 chain
24-Feb-2010 14:31:44.808 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': writing journal toto.fr.db.signed.jnl
24-Feb-2010 14:31:44.819 update: debug 8: client ::1#13202: updating zone 
'toto.fr/IN': committing update transaction

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

RE: Query denied errors on PTR records for delegated zone

[Lightner, Jeff]

Nice write up.  It explains WHY we had the weird delegation on switching
carriers a few years back and also explains why I had to put my kluge
in.

However, I wonder how easy it is in practice to get a company the size
of AT&T to do individual delegations for dozens or hundreds of IPs?
You mention it as if it is a non-issue but I suspect they'd balk at such
a request.

-Original Message-
From: Jonathan de Boyne Pollard
[mailto:j.deboynepollard-newsgro...@ntlworld.com] 
Sent: Wednesday, February 24, 2010 4:36 AM
To: Lightner, Jeff; BIND users mailing list
Subject: Re: Query denied errors on PTR records for delegated zone

I did run into some oddities in setting up arpa zones to be able
to query them inside my network and outside my network [...]

You've hit one of the several reasons that RFC 2317 style delegation
should be avoided
 : Your lookup tools require a specific structure for
reverse-lookup domain names, but your delegation scheme imposes a
different structure.  RFC 2317 style delegation broke the convenience
features of your lookup tools.


I note it as originally I was pulling my hair out trying to
figure out why digs directly to my DNS server via the internal facing
interface wouldn't resolve like the ones on the external facing
interface.

You're wishing that you'd read the aforelinked Frequently Given Answer
ages ago, now, aren't you?  (-:
 
Proud partner. Susan G. Komen for the Cure.
 
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6.2rc1 make test question

[Stacey Jonathan Marshall]

On 02/15/10 20:25, John Center wrote:

Hi,

I just built BIND 9.6.2rc1 & make test passes except for the following:

A:the dst module provides the capability to verify data signed with 
the RSA and DSA algorithms

I:testing t2_data_1, t2_dsasig, test., 23616, DST_ALG_DSA, ISC_R_SUCCESS
I:testing t2_data_1, t2_rsasig, test., 54622, DST_ALG_RSAMD5, 
ISC_R_SUCCESS
I:testing t2_data_1, t2_dsasig, test., 54622, DST_ALG_RSAMD5, 
!ISC_R_SUCCESS

I:testing t2_data_2, t2_dsasig, test., 23616, DST_ALG_DSA, !ISC_R_SUCCESS
mem.c:322: INSIST(dl != 0L) failed.
I:the test case caused exception 6
R:UNRESOLVED

What does this mean & where do I look to resolve this issue?

Thanks.

-John


John,

You don't state what your building on? I too have come across the same 
error on OpenSolaris circa snv_117.


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

Re: Update returns FORMERR: ran out of space

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 10:18:31AM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 39 lines which said:

> 24-Feb-2010 10:17:01.057 update: error: client ::1#45986: updating zone 
> 'toto.fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space

Adding a fair amount of debugging traces, I can get the line number:

24-Feb-2010 15:04:26.343 update: info: client ::1#60371: updating zone 
'toto.fr/IN': error: ran out of space at line 1945

which, in my case, is:

/* Calculate the signature, creating a RRSIG RDATA. */
CHECKV(dns_dnssec_sign(name, &rdataset, keys[i],
  &inception, &expire,
  mctx, &buffer, &sig_rdata));

So, the problem lies somewhere in dns_dnssec_sign but my knowledge
stops there.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Modifying a response

[Stephane Bortzmeyer]

On Wed, Feb 24, 2010 at 11:37:29AM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 18 lines which said:

> Other name servers may do it

http://www.unbound.net/documentation/pythonmod/index.html
http://www.unbound.net/documentation/pythonmod/examples/example3.html
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Joe Baptista]

reply below

On Wed, Feb 24, 2010 at 1:06 AM, Evan Hunt  wrote:

>
> > I humbly suggest Dr. Bernstein who is behind DNScurve thinks the IETF is
> > full of wackos. So it is unlikely he will ever be bothered to dance the
> > IETF RFC jig.
>
> Is there a requirement that Dr. Bernstein must personally do the dancing?
> Let someone else write the RFC, if it needs writing.
>

Someone else has written the RFC draft - which see http://bit.ly/b5mFkV

Looks like Matthew Dempsky and OpenDNS have taken the lead here.



>
> While the existence of an RFC isn't an absolute requirement for BIND to
> implement something, it certainly helps.  But what helps a lot more is
> evidence that the thing in question is getting widespread use, or that
> there's significant user demand for it.


Now there is. OpenDNS support of DNScurve means over 20 billion DNS queries
per day. I think thats enough evidence to get cracking and write the code.


> So far, we're not seeing either
> of those things with DNSCurve.


Were not seeing much of the same with DNSSEC.

Thats not the case with DNScurve. Again I stress - over 20 billion requests
per day at OpenDNS are DNScurve compatible.The traffic in DNSSEC is chicken
feed compared to DNScurve.


> When we do, I'll be happy to write the
> code.
>

It's happened - start writing.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Joe Baptista]

On Wed, Feb 24, 2010 at 1:13 AM, Michael Sinatra <
mich...@rancid.berkeley.edu> wrote:

> As someone who both signs his production zones and does DNSSEC validation,
> I can assure you that DNSSEC works.  But you've done as good job as I can
> imagine in making the case for DNScurve.
>

Done.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Michael Sinatra]

On 02/24/10 01:25, Jonathan de Boyne Pollard wrote:



DNScurve advocates, on the other hand, point out that DNS isn't
encrypted. Well, neither is the phone book. So what?


So the protocol is vulnerable to both local and remote forgery attacks,
just like other unencrypted protocols
.
For any that don't understand this point, there's a simple thought to
prod them in the right direction: Do you remember why SSH and SSL were
invented?


Do you understand the difference between encryption and authentication? 
 SSH and SSL do both because they protect the payload, which may be 
sensitive, AND they want to verify that the server you're talking to is 
really the one you want.  DNS only needs authentication.  DNSSEC 
prevents forgery without encrypting the payload.



Do you remember, say, the forgery problems with TELNET and
HTTP?


The bigger problems with TELNET and HTTP were that they could be sniffed 
on the wire to get confidential information like passwords.  Forgery was 
conveniently solved by cryptography along the way, but confidentiality 
was in issue with these protocols, unlike with DNS.



The /very same problems exist/ for unencrypted UDP/IP protocols
such as DNS and NTP. And the solution is the same, too.


Yes, cryptographic signatures, not full encryption.  Just like NTP with 
Autokey.


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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Alan Clegg]

Joe Baptista wrote:

> Thats not the case with DNScurve. Again I stress - over 20 billion
> requests per day at OpenDNS are DNScurve compatible.The traffic in
> DNSSEC is chicken feed compared to DNScurve.

Joe,

The fact that queries hit servers that are DNScurve capable does not
mean that they are taking any advantage of the DNScurve protocol.

I'm sure that there are more "DO bit" queries in the world than DNScurve
label queries on any given day -- and not only DO bit queries, but
queries that hit servers that are DNSSEC capable.

The fact that DNScurve allows OpenDNS to continue modifying responses
while "proving" that their answers are authentic tells me that there is
a gaping hole in the DNScurve protocol...

Follow the money.  OpenDNS has fought against DNSSEC because it
prohibits their "Intelligent Navigation" (Typo correction) and
redirection of google...  They "approve" of DNScurve because it can be
subverted.

 ; <<>> DiG 9.7.0 <<>> @208.67.222.222 www.google.com
 [...]
 ;; ANSWER SECTION:
 www.google.com.  30 IN CNAMEgoogle.navigation.opendns.com.
 google.navigation.opendns.com. 30 IN   A   208.69.32.230
 google.navigation.opendns.com. 30 IN   A   208.69.32.231

That's not the google I was looking for...

I'm in no way saying that BIND won't at some point in the future support
DNScurve, I'm just saying that to try to prove the need by pointing to
OpenDNS is not the justification that is needed.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Query denied errors on PTR records for delegated zone

[Matus UHLAR - fantomas]

On 24.02.10 08:31, Lightner, Jeff wrote:
> From: "Lightner, Jeff" 
> Date: Wed, 24 Feb 2010 08:31:44 -0500
> Subject: RE: Query denied errors on PTR records for delegated zone
> To: Jonathan de Boyne Pollard ,
>   BIND users mailing list 
> 
> Nice write up.  It explains WHY we had the weird delegation on switching
> carriers a few years back and also explains why I had to put my kluge
> in.
> 
> However, I wonder how easy it is in practice to get a company the size
> of AT&T to do individual delegations for dozens or hundreds of IPs?
> You mention it as if it is a non-issue but I suspect they'd balk at such
> a request.
> 
> -Original Message-
> From: Jonathan de Boyne Pollard
> [mailto:j.deboynepollard-newsgro...@ntlworld.com] 
> Sent: Wednesday, February 24, 2010 4:36 AM
> To: Lightner, Jeff; BIND users mailing list
> Subject: Re: Query denied errors on PTR records for delegated zone
> 
>   I did run into some oddities in setting up arpa zones to be able
> to query them inside my network and outside my network [...]
> 
> You've hit one of the several reasons that RFC 2317 style delegation
> should be avoided
>  7-delegation.html> : Your lookup tools require a specific structure for
> reverse-lookup domain names, but your delegation scheme imposes a
> different structure.  RFC 2317 style delegation broke the convenience
> features of your lookup tools.
> 
> 
>   I note it as originally I was pulling my hair out trying to
> figure out why digs directly to my DNS server via the internal facing
> interface wouldn't resolve like the ones on the external facing
> interface.
> 
> You're wishing that you'd read the aforelinked Frequently Given Answer
> ages ago, now, aren't you?  (-:
>  
> Proud partner. Susan G. Komen for the Cure.
>  
> Please consider our environment before printing this e-mail or attachments.
> --
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
> information and is for the sole use of the intended recipient(s). If you are 
> not the intended recipient, any disclosure, copying, distribution, or use of 
> the contents of this information is prohibited and may be unlawful. If you 
> have received this electronic transmission in error, please reply immediately 
> to the sender that you have received the message in error, and delete it. 
> Thank you.
> --
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
It's now safe to throw off your computer.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Query denied errors on PTR records for delegated zone

[Matus UHLAR - fantomas]

sorry for the first post, accidentally hit send instead of drop...

On 24.02.10 08:31, Lightner, Jeff wrote:
> Nice write up.  It explains WHY we had the weird delegation on switching
> carriers a few years back and also explains why I had to put my kluge
> in.
> 
> However, I wonder how easy it is in practice to get a company the size
> of AT&T to do individual delegations for dozens or hundreds of IPs?
> You mention it as if it is a non-issue but I suspect they'd balk at such
> a request.
> 
> -Original Message-
> From: Jonathan de Boyne Pollard
> [mailto:j.deboynepollard-newsgro...@ntlworld.com] 
> Sent: Wednesday, February 24, 2010 4:36 AM
> To: Lightner, Jeff; BIND users mailing list
> Subject: Re: Query denied errors on PTR records for delegated zone
> 
>   I did run into some oddities in setting up arpa zones to be able
> to query them inside my network and outside my network [...]
> 
> You've hit one of the several reasons that RFC 2317 style delegation
> should be avoided
>  7-delegation.html> : Your lookup tools require a specific structure for
> reverse-lookup domain names, but your delegation scheme imposes a
> different structure.  RFC 2317 style delegation broke the convenience
> features of your lookup tools.

This is imho bad:
By delegating the djbdns' way, you are creating bunch of NS records for each
one PTR, instead of bunch NS records for a zone and one CNAME for each PTR.

I've been solving problems where a record was delegated to other
servers (load balancers) via NS records, when those didn't reply by anything
but A (in this case it would be PTR). That caused troubles and my
recommentation was to create full zone for the delegation.

Creating full zones for 128 IPs in /25 delegation would be, ehm, bloated.
Those tools and nameservers should be fixed imho.
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Blacklisting private address range

[Tony Finch]

On Wed, 24 Feb 2010, Stephane Bortzmeyer wrote:
> On Tue, Feb 23, 2010 at 09:56:55PM -0500,
>  Diosney Sarmiento Herrera  wrote:
>
> > Have any sense to blacklist the private address ranges on a server
> > that is facing Internet?
>
> I am not sure I parse your sentence correctly but may be you refer to
> the "Rebinding prevention feature" which appeared in 9.7.0?
>
> deny-answer-addresses { 10.0.0.0/8; }
> deny-answer-addresses { 172.16.0.0/12; }
> deny-answer-addresses { 192.168.0.0/16; }

We also do the following to stop BIND from trying to talk to name servers
in bogon address space:

server 0.0.0.0/8{ bogus yes; };
server 10.0.0.0/8   { bogus yes; };
server 127.0.0.0/8  { bogus yes; };
server 169.254.0.0/16   { bogus yes; };
server 172.16.0.0/12{ bogus yes; };
server 192.0.0.0/24 { bogus yes; };
server 192.0.2.0/24 { bogus yes; };
server 192.168.0.0/16   { bogus yes; };
server 198.18.0.0/15{ bogus yes; };
server 198.51.100.0/24  { bogus yes; };
server 203.0.113.0/24   { bogus yes; };
server 224.0.0.0/3  { bogus yes; };

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Tony Finch]

On Tue, 23 Feb 2010, Joe Baptista wrote:
>
> Lets not forget the IETF has had 15 years to secure the DNS. The result is
> the DNSSEC abortion. It has failed.

It looks pretty lively to me. DNSSEC has multiple interoperable
implementations, and it will be deployed in the most important zones this
year. DNScurve doesn't even have one publicly available implementation.

> This announcement today is a stiff well deserved kick in the balls to
> the DNSSEC crowd.

It's a tickle compared to the flood of interest in Comcast's announcement
of DNSSEC support.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Evan Hunt]

> Thats not the case with DNScurve. Again I stress - over 20 billion
> requests per day at OpenDNS are DNScurve compatible. The traffic in
> DNSSEC is chicken feed compared to DNScurve.

ORG and GOV and quite a lot of the ccTLD's are "DNSSEC compatible", so I
don't actually think it'd be much of a horserace if compatibility is all
you're looking for.  What'll be interesting is how many queries the root
and TLD servers start seeing for uz5*/NS.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Paul Wouters]

On Wed, 24 Feb 2010, Tony Finch wrote:


On Tue, 23 Feb 2010, Joe Baptista wrote:


Lets not forget the IETF has had 15 years to secure the DNS. The result is
the DNSSEC abortion. It has failed.


It looks pretty lively to me. DNSSEC has multiple interoperable
implementations, and it will be deployed in the most important zones this
year. DNScurve doesn't even have one publicly available implementation.


Nor do dnscurve.* or opendns.* domains even use dnscurve themselves. If
the inventors are not even running it, and we have no minimal two
independantly written interoperable implementations, it's clearly not
meant to be used outside the reseach labs, and telling others (ISC)
to do your work seems rather out of place.

This has neither concensus or running code or a publicly testable deployment.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Chris Thompson]

On Feb 24 2010, Evan Hunt wrote:


Thats not the case with DNScurve. Again I stress - over 20 billion
requests per day at OpenDNS are DNScurve compatible. The traffic in
DNSSEC is chicken feed compared to DNScurve.


ORG and GOV and quite a lot of the ccTLD's are "DNSSEC compatible", so I
don't actually think it'd be much of a horserace if compatibility is all
you're looking for.  What'll be interesting is how many queries the root
and TLD servers start seeing for uz5*/NS.


If OpenDNS really believe that DNScurve is the way of the future, why
don't they have such NS records for opendns.com?

--
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: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Sam Wilson]

In article ,
 Chris Thompson  wrote:

> On Feb 24 2010, Evan Hunt wrote:
> 
> >> Thats not the case with DNScurve. Again I stress - over 20 billion
> >> requests per day at OpenDNS are DNScurve compatible. The traffic in
> >> DNSSEC is chicken feed compared to DNScurve.
> >
> >ORG and GOV and quite a lot of the ccTLD's are "DNSSEC compatible", so I
> >don't actually think it'd be much of a horserace if compatibility is all
> >you're looking for.  What'll be interesting is how many queries the root
> >and TLD servers start seeing for uz5*/NS.
> 
> If OpenDNS really believe that DNScurve is the way of the future, why
> don't they have such NS records for opendns.com?

And what effect will 54-character names for nameservers have when the 
description recommends against using TCP or UDP with packets longer than 
512 bytes (EDNS0, anyone?).

Actually the idea of encoding your public key your name, whilst 
superficially neat, sounds like a killer to me.  How will I ever 
remember which server is which?

Has anyone found any uz5* servers out there yet?

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

Re: Blacklisting private address range

[Warren Kumari]

On Feb 24, 2010, at 11:23 AM, Tony Finch wrote:


On Wed, 24 Feb 2010, Stephane Bortzmeyer wrote:

On Tue, Feb 23, 2010 at 09:56:55PM -0500,
Diosney Sarmiento Herrera  wrote:


Have any sense to blacklist the private address ranges on a server
that is facing Internet?


I am not sure I parse your sentence correctly but may be you refer to
the "Rebinding prevention feature" which appeared in 9.7.0?

deny-answer-addresses { 10.0.0.0/8; }
deny-answer-addresses { 172.16.0.0/12; }
deny-answer-addresses { 192.168.0.0/16; }


We also do the following to stop BIND from trying to talk to name  
servers

in bogon address space:



Yes, but remember to be careful as to how you are using the term  
'bogon' -- some folks include things like (currently) unassigned space  
in their definition of bogon, which is fine till the space gets  
allocated, at which time hilarity ensues.





server 0.0.0.0/8{ bogus yes; };
server 10.0.0.0/8   { bogus yes; };
server 127.0.0.0/8  { bogus yes; };
server 169.254.0.0/16   { bogus yes; };
server 172.16.0.0/12{ bogus yes; };
server 192.0.0.0/24 { bogus yes; };
server 192.0.2.0/24 { bogus yes; };
server 192.168.0.0/16   { bogus yes; };
server 198.18.0.0/15{ bogus yes; };
server 198.51.100.0/24  { bogus yes; };
server 203.0.113.0/24   { bogus yes; };
server 224.0.0.0/3  { bogus yes; };


Ok, fair 'nuff.

W




Tony.
--
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY  
SHOWERS.

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


--
"When it comes to glittering objects, wizards have all the taste and  
self-control of a deranged magpie."

-- Terry Pratchett




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

Random slow queries

[Mike Chesney]

Running Bind 9.6.1-P3

We run authorative DNS for 60k+ zones.  One one network where we two dns
servers both running the same hardware on Centos 5.4

We see slow dns responses : example

for i in {1..250}; do dig example.com @localhost | grep "Query time:"; done;

Sometimes they'll all come back w/ a 0msec response .  But every few runs we
see.
; Query time: 501 msec
;; Query time: 111 msec
;; Query time: 0 msec
;; Query time: 0 msec
; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 1461 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 441 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

This is just a snapshot, most other entries are all 0.  This doesn't happen
on any of our other dns servers.  Load is pretty low on this machine around
.3   4gb ram.  Named consumes about 15% of memory and 4% of cpu.  Not sure
where to look next.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Zone transfers from slaves to slaves?

[Dan Letkeman]

Hello,

I think I have a configuration issue somewhere.  It looks like from
the logs that my master server is notifying the slaves correctly, but
then the other slaves are also notifying the slaves as well.

172.16.0.100 is the master
172.16.0.101 is 1st slave
172.16.0.102 is 2nd slave

Here is a log from a zone update on 172.16.0.101 (1st slave)


24-Feb-2010 13:31:52.717 notify: info: client 172.16.0.100#58960:
received notify for zone 'guest.company.com'
24-Feb-2010 13:31:52.718 general: info: zone guest.company.com/IN:
Transfer started.
24-Feb-2010 13:31:52.718 xfer-in: info: transfer of
'guest.company.com/IN' from 172.16.0.100#53: connected using
172.16.0.101#33350
24-Feb-2010 13:31:52.721 general: info: zone guest.company.com/IN:
transferred serial 1263866844
24-Feb-2010 13:31:52.721 xfer-in: info: transfer of
'guest.company.com/IN' from 172.16.0.100#53: end of transfer
24-Feb-2010 13:31:52.722 notify: info: zone guest.company.com/IN:
sending notifies (serial 1263866844)
24-Feb-2010 13:31:53.219 notify: info: client 172.16.0.100#46912:
received notify for zone 'guest.company.com'
24-Feb-2010 13:31:53.219 general: info: zone guest.company.com/IN:
notify from 172.16.0.100#46912: zone is up to date
24-Feb-2010 13:31:53.220 notify: info: client 172.16.0.101#37186:
received notify for zone 'guest.company.com'
24-Feb-2010 13:31:53.220 general: info: zone guest.company.com/IN:
refused notify from non-master: 172.16.0.101#37186
24-Feb-2010 13:31:53.220 notify: info: client 172.16.0.100#46912:
received notify for zone '7.0.10.in-addr.arpa'
24-Feb-2010 13:31:53.220 general: info: zone 7.0.10.in-addr.arpa/IN:
Transfer started.
24-Feb-2010 13:31:53.221 xfer-in: info: transfer of
'7.0.10.in-addr.arpa/IN' from 172.16.0.100#53: connected using
172.16.0.101#32980
24-Feb-2010 13:31:53.223 general: info: zone 7.0.10.in-addr.arpa/IN:
transferred serial 1263866144
24-Feb-2010 13:31:53.223 xfer-in: info: transfer of
'7.0.10.in-addr.arpa/IN' from 172.16.0.100#53: end of transfer
24-Feb-2010 13:31:53.223 notify: info: zone 7.0.10.in-addr.arpa/IN:
sending notifies (serial 1263866144)
24-Feb-2010 13:31:53.731 notify: info: client 172.16.0.102#30923:
received notify for zone 'guest.company.com'
24-Feb-2010 13:31:53.731 general: info: zone guest.company.com/IN:
notify from 172.16.0.102#30923: zone is up to date
24-Feb-2010 13:31:53.832 notify: info: client 172.16.0.101#36686:
received notify for zone '7.0.10.in-addr.arpa'
24-Feb-2010 13:31:53.832 general: info: zone 7.0.10.in-addr.arpa/IN:
refused notify from non-master: 172.16.0.101#36686
24-Feb-2010 13:31:54.244 notify: info: client 172.16.0.102#57854:
received notify for zone '7.0.10.in-addr.arpa'
24-Feb-2010 13:31:54.245 general: info: zone 7.0.10.in-addr.arpa/IN:
notify from 172.16.0.102#57854: zone is up to date

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

Re: Zone transfers from slaves to slaves?

[Alan Clegg]

Dan Letkeman wrote:

> I think I have a configuration issue somewhere.  It looks like from
> the logs that my master server is notifying the slaves correctly, but
> then the other slaves are also notifying the slaves as well.
> 
> 172.16.0.100 is the master
> 172.16.0.101 is 1st slave
> 172.16.0.102 is 2nd slave

Zone transfers can take place between slaves as well.  If you want to
limit the number of NOTIFY messages, you may want to look into:

   "also-notify { list; };"
and
   "notify explicit;"

What you are seeing is in the case where you have a master server that
is not visible to all slaves -- slaves must be able to let their peers
know that they themselves have been updated.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[bsfinkel]

Joe Baptista  wrote:
>Someone else has written the RFC draft - which see http://bit.ly/b5mFkV

That draft has this text, "Expires: February 27, 2010" [3 days from
today].  I am not sure what an expiration date means officially on a
draft RFC.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory  Phone:+1 (630) 252-7277
9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL   60439-4828 IBMMAIL:  I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: BIND 9.6.2rc1 make test question

[John Center]

Hi Stace,

Sorry, I didn't think this was necessarily a Solaris problem.  I'm running this 
on Solaris 10 (SPARC 64bit), built with Sun Studio 12.1.  Why did it occur on 
OpenSolaris?

Thanks.

-John


From: stacey.marsh...@sun.com [stacey.marsh...@sun.com]
Sent: Wednesday, February 24, 2010 9:01 AM
To: John Center
Cc: bind-users@lists.isc.org
Subject: Re: BIND 9.6.2rc1 make test question

On 02/15/10 20:25, John Center wrote:
> Hi,
>
> I just built BIND 9.6.2rc1 & make test passes except for the following:
>
> A:the dst module provides the capability to verify data signed with
> the RSA and DSA algorithms
> I:testing t2_data_1, t2_dsasig, test., 23616, DST_ALG_DSA, ISC_R_SUCCESS
> I:testing t2_data_1, t2_rsasig, test., 54622, DST_ALG_RSAMD5,
> ISC_R_SUCCESS
> I:testing t2_data_1, t2_dsasig, test., 54622, DST_ALG_RSAMD5,
> !ISC_R_SUCCESS
> I:testing t2_data_2, t2_dsasig, test., 23616, DST_ALG_DSA, !ISC_R_SUCCESS
> mem.c:322: INSIST(dl != 0L) failed.
> I:the test case caused exception 6
> R:UNRESOLVED
>
> What does this mean & where do I look to resolve this issue?
>
> Thanks.
>
> -John
>
John,

You don't state what your building on? I too have come across the same
error on OpenSolaris circa snv_117.

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

RE: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Lightner, Jeff]

>From the BCP79 referenced at top of the draft:

" d. "Internet-Draft": temporary documents used in the IETF and RFC
  Editor processes.  Internet-Drafts are posted on the IETF web site
  by the IETF Secretariat and have a nominal maximum lifetime in the
  Secretariat's public directory of 6 months, after which they are
  removed.  Note that Internet-Drafts are archived many places on
  the Internet, and not all of these places remove expired
  Internet-Drafts.  Internet-Drafts that are under active
  consideration by the IESG are not removed from the Secretariat's
  public directory until that consideration is complete.  In
  addition, the author of an Internet-Draft can request that the
  lifetime in the Secretariat's public directory be extended before
  the expiration."

-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of bsfin...@anl.gov
Sent: Wednesday, February 24, 2010 3:49 PM
To: bind-users@lists.isc.org
Subject: Re: OpenDNS today announced it has adopted DNSCurve to secure
DNS

Joe Baptista  wrote:
>Someone else has written the RFC draft - which see http://bit.ly/b5mFkV

That draft has this text, "Expires: February 27, 2010" [3 days from
today].  I am not sure what an expiration date means officially on a
draft RFC.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory  Phone:+1 (630) 252-7277
9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL   60439-4828 IBMMAIL:  I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
 
Proud partner. Susan G. Komen for the Cure.
 
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Fwd: IPv6 client and negative cache - some doubts

[Mark Andrews]

In message , Sam Wilson wri
tes:
> In article ,
>  Mark Andrews  wrote:
> 
> > In message , 
> > Micha
> > l Wesolowski writes:
> > > 
> > > After some reading my present understanding is that correct response to 
> > > 
> > > query when there is such record in the zone and there exists another reco
> rd
> > > of different type for the same name - is to reply with empty answer and n
> o
> > > error (this applies to authoritative NS). So what ns10.az.pl does is not
> > > consistent with specification.
> 
> That's correct.
> 
> > > However I'm still not sure if bind shouldn't cope with this somehow. I
> > > understand that if it applied to final query for "www.goliszew.pl" than i
> t
> > > would be correct for bind to cache it as negative for all types of record
> s.
> > > But if it concerns bad respond for NS? - I don't know.
> 
> I don't either.
> 
> > Well one of the nameservers does not exist and the other is a CNAME.
> > Both of these are fatal errors for the particular nameserver and
> > as there are only two nameservers for the zone lookups fail.
> 
> I hesitate to take issue with you Mark, but the problem is also that one 
> of the nameservers has either an A record or a CNAME depending on how 
> you look it up (A or  query), and his caching server is keeping them 
> both.

Named sees the CNAME for virtual.jasnet.pl and marks the server as bad.
Named sees the NXDOMAIN for virtual.sincom.pl and marks the server as bad.

> > Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl
> > and virtual.jasnet.pl respectively.
> 
> As the OP has pointed out that's not under his control, and if the same 
> misbehaving servers are responsible there's the chance that both will be 
> screwed up.

Well he needs to complain to the administrators of the zones as
they are not following the relevent RFC's and their nameservers are
not preventing them from making configuration errors by allowing
the A and CNAME to co-exist virtual.jasnet.pl.

RFC 1034, Section 3.6.2.

"If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different."

He should also complain to the administrators for .PL for not
following RFC 1034 and ensuring that delegation start off and
continue to be RFC compliant.
 
RFC 1034, Section 4.2.2.

"As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so."

> Sam
> ___
> 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: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Update returns FORMERR: ran out of space

[Mark Andrews]

In message <20100224091831.ga3...@nic.fr>, Stephane Bortzmeyer writes:
> On Wed, Feb 24, 2010 at 11:32:35AM +1100,
>  Mark Andrews  wrote 
>  a message of 35 lines which said:
> 
> > Turn the debugging up to 3. 
> 
> With 'severity debug 30', all I get is:
> 
> 24-Feb-2010 10:17:01.047 update: debug 8: client ::1#45986: updating zone 'to
> to.fr/IN': prerequisites are OK
> 24-Feb-2010 10:17:01.047 update: debug 8: client ::1#45986: updating zone 'to
> to.fr/IN': update section prescan OK
> 24-Feb-2010 10:17:01.047 update: info: client ::1#45986: updating zone 'toto.
> fr/IN': adding an RR at 'toto.fr' DNSKEY
> 24-Feb-2010 10:17:01.048 update: debug 3: client ::1#45986: updating zone 'to
> to.fr/IN': checking for NSEC3PARAM changes
> 24-Feb-2010 10:17:01.057 update: error: client ::1#45986: updating zone 'toto
> .fr/IN': RRSIG/NSEC/NSEC3 update failed: ran out of space
> 24-Feb-2010 10:17:01.057 update: debug 8: client ::1#45986: updating zone 'to
> to.fr/IN': rolling back
> 
> I log 'dnssec' events:
> 
> logging {
>   channel debugging {
>  file "/tmp/bind-dnssec.log" versions 2 size 5m;
>severity debug 30;
>print-time yes;
>  print-severity yes;
>  print-category yes;
>};
>   category update {
> debugging;
>   };
>   category dnssec {
> debugging;
>   };
> };
> 
> 
> But I do not see them in the log.

You won't see DNSSEC events as DNSSEC basically covers validation.

Try this patch.  It resets the scratch space 'data' used by
dns_dnssec_sign().

Index: bin/named/update.c
===
RCS file: /proj/cvs/prod/bind9/bin/named/update.c,v
retrieving revision 1.176.4.3
diff -u -r1.176.4.3 update.c
--- bin/named/update.c  30 Dec 2009 03:55:03 -  1.176.4.3
+++ bin/named/update.c  24 Feb 2010 22:58:21 -
@@ -1941,6 +1941,7 @@
CHECK(update_one_rr(db, ver, diff, DNS_DIFFOP_ADDRESIGN, name,
rdataset.ttl, &sig_rdata));
dns_rdata_reset(&sig_rdata);
+   isc_buffer_init(&buffer, data, sizeof(data));
added_sig = ISC_TRUE;
}
if (!added_sig) {
-- 
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: Zone transfers from slaves to slaves?

[Mark Andrews]

In message <4b8586a0.2030...@isc.org>, Alan Clegg writes:
> Dan Letkeman wrote:
> 
> > I think I have a configuration issue somewhere.  It looks like from
> > the logs that my master server is notifying the slaves correctly, but
> > then the other slaves are also notifying the slaves as well.
> >=20
> > 172.16.0.100 is the master
> > 172.16.0.101 is 1st slave
> > 172.16.0.102 is 2nd slave
> 
> Zone transfers can take place between slaves as well.  If you want to
> limit the number of NOTIFY messages, you may want to look into:
> 
>"also-notify { list; };"
> and
>"notify explicit;"
> 
> What you are seeing is in the case where you have a master server that
> is not visible to all slaves -- slaves must be able to let their peers
> know that they themselves have been updated.

And "notify master-only;" in later versions of named.
 
> AlanC
-- 
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: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Joe Baptista]

On Wed, Feb 24, 2010 at 11:33 AM, Evan Hunt  wrote:

> > Thats not the case with DNScurve. Again I stress - over 20 billion
> > requests per day at OpenDNS are DNScurve compatible. The traffic in
> > DNSSEC is chicken feed compared to DNScurve.
>
> ORG and GOV and quite a lot of the ccTLD's are "DNSSEC compatible", so I
> don't actually think it'd be much of a horserace if compatibility is all
> you're looking for.


I agree they are both DNSSEC compatible but .GOV has only deployed DNSSEC in
20% of it's zones. I'm not sure what the percentage is in .ORG - 5% ? less ?
is it even 1% of the zones? The make work project continues.

Thats what I like about DNScurve. No make work projects.

But I get your point.


>  What'll be interesting is how many queries the root
> and TLD servers start seeing for uz5*/NS.
>

It's going to be interesting to watch. I guess that depends on if DNSSEC is
turned on by default in BIND. Incidentally - is it?

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Alan Clegg]

Joe Baptista wrote:

> [] I guess that depends on if DNSSEC
> is turned on by default in BIND. Incidentally - is it?

   dnssec-enable yes;
and
   dnssec-validation yes;

are the defaults since BIND 9.5

Serving signed zones requires signed zone data to serve.

Validation requires configuration of trust anchors.

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Joe Baptista]

On Wed, Feb 24, 2010 at 10:08 PM, Alan Clegg  wrote:

>
>   dnssec-enable yes;
> and
>   dnssec-validation yes;
>
> are the defaults since BIND 9.5
>
>
How do I turn it off.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Alan Clegg]

Joe Baptista wrote:

>   dnssec-enable yes;
> and
>   dnssec-validation yes;
> 
> are the defaults since BIND 9.5
> 
> 
> How do I turn it off.

Since you edited out the most important part of my post, I'll repeat it
here before I answer your question:

Serving signed zones requires signed zone data to serve.
Validation requires configuration of trust anchors.

To "turn it off",

Don't sign your zones and don't configure trust anchors.

Or, if you think you might accidentally sign your zones or configure
trust anchors, you can:

 dnssec-enable no;
 dnssec-validation no;

AlanC



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Evan Hunt]

> It's going to be interesting to watch. I guess that depends on if DNSSEC is
> turned on by default in BIND. Incidentally - is it?

That depends on what you mean by "turned on".  The DNSSEC protocol is
enabled, and the DO bit is set in queries, so authoritative servers with
signed data will send it.

But the DO bit is merely a flag that says "if you send me DNSSEC signatures
I won't catch fire," it doesn't actually switch on DNSSEC in any meaningful
way.  DNSSEC validation only becomes active when you've configured a trust
anchor, and that is *not* done by default.

(There is a built-in trust anchor for dlv.isc.org included with BIND 9.7,
but you have to turn on a config option for it to be used, and that will
not change.  We would like people to trust us, and we wanted to make it
as easy as possible to do so, but we don't think we'd be worthy of trust
if we made it the default.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Paul Wouters]

On Thu, 25 Feb 2010, Evan Hunt wrote:


It's going to be interesting to watch. I guess that depends on if DNSSEC is
turned on by default in BIND. Incidentally - is it?


That depends on what you mean by "turned on".  The DNSSEC protocol is
enabled, and the DO bit is set in queries, so authoritative servers with
signed data will send it.


The default in Fedora has been "on" with many keys and DLV since Fedora-12.
That's about 6 months now.


(There is a built-in trust anchor for dlv.isc.org included with BIND 9.7,
but you have to turn on a config option for it to be used, and that will
not change.  We would like people to trust us, and we wanted to make it
as easy as possible to do so, but we don't think we'd be worthy of trust
if we made it the default.)


That's correct. But Fedora has tested and used the DLV, and it seems
very solid, though we are looking at one bootstrap issue with VPN we
have observed, where bind could not fetch the DLV's DNSKEY to validate.

But people who are waiting for DNSSEC to "get turned on" are denialists.

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