Re: UAE punycode in zone

[Chris Hills]

On 09/05/2010 19:31, Warren Kumari wrote:
> I am *so* not an IDN person (although I did follow the IDNA WG for a
> while), but I *believe* that the process is just to convert the native
> UTF8 representation (تامايدوجان.سى) to punycode 
> (xn--mgbaajmr6mmaps.xn--ygb8b). There are a bunch of tools that will do
> this for you, I suspect that just using something like:
> http://mct.verisign-grs.com/conversiontool/convertServlet?input=تامايدوجان.سى&type=UTF8
> is easiest.
> 
> Now that you have the punycode representation, you just treat it like
> any other domain (create a zone file called
> xn--mgbaajmr6mmaps.xn--ygb8b, set $ORIGIN xn--mgbaajmr6mmaps.xn--ygb8b.,
> etc).

I sent a requests to isc for a new option in dig, enabled by default:-

+[no]idn
   automatically convert input to IDN

So entering:-

dig تامايدوجان.سى

would give you the result as if you had entered:-

dig xn--mgbaajmr6mmaps.xn--ygb8b

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

IPv6 reverse zones advise

[a . smith]

Hi,

  we will shortly start using IPv6 reverse DNS, and having never used  
it before I thought Id ask those with some experience if they have any  
words of wisdom before I make any horrible mistakes ;) Ive already had  
a good read of a good many sites on the subject but still would like  
to check a couple of things.
When creating IPv6 reverse zones can the subnet be as large or small  
as you like? Ive seen examples using /48 and /64, can this be  
effectively whatever you want?
And following on from that if it is user definable, what would be the  
recommended way (size) forward? We are using flat file zone files. To  
me the simplest would seem to create the zones using large subnets and  
where necessary (as occasionally we are asked to do) delegate via the  
zone file some ranges to other DNS servers.
Im not an expert in all of this really, but we get by on IPv4 so if  
anyone has any tips they would be greatfully recieved,


thanks Andy.



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

Allowing recursion for just specific zones

[Brian Candler]

Hello,

I am trying to configure a bind9 view to allow recursion just for certain
domains. (This is bind-9.2.4-16.EL4 under RHEL4).

In fact, it doesn't even have to be real recursion, just forwarding to an
upstream recursive nameserver.  The point is that the clients are only
authorised to look up names under a handful of domains, and the rest should
be denied.

However, the various attempts I've tried have failed so far. As far as I can
tell:

1. "recursion no" can only be set at the top (view) level, not overridden
   at the zone level.

2. If I set "recursion no" at the view level, then a "type forward"
   zone has no effect:

  view "foo" {
recursion no;
...
zone "example.com" {
  type forward;
  forward only;
  forwarders {192.0.2.1;};
};

-- query for foo.example.com returns only referral to root servers
   (i.e. it is not forwarded)

3. If I make the view authoritative for the root zone, then a "type forward"
   zone also has no effect:

  view "foo" {
recursion yes;
...
zone "." {
  type master;
  file "named.zero";   // just SOA
  allow-update {none;};
};
zone "example.com" {
  type forward;
  forward only;
  forwarders {192.0.2.1;};
};

-- query for foo.example.com gives NXDOMAIN and the root SOA

4. Setting forwarders to an empty list at the top level doesn't prevent
forwarding, it just falls back to normal recursive lookup instead.

  view "foo" {
recursion yes;
forward only;
forwarders {};
..
zone "example.com" {
  type forward;
  forward only;
  forwarders {192.0.2.1;};
};

-- queries for bar.example.com are forwarded as expected
-- queries for baz.anythingelse.com are looked up recursively, which
   is what I'm trying to prevent :-(

5. I don't have AXFR access to the upstream zones, so making the server
a slave for these zones is not an option.

At the moment the best I can do is to forward to a non-existent IP in the
top level, which makes unauthorised queries time out - clearly not ideal.

Anyone have any better suggestions?

Many thanks,

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

Re: IPv6 reverse zones advise

[Matthew Seaman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/2010 12:44:32, a.sm...@ukgrid.net wrote:

>   we will shortly start using IPv6 reverse DNS, and having never used it
> before I thought Id ask those with some experience if they have any
> words of wisdom before I make any horrible mistakes ;) Ive already had a
> good read of a good many sites on the subject but still would like to
> check a couple of things.
> When creating IPv6 reverse zones can the subnet be as large or small as
> you like? Ive seen examples using /48 and /64, can this be effectively
> whatever you want?
> And following on from that if it is user definable, what would be the
> recommended way (size) forward? We are using flat file zone files. To me
> the simplest would seem to create the zones using large subnets and
> where necessary (as occasionally we are asked to do) delegate via the
> zone file some ranges to other DNS servers.
> Im not an expert in all of this really, but we get by on IPv4 so if
> anyone has any tips they would be greatfully recieved,
> 
> thanks Andy.

For an example IPv6 address -- say: 2001:8b0:151:1:240:5ff:fea5:8db7
the PTR record would be:

7.b.d.8.5.a.e.f.f.f.5.0.0.4.2.0.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa. IN
PTR

So zero fill each of the colon separated fields to 4 digits, reverse and
split into individual hex digits.  Now *each* hex digit in the address
is a label in the DNS, and you can delegate chunks of the address space
at any label (exactly as you can for forward zones).

This means that the smallest chunk of IP space you can delegate is 16
addresses, which is minuscule on the IPv6 scale of things.  The largest
chunk you could manage from a sigle zone file would be your whole
allocation.  That will likely be a /32, /48 or /64 depending on your ISP
and whether you're dealing directly with RIPE or not.  Assuming a /64
and that you want to keep everything in just one zone file, it would
look something like this:

% less 1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa
;
; @(#) $Id: 1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa 672 2010-04-13
08:32:21Z matthew $
;
; MJS 20031213: Reverse mappings for 2001:8b0:151:1/64 addresses
;

$TTL3600

@   IN  SOA ns0.infracaninophile.co.uk.
hostmaster.infracaninophile.co.uk. (
2008071000  ; Serial
10800   ; Refresh (3H)
3600; Retry   (1H)
604800  ; Expire  (1W)
43200 ) ; Minimum (12H)
NS  secondary-ns.co.uk.
NS  secondary-dns.co.uk.
;
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR net6.infracaninophile.co.uk.
;
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 PTR gate6.infracaninophile.co.uk.
7.b.d.8.5.a.e.f.f.f.5.0.0.4.2.0 PTR
happy-idiot-talk.infracaninophile.co.uk.
[...etc...]

If you're using rtadv/rtsol, especially if you're combining that with
dynamic DNS, then having a zone for each /64 prefix you advertise would
make sense.

Cheers,

Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
  Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvoAMMACgkQ8Mjk52CukIzQ0ACcCyjiogNgoUu3+dBB3cELY86c
U4wAnRSqfR19RJ19d1bROnVVFFA63onk
=57I9
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Master server offline

[Sam Wilson]

In article ,
 Bruce Ray  wrote:

> You have until the expiry counter expires for a given zone.
> 
> We typically run our expiries at a week to allow for this type of failure.

Make them 10 days - that way you can break things on a Friday, have a 
week off and then fix them again on the Monday morning you come back.

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

KAMINSKY vulnerability !!

[P.A]

Hi, list.

 

Today I came in and both my name server stopped answering queries. I
restarted the servers a couple of times and they are now up. I have posted
the primary/slave look below. My question is did I just get rid by the
kaminsky vulnerability? if so how can I determined what host caused this if
its possible. The last thing what version should I upgrade to?

 

Thanks, Paul.

 

Primary server: BIND 9.4.3b2

 

May 10 08:37:06 ns1 named[4388]: client 69.7.14.195#12898: RFC 1918 response
from Internet for 22.98.168.192.in-addr.arpa

May 10 08:37:09 ns1 named[4388]: client 69.7.14.195#12899: RFC 1918 response
from Internet for 22.98.168.192.in-addr.arpa

May 10 08:37:11 ns1 named[4388]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 08:37:11 ns1 named[4388]: exiting (due to assertion failure)

 

May 10 09:22:12 ns1 named[5020]: client 76.119.98.131#3941: updating zone
'x.com/IN': update unsuccessful: MATTLAPTOP.quakerfabric.com/A: 'RRset
exists (value dependent)' prerequisite not satisfied (NXRRSET)

May 10 09:22:12 ns1 named[5020]: client 76.119.98.131#3944: update
'x.com/IN' denied

May 10 09:22:15 ns1 named[5020]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 09:22:15 ns1 named[5020]: exiting (due to assertion failure)

 

 

Secondary server: BIND 9.4.3b2

 

May 10 08:37:06 ns1 named[11422]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 08:37:06 ns1 named[11422]: exiting (due to assertion failure)

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

Re: IPv6 reverse zones advise

[Sam Wilson]

In article ,
 Matthew Seaman  wrote:

> This means that the smallest chunk of IP space you can delegate is 16
> addresses, ...

Nitpick: The smallest chunk of IPv6 space you can delegate is a single 
address, as you can for IPv4.  You could also do RFC 2317 style 
delegations to delegate chunks of other sizes, though you might argue 
that that's a specially extended case of delegating single addresses 
(all those CNAME records!).

Given the standard address granularity in IPv6 (/64 is mandated for 
almost all the address space, though there is pressure to allow /126 or 
/127 for point to point links) there probably aren't many cases were 
you'd want to delegate any further than at the /64 boundary.

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

RE: KAMINSKY vulnerability !!

[P.A]

I think I see what the issue is,

 

http://www.kb.cert.org/vuls/id/725188

 

I was asking about kaminsky because I wasn't sure if I had previously
upgraded to fix that fix, which seems like I had and the problem is
something different. 

 

From: P.A [mailto:ra...@meganet.net] 
Sent: Monday, May 10, 2010 10:06 AM
To: 'bind-users@lists.isc.org'
Subject: KAMINSKY vulnerability !!

 

Hi, list.

 

Today I came in and both my name server stopped answering queries. I
restarted the servers a couple of times and they are now up. I have posted
the primary/slave look below. My question is did I just get rid by the
kaminsky vulnerability? if so how can I determined what host caused this if
its possible. The last thing what version should I upgrade to?

 

Thanks, Paul.

 

Primary server: BIND 9.4.3b2

 

May 10 08:37:06 ns1 named[4388]: client 69.7.14.195#12898: RFC 1918 response
from Internet for 22.98.168.192.in-addr.arpa

May 10 08:37:09 ns1 named[4388]: client 69.7.14.195#12899: RFC 1918 response
from Internet for 22.98.168.192.in-addr.arpa

May 10 08:37:11 ns1 named[4388]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 08:37:11 ns1 named[4388]: exiting (due to assertion failure)

 

May 10 09:22:12 ns1 named[5020]: client 76.119.98.131#3941: updating zone
'x.com/IN': update unsuccessful: MATTLAPTOP.quakerfabric.com/A: 'RRset
exists (value dependent)' prerequisite not satisfied (NXRRSET)

May 10 09:22:12 ns1 named[5020]: client 76.119.98.131#3944: update
'x.com/IN' denied

May 10 09:22:15 ns1 named[5020]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 09:22:15 ns1 named[5020]: exiting (due to assertion failure)

 

 

Secondary server: BIND 9.4.3b2

 

May 10 08:37:06 ns1 named[11422]: resolver.c:5494: REQUIREquery) !=
((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
('!') << 16 | ('!') << 8 | ('!')) failed

May 10 08:37:06 ns1 named[11422]: exiting (due to assertion failure)

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

Re: KAMINSKY vulnerability !!

[Stephane Bortzmeyer]

On Mon, May 10, 2010 at 10:19:33AM -0400,
 P.A  wrote 
 a message of 314 lines which said:

> I think I see what the issue is,

No. Completely unrelated. 

> http://www.kb.cert.org/vuls/id/725188

In that case, the error was:

Jul 29 09:10:57 lilith named[2428]: db.c:619: \
   REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 29 09:10:57 lilith named[2428]: exiting (due to assertion failure)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KAMINSKY vulnerability !!

[Stephane Bortzmeyer]

On Mon, May 10, 2010 at 10:05:47AM -0400,
 P.A  wrote 
 a message of 242 lines which said:

> My question is did I just get rid by the kaminsky vulnerability?

Not at all. The Kaminsky attack poisons the server, it does not crash
it.

> Primary server: BIND 9.4.3b2

Why do you run a beta version (and an old one)?

This issue is known
 and has
been fixed in production versions a long time ago.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KAMINSKY vulnerability !!

[Alan Clegg]

On 5/10/2010 10:19 AM, P.A wrote:

> Primary server: BIND 9.4.3b2

Continue your upgrade process to a version of BIND that is supported. :)

http://www.isc.org/software/bind/versions

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: KAMINSKY vulnerability !!

[P.A]

Stephane, do you think I can get away with running 9.4.3-P5 that doesn't
seem to have any known issues. Also what exploit do you think caused my
original issue?

As far as running an old version its been stable for a long time and to be
honest I forgot I was running that version.


-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] 
Sent: Monday, May 10, 2010 10:24 AM
To: P.A
Cc: bind-users@lists.isc.org
Subject: Re: KAMINSKY vulnerability !!

On Mon, May 10, 2010 at 10:05:47AM -0400,
 P.A  wrote 
 a message of 242 lines which said:

> My question is did I just get rid by the kaminsky vulnerability?

Not at all. The Kaminsky attack poisons the server, it does not crash
it.

> Primary server: BIND 9.4.3b2

Why do you run a beta version (and an old one)?

This issue is known
 and has
been fixed in production versions a long time ago.

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

Splitting off a sub-zone "atomically"

[Phil Mayers]

We're doing some DNSSEC testing with sub-zones of our main zone, and I 
had a little accident largely due to my own incompetence today where I 
basically did this:


1. Existing zone "example.com"; create new zone "sub.example.com"

2. Run a SQL->DNS update; *.sub.example.com RRs are removed from 
"example.com", and added to "sub.example.com"


3. Slaves immediately get the NOTIFY for "example.com" and remove the 
records via IXFR, but aren't yet configured for "sub.example.com" (cron 
job hasn't yet run)


4. Some time later, the cron job runs


Obviously between 3 & 4 we weren't resolving "sub.example.com" on the 
slaves. Tedious.



This got me thinking. When I have this:

zone "example.com" {
  type slave;
  master 192.168.1.1;
  file "zones/example.com";
};

...and I then append this:

zone "sub.example.com" {
  ...
};

...and issue an "rndc reload", does bind NXDOMAIN any queries for 
"sub.example.com" between the "reload" and the AXFR finishing? Or does 
it wait until the zone is fully downloaded before inserting it into the 
internal lookup "tree" (or whatever)?


Obviously I can change my procedures to do:

 1. Create zone on master
 2. For each slave:
a. axfr file from master
b. add zone into /etc/named.conf
c. rndc reload
 3. On master, remove *.sub.example.com RRs from example.com

...but I was just curious.

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

Re: KAMINSKY vulnerability !!

[Kevin Darcy]

A) Why do you assume an exploit at all? Hopefully you understand that 
the vast majority of software crashes in the world are triggered by 
benign transactions.


B) From the www.isc.org website:

"BIND 9.4-ESV-R1 is now available. BIND 9.4-ESV-R1 is revision 1 of the 
extended release version for BIND 9.4. It is recommended that all BIND 
9.4.x users upgrade to BIND 9.4-ESV-R1."


If you have to upgrade anyway, but you're going to stick with 9.4.x, why 
would you try to "get away with" running something older and 
less-recommended in that generation of BIND 9 than 9.4-ESV-R1?



- Kevin



On 5/10/2010 10:58 AM, P.A wrote:

Stephane, do you think I can get away with running 9.4.3-P5 that doesn't
seem to have any known issues. Also what exploit do you think caused my
original issue?

As far as running an old version its been stable for a long time and to be
honest I forgot I was running that version.


-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
Sent: Monday, May 10, 2010 10:24 AM
To: P.A
Cc: bind-users@lists.isc.org
Subject: Re: KAMINSKY vulnerability !!

On Mon, May 10, 2010 at 10:05:47AM -0400,
  P.A  wrote
  a message of 242 lines which said:

   

My question is did I just get rid by the kaminsky vulnerability?
 

Not at all. The Kaminsky attack poisons the server, it does not crash
it.

   

Primary server: BIND 9.4.3b2
 

Why do you run a beta version (and an old one)?

This issue is known
  and has
been fixed in production versions a long time ago.

___
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: KAMINSKY vulnerability !!

[P.A]

Kevin,

At 1st I assumed an exploit after looking at the version of bind I was
using, which was a beta, I noticed that there was some talk of the beta
version crashing and the solution was to go to P1. Looking back on it I did
an emergency upgrade to the beta because of the kaminsky problem. Since both
our name server are chrooted and have never gave us any issues I slowly
forgot about the fact that I was using the beta version. Remember not until
today has the version giving me any issues.

As far as getting away with the version, I looked at the ISC site and
noticed that BIND 9.4.3-P5 doesn't seem to have an known issues. Since I'm
running BIND on an older server, centos 4.8 with one gig of ram, I decided
to compile 9.4.3-P5 instead of the newer version because some of my libs/etc
might be older and therefore not supported by the latest release. I need to
get these name servers up and running and being stable fast.


-Original Message-
From: bind-users-bounces+pamaral=meganet@lists.isc.org
[mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of
Kevin Darcy
Sent: Monday, May 10, 2010 12:25 PM
To: bind-users@lists.isc.org
Subject: Re: KAMINSKY vulnerability !!

A) Why do you assume an exploit at all? Hopefully you understand that 
the vast majority of software crashes in the world are triggered by 
benign transactions.

B) From the www.isc.org website:

"BIND 9.4-ESV-R1 is now available. BIND 9.4-ESV-R1 is revision 1 of the 
extended release version for BIND 9.4. It is recommended that all BIND 
9.4.x users upgrade to BIND 9.4-ESV-R1."

If you have to upgrade anyway, but you're going to stick with 9.4.x, why 
would you try to "get away with" running something older and 
less-recommended in that generation of BIND 9 than 9.4-ESV-R1?

 
 - Kevin


On 5/10/2010 10:58 AM, P.A wrote:
> Stephane, do you think I can get away with running 9.4.3-P5 that doesn't
> seem to have any known issues. Also what exploit do you think caused my
> original issue?
>
> As far as running an old version its been stable for a long time and to be
> honest I forgot I was running that version.
>
>
> -Original Message-
> From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr]
> Sent: Monday, May 10, 2010 10:24 AM
> To: P.A
> Cc: bind-users@lists.isc.org
> Subject: Re: KAMINSKY vulnerability !!
>
> On Mon, May 10, 2010 at 10:05:47AM -0400,
>   P.A  wrote
>   a message of 242 lines which said:
>
>
>> My question is did I just get rid by the kaminsky vulnerability?
>>  
> Not at all. The Kaminsky attack poisons the server, it does not crash
> it.
>
>
>> Primary server: BIND 9.4.3b2
>>  
> Why do you run a beta version (and an old one)?
>
> This issue is known
>   and has
> been fixed in production versions a long time ago.
>
> ___
> 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

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

ignoring out-of-zone data (254.88.8.207.in-addr.arpa)

[Jason Davis]

Hello,
 I have setup some rdns with bind, when i try to start I get this error:

/etc/zones/master/reverses/88.8.207.in-addr.arpa:257: ignoring
out-of-zone data (254.88.8.207.in-addr.arpa)

I get it for each host in the reverse zone file. ANy idea whay Im doing wrong?

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

Re: ignoring out-of-zone data (254.88.8.207.in-addr.arpa)

[Jason Davis]

Thanks guys, the issue was i just needed to put the last octect in the
zone file.

Thanks,
Jason

On Mon, May 10, 2010 at 12:20 PM, Chris Buxton  wrote:
> Your zone definition in named.conf must have a different name than
> what you expect. Check it for typos.
>
> Chris Buxton
> BlueCat Networks
>
> On 5/10/10, Jason Davis  wrote:
>> Hello,
>>  I have setup some rdns with bind, when i try to start I get this error:
>>
>> /etc/zones/master/reverses/88.8.207.in-addr.arpa:257: ignoring
>> out-of-zone data (254.88.8.207.in-addr.arpa)
>>
>> I get it for each host in the reverse zone file. ANy idea whay Im doing
>> wrong?
>>
>> Thanks,
>> Jason
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
> --
> Sent from my mobile device
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ignoring out-of-zone data (254.88.8.207.in-addr.arpa)

[Chris Buxton]

Your zone definition in named.conf must have a different name than
what you expect. Check it for typos.

Chris Buxton
BlueCat Networks

On 5/10/10, Jason Davis  wrote:
> Hello,
>  I have setup some rdns with bind, when i try to start I get this error:
>
> /etc/zones/master/reverses/88.8.207.in-addr.arpa:257: ignoring
> out-of-zone data (254.88.8.207.in-addr.arpa)
>
> I get it for each host in the reverse zone file. ANy idea whay Im doing
> wrong?
>
> Thanks,
> Jason
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

-- 
Sent from my mobile device
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KAMINSKY vulnerability !!

[JINMEI Tatuya / 神明達哉]

At Mon, 10 May 2010 10:05:47 -0400,
"P.A"  wrote:

> Today I came in and both my name server stopped answering queries. I
> restarted the servers a couple of times and they are now up. I have posted
> the primary/slave look below. My question is did I just get rid by the
> kaminsky vulnerability? if so how can I determined what host caused this if
> its possible. The last thing what version should I upgrade to?

[...]

> May 10 08:37:11 ns1 named[4388]: resolver.c:5494: REQUIREquery) !=
> ((void *)0)) && (((const isc__magic_t *)(query))->magic == ((('Q') << 24 |
> ('!') << 16 | ('!') << 8 | ('!')) failed

I suspect you hit an old bug:

2408.   [bug]   A duplicate TCP dispatch event could be sent, which
could then trigger an assertion failure in
resquery_response().  [RT #18275]

which was fixed in 9.4.3.

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

Re: Allowing recursion for just specific zones

[Chris Buxton]

Recursion is enabled/allowed at the view level, not the zone level.

One strategy would be to set up a view that matches recursive queries
only. Set allow-query to none at the view, then set it any (or
whatever) in each zone of type forward or stub.

Or if you want to use your root zone idea, make sure to populate it
with delegations to the domains that should resolve.

I'm not sure if the match-recursive statement existed in 9.2. You may
need to upgrade to something current.

Chris Buxton
BlueCat Networks

On 5/10/10, Brian Candler  wrote:
> Hello,
>
> I am trying to configure a bind9 view to allow recursion just for certain
> domains. (This is bind-9.2.4-16.EL4 under RHEL4).
>
> In fact, it doesn't even have to be real recursion, just forwarding to an
> upstream recursive nameserver.  The point is that the clients are only
> authorised to look up names under a handful of domains, and the rest should
> be denied.
>
> However, the various attempts I've tried have failed so far. As far as I can
> tell:
>
> 1. "recursion no" can only be set at the top (view) level, not overridden
>at the zone level.
>
> 2. If I set "recursion no" at the view level, then a "type forward"
>zone has no effect:
>
>   view "foo" {
> recursion no;
> ...
> zone "example.com" {
>   type forward;
>   forward only;
>   forwarders {192.0.2.1;};
> };
>
> -- query for foo.example.com returns only referral to root servers
>(i.e. it is not forwarded)
>
> 3. If I make the view authoritative for the root zone, then a "type forward"
>zone also has no effect:
>
>   view "foo" {
> recursion yes;
> ...
> zone "." {
>   type master;
>   file "named.zero";   // just SOA
>   allow-update {none;};
> };
> zone "example.com" {
>   type forward;
>   forward only;
>   forwarders {192.0.2.1;};
> };
>
> -- query for foo.example.com gives NXDOMAIN and the root SOA
>
> 4. Setting forwarders to an empty list at the top level doesn't prevent
> forwarding, it just falls back to normal recursive lookup instead.
>
>   view "foo" {
> recursion yes;
> forward only;
> forwarders {};
> ..
> zone "example.com" {
>   type forward;
>   forward only;
>   forwarders {192.0.2.1;};
> };
>
> -- queries for bar.example.com are forwarded as expected
> -- queries for baz.anythingelse.com are looked up recursively, which
>is what I'm trying to prevent :-(
>
> 5. I don't have AXFR access to the upstream zones, so making the server
> a slave for these zones is not an option.
>
> At the moment the best I can do is to forward to a non-existent IP in the
> top level, which makes unauthorised queries time out - clearly not ideal.
>
> Anyone have any better suggestions?
>
> Many thanks,
>
> Brian.
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

-- 
Sent from my mobile device
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: KAMINSKY vulnerability !!

[Paul Amaral]

Thanks to Tatuya Jinmei.

2408.   [bug]   A duplicate TCP dispatch event could be sent, which
could then trigger an assertion failure in
resquery_response().  [RT #18275]


-Original Message-
From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] 
Sent: Monday, May 10, 2010 10:25 AM
To: P.A
Cc: bind-users@lists.isc.org
Subject: Re: KAMINSKY vulnerability !!

On Mon, May 10, 2010 at 10:19:33AM -0400,
 P.A  wrote 
 a message of 314 lines which said:

> I think I see what the issue is,

No. Completely unrelated. 

> http://www.kb.cert.org/vuls/id/725188

In that case, the error was:

Jul 29 09:10:57 lilith named[2428]: db.c:619: \
   REQUIRE(type != ((dns_rdatatype_t)dns_rdatatype_any)) failed
Jul 29 09:10:57 lilith named[2428]: exiting (due to assertion failure)

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

named-checkzone behavior change?

[Jack Tavares]

I have downloaded 9.7.0-P1 and I am running into something odd with 
named-checkzone
I have a simple zone with an NS record that has no A or  record.

named-checkzone has flags to ignore this. and this same command (see below) 
worked in 9.6

but given this zone file
test.net. 500 IN SOA d88.test.net. hostmaster.d88.test.net. 2010051001 10800 
3600 604800 86400
test.net. 500 IN NS d88.test.net.

named-checkconf -k ignore -n ignore -i none test.net. 
gives

zone test.net/IN: NS 'd88.test.net' has no address records (A or )
zone test.net/IN: not loaded due to errors.

Is this a bug? or do I have a flag missing or incorrect?



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

RE: named-checkzone behavior change?

[Jack Tavares]

Correction:

I am calling named-checkzone not checkconf.
this:
named-checkconf -k ignore -n ignore -i none test.net. 

should read
named-checkzone -k ignore -n ignore -i none test.net. 

the rest of the email is correct

From: Jack Tavares
Sent: Monday, May 10, 2010 12:49 PM
To: bind-users@lists.isc.org
Subject: named-checkzone behavior change?

I have downloaded 9.7.0-P1 and I am running into something odd with 
named-checkzone
I have a simple zone with an NS record that has no A or  record.

named-checkzone has flags to ignore this. and this same command (see below) 
worked in 9.6

but given this zone file
test.net. 500 IN SOA d88.test.net. hostmaster.d88.test.net. 2010051001 10800 
3600 604800 86400
test.net. 500 IN NS d88.test.net.

gives

zone test.net/IN: NS 'd88.test.net' has no address records (A or )
zone test.net/IN: not loaded due to errors.

Is this a bug? or do I have a flag missing or incorrect?



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

RE: named-checkzone behavior change?

[Jack Tavares]

I see this was intentional.
2800. [func]Reject zones which have NS records which 
refer to
CNAMEs, DNAMEs or don't have 
address record (class IN
only).  Reject UPDATEs which 
would cause the zone
to fail the above checks if 
committed. [RT #20678]

From: Jack Tavares
Sent: Monday, May 10, 2010 12:54 PM
To: Jack Tavares; bind-users@lists.isc.org
Subject: RE: named-checkzone behavior change?

Correction:

I am calling named-checkzone not checkconf.
this:
named-checkconf -k ignore -n ignore -i none test.net. 

should read
named-checkzone -k ignore -n ignore -i none test.net. 

the rest of the email is correct

From: Jack Tavares
Sent: Monday, May 10, 2010 12:49 PM
To: bind-users@lists.isc.org
Subject: named-checkzone behavior change?

I have downloaded 9.7.0-P1 and I am running into something odd with 
named-checkzone
I have a simple zone with an NS record that has no A or  record.

named-checkzone has flags to ignore this. and this same command (see below) 
worked in 9.6

but given this zone file
test.net. 500 IN SOA d88.test.net. hostmaster.d88.test.net. 2010051001 10800 
3600 604800 86400
test.net. 500 IN NS d88.test.net.

gives

zone test.net/IN: NS 'd88.test.net' has no address records (A or )
zone test.net/IN: not loaded due to errors.

Is this a bug? or do I have a flag missing or incorrect?



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

Re: UAE punycode in zone

[Michelle Konzack]

Hello Chris Hills,

Am 2010-05-10 09:02:35, hacktest Du folgendes herunter:
> I sent a requests to isc for a new option in dig, enabled by default:-
> 
> +[no]idn
>automatically convert input to IDN
> 
> So entering:-
> 
> digتامايدوجان.سى
> 
> would give you the result as if you had entered:-
> 
> dig xn--mgbaajmr6mmaps.xn--ygb8b

Are you sure, you can enter arabic domainnames nt he console?  :-D

I can not even copy/past it.

However it would be very usefull if "dig" could outpout the inverse too,
I mean if I use "dig -x a.b.c.d" and Dig woud not onle respond with  the
"xn--mgbaajmr6mmaps.xn--ygb8b" but also in a second line the  translated
domainname.  Somehing like

[command 'dig +idn -x 192.168.0.200' ]--

; <<>> DiG 9.5.1-P3 <<>> -x 192.168.0.200
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34023
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;200.0.168.192.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
200.0.168.192.in-addr.arpa. 38400 INPTR xn--mgbaajmr6mmaps.xn--ygb8b.
200.0.168.192.in-addr.arpa. 38400 INIDN تامايدوجان.سى.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa. 38400   IN  NS  dns.private.tamay-dogan.net.

;; ADDITIONAL SECTION:
dns.private.tamay-dogan.net. 300 IN A   192.168.0.74

;; Query time: 1 msec
;; SERVER: 192.168.0.74#53(192.168.0.74)
;; WHEN: Tue May 11 00:45:30 2010
;; MSG SIZE  rcvd: 121



Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsyst...@tdnet France   itsyst...@tdnet UG (haftungsbeschränkt)
Gesch. Michelle Konzack  Gesch. Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz   Kinzigstraße 17
67100 Strasbourg/France 77694 Kehl/Germany
Tel: +33-6-61925193 mobil   Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


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

Re: IPv6 reverse zones advise

[Mark Andrews]

In message <20100510124432.19374b1xzk3ab...@webmail2.ukgrid.net>, a.sm...@ukgri
d.net writes:
> Hi,
> 
>we will shortly start using IPv6 reverse DNS, and having never used  
> it before I thought Id ask those with some experience if they have any  
> words of wisdom before I make any horrible mistakes ;) Ive already had  
> a good read of a good many sites on the subject but still would like  
> to check a couple of things.
> When creating IPv6 reverse zones can the subnet be as large or small  
> as you like? Ive seen examples using /48 and /64, can this be  
> effectively whatever you want?
> And following on from that if it is user definable, what would be the  
> recommended way (size) forward? We are using flat file zone files. To  
> me the simplest would seem to create the zones using large subnets and  
> where necessary (as occasionally we are asked to do) delegate via the  
> zone file some ranges to other DNS servers.
> Im not an expert in all of this really, but we get by on IPv4 so if  
> anyone has any tips they would be greatfully recieved,
> 
> thanks Andy.

The answer to that lies in who (or what) is doing the updating.
This is a administative issue not a technical one.

For home being allocated a /56 I would not subdivide it.

For companies with different division on different subnets I would
subdivide the /48.  Also company zones tend to have more records
in them.

Whatever you do I would be consistent.  If you need to split out a
/64 for one subnet I would do it for all subnets even though it
means a little more work initially.

In my previous job I had a /16 (IPv4) and it was further sub divided
into /20's (one for each division in the state).  I delegate all
16 reverse zones at that point.  For IPv6 that would be a /48 and
delegating /52 which could be further sub delegated if needed at
the /64 boundary.  Note there would be a single delagation for the
/52 as it is at a nibble break point.

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: Splitting off a sub-zone "atomically"

[Mark Andrews]

In message <4be82427.5060...@imperial.ac.uk>, Phil Mayers writes:
> We're doing some DNSSEC testing with sub-zones of our main zone, and I 
> had a little accident largely due to my own incompetence today where I 
> basically did this:
> 
> 1. Existing zone "example.com"; create new zone "sub.example.com"
> 
> 2. Run a SQL->DNS update; *.sub.example.com RRs are removed from 
> "example.com", and added to "sub.example.com"
> 
> 3. Slaves immediately get the NOTIFY for "example.com" and remove the 
> records via IXFR, but aren't yet configured for "sub.example.com" (cron 
> job hasn't yet run)
> 
> 4. Some time later, the cron job runs
> 
> 
> Obviously between 3 & 4 we weren't resolving "sub.example.com" on the 
> slaves. Tedious.
> 
> 
> This got me thinking. When I have this:
> 
> zone "example.com" {
>type slave;
>master 192.168.1.1;
>file "zones/example.com";
> };
> 
> ...and I then append this:
> 
> zone "sub.example.com" {
>...
> };
> 
> ...and issue an "rndc reload", does bind NXDOMAIN any queries for 
> "sub.example.com" between the "reload" and the AXFR finishing? Or does 
> it wait until the zone is fully downloaded before inserting it into the 
> internal lookup "tree" (or whatever)?

It SERVFAILs the query as it doesn't have the data to respond to
it.  Iterative resolvers should move onto the next server on SERVFAIL.

> Obviously I can change my procedures to do:
> 
>   1. Create zone on master
>   2. For each slave:
>  a. axfr file from master
>  b. add zone into /etc/named.conf
>  c. rndc reload
>   3. On master, remove *.sub.example.com RRs from example.com
> 
> ...but I was just curious.
> 
> ___
> 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: UAE punycode in zone

[Warren Kumari]

On May 10, 2010, at 6:48 PM, Michelle Konzack wrote:


Hello Chris Hills,

Am 2010-05-10 09:02:35, hacktest Du folgendes herunter:
I sent a requests to isc for a new option in dig, enabled by  
default:-


+[no]idn
  automatically convert input to IDN

So entering:-

digتامايدوجان.سى

would give you the result as if you had entered:-

dig xn--mgbaajmr6mmaps.xn--ygb8b


Are you sure, you can enter arabic domainnames nt he console?  :-D

I can not even copy/past it.

However it would be very usefull if "dig" could outpout the inverse  
too,
I mean if I use "dig -x a.b.c.d" and Dig woud not onle respond with   
the
"xn--mgbaajmr6mmaps.xn--ygb8b" but also in a second line the   
translated

domainname.  Somehing like


I think that part of the issue with that is that the console might get  
very grumpy if it is not UTF8 clean -- if your console only speaks  
ASCII (like VT100/102) and you try to output UTF8, it barfs horribly.  
I guess that dig could try and work out if things are safe, but that  
seems fraught with peril and platform specific nonsense...


W




[command 'dig +idn -x  
192.168.0.200' ]--


; <<>> DiG 9.5.1-P3 <<>> -x 192.168.0.200
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34023
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,  
ADDITIONAL: 1


;; QUESTION SECTION:
;200.0.168.192.in-addr.arpa.IN  PTR

;; ANSWER SECTION:
200.0.168.192.in-addr.arpa. 38400 INPTR xn--mgbaajmr6mmaps.xn--ygb8b.
200.0.168.192.in-addr.arpa. 38400 INIDN تامايدوجان.سى.

;; AUTHORITY SECTION:
0.168.192.in-addr.arpa. 38400   IN  NS  dns.private.tamay-dogan.net.

;; ADDITIONAL SECTION:
dns.private.tamay-dogan.net. 300 IN A   192.168.0.74

;; Query time: 1 msec
;; SERVER: 192.168.0.74#53(192.168.0.74)
;; WHEN: Tue May 11 00:45:30 2010
;; MSG SIZE  rcvd: 121



Thanks, Greetings and nice Day/Evening
   Michelle Konzack
   Systemadministrator

--
# Debian GNU/Linux Consultant  
##

  Development of Intranet and Embedded Systems with Debian GNU/Linux

itsyst...@tdnet France   itsyst...@tdnet UG  
(haftungsbeschränkt)

Gesch. Michelle Konzack  Gesch. Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz   Kinzigstraße 17
67100 Strasbourg/France 77694 Kehl/Germany
Tel: +33-6-61925193 mobil   Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 


Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/
___
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: ignoring out-of-zone data (254.88.8.207.in-addr.arpa)

[Barry Margolin]

In article ,
 Jason Davis  wrote:

> Thanks guys, the issue was i just needed to put the last octect in the
> zone file.

That doesn't sound right. As long as the suffix matched the zone name, 
it shouldn't have caused the error you got.

254 IN PTR 

is equivalent to

254.88.8.207.in-addr.arpa. IN PTR 

if the zone name is 88.8.207.in-addr.arpa.

The more common mistake is to forget the trailing ".", but then it would 
be treated as

254.88.8.207.in-addr.arpa.88.8.207.in-addr.arpa. IN PTR 

but this still wouldn't cause the error.

> 
> Thanks,
> Jason
> 
> On Mon, May 10, 2010 at 12:20 PM, Chris Buxton  
> wrote:
> > Your zone definition in named.conf must have a different name than
> > what you expect. Check it for typos.
> >
> > Chris Buxton
> > BlueCat Networks
> >
> > On 5/10/10, Jason Davis  wrote:
> >> Hello,
> >>  I have setup some rdns with bind, when i try to start I get this error:
> >>
> >> /etc/zones/master/reverses/88.8.207.in-addr.arpa:257: ignoring
> >> out-of-zone data (254.88.8.207.in-addr.arpa)
> >>
> >> I get it for each host in the reverse zone file. ANy idea whay Im doing
> >> wrong?
> >>
> >> Thanks,
> >> Jason
> >> ___
> >> bind-users mailing list
> >> bind-users@lists.isc.org
> >> https://lists.isc.org/mailman/listinfo/bind-users
> >>
> >
> > --
> > Sent from my mobile device
> >

-- 
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

Behavior of delegation records for dnssec

[rams]

Hi,

I have delegation of NS records in my zone and i signed zone using RSASHA1
algorithm. It is signed successfully. When I checked the the zone i am not
seeing RRSIG for delegated NS records. When I query for delegated NS record
with dnssec, it is returning NS records, NSEC and RRSIG for NSEC and also
glue records returned in additional section with out any RRSIG. Dig results
are given below.

; <<>> DiG 9.6.1-P3 <<>> @localhost srs.net.nu.moon. A +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40245
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;srs.net.nu.moon.   IN  A

;; AUTHORITY SECTION:
srs.net.nu.moon.86400   IN  NS  ns1.dns.net.nu.moon.
srs.net.nu.moon.86400   IN  NS  ns2.dns.net.nu.moon.
srs.net.nu.moon.86400   IN  NS  ns3.dns.net.nu.moon.
srs.net.nu.moon.86400   IN  NSECnet.nu.moon. NS RRSIG NSEC
srs.net.nu.moon.86400   IN  RRSIG   NSEC 5 4 86400
20100521075518 20100421075518 57966 net.nu.moon.
DxLpXxvkOsLVruDKp1K/K7FUPpxlxI/awCOtggM6m6T/d26iGwDJ1wqW
5PTQ6baNCgUTUbiydNEpHmKR7Z1bqQ==

;; ADDITIONAL SECTION:
ns1.dns.net.nu.moon.86400   IN  A   202.46.190.130
ns1.dns.net.nu.moon.86400   IN  2001:dce:2000:2::130
ns2.dns.net.nu.moon.86400   IN  A   202.46.191.130

Why i am not getting RRSIG for NS records and also RRSIG for additional
section records. Is there any configuration required for glue records and
delegated records . Please clarify me on this.

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

Re: Behavior of delegation records for dnssec

[Mark Andrews]

In message , rams
 writes:
> Hi,
> 
> I have delegation of NS records in my zone and i signed zone using RSASHA1
> algorithm. It is signed successfully. When I checked the the zone i am not
> seeing RRSIG for delegated NS records.

There arn't supposed to be any.  The child zone is authoritative
for the NS RRset and signs it.  Similarly glue records are signed
by the zone that owns them not the parent zone.

> When I query for delegated NS record
> with dnssec, it is returning NS records, NSEC and RRSIG for NSEC and also
> glue records returned in additional section with out any RRSIG. Dig results
> are given below.

The NSEC record proves that the delegation exists and that it a
insecure delegation (no DS records).

> ; <<>> DiG 9.6.1-P3 <<>> @localhost srs.net.nu.moon. A +dnssec
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40245
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;srs.net.nu.moon.   IN  A
> 
> ;; AUTHORITY SECTION:
> srs.net.nu.moon.86400   IN  NS  ns1.dns.net.nu.moon.
> srs.net.nu.moon.86400   IN  NS  ns2.dns.net.nu.moon.
> srs.net.nu.moon.86400   IN  NS  ns3.dns.net.nu.moon.
> srs.net.nu.moon.86400   IN  NSECnet.nu.moon. NS RRSIG NSEC
> srs.net.nu.moon.86400   IN  RRSIG   NSEC 5 4 86400
> 20100521075518 20100421075518 57966 net.nu.moon.
> DxLpXxvkOsLVruDKp1K/K7FUPpxlxI/awCOtggM6m6T/d26iGwDJ1wqW
> 5PTQ6baNCgUTUbiydNEpHmKR7Z1bqQ==
> 
> ;; ADDITIONAL SECTION:
> ns1.dns.net.nu.moon.86400   IN  A   202.46.190.130
> ns1.dns.net.nu.moon.86400   IN  2001:dce:2000:2::130
> ns2.dns.net.nu.moon.86400   IN  A   202.46.191.130
> 
> Why i am not getting RRSIG for NS records and also RRSIG for additional
> section records. Is there any configuration required for glue records and
> delegated records . Please clarify me on this.
> 
> Thanks,
> Ramesh
-- 
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