Re: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Chris Thompson]

On Dec 15 2009, Doug Barton wrote:


While this reminder is timely and helpful, more welcome would be the
news that BIND 9.6.2 is going to have actual support for
RSASHA{256|512}. My cursory reading of the 9.6.2b1 code does not seem
to indicate that it does, although I would be happy to be proven wrong.

I personally don't think it's reasonable to expect everyone who wants
to validate with BIND to upgrade to 9.7.x for a variety of reasons
that I'd be happy to elucidate if they are not obvious.


Quoting from https://lists.isc.org/pipermail/bind-users/2009-October/077853.html

(me)

Will you be adding RSASHA256 support in the 9.5.x and 9.6.x series? It
might be a bit optimistic to expect everyone to move to 9.7.x by 2010-07-01,
if that's when the root zone is going to be *really* signed (with RSASHA256,
according to current reports).


(Evan Hunt)

Not 9.5.x, as it lacks NSEC3 support.

Adding SHA-2 to 9.6.x would violate our policy of making major
functional changes only in major releases, so I don't expect we'll
do that.  Given the odd circumstances you mentioned, I won't say for
certain that we won't--but I doubt it.

9.7.0 is going to be final in a little over a month, which is fortunate
timing.


(But it's not too obvious to me that adding support for a new signing
algorithm should necessarily be considered a "major functional change".)

--
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: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Stephane Bortzmeyer]

On Mon, Dec 14, 2009 at 08:05:40PM -0800,
 Doug Barton  wrote 
 a message of 44 lines which said:

> While this reminder is timely and helpful, more welcome would be the
> news that BIND 9.6.2 is going to have actual support for
> RSASHA{256|512}.

No, it won't. Migrating to >= 9.6.1 is necessary to avoid breakage,
not to validate the root.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Delegating in reverse lookup zones

[Simon Dodd]

I'm having a problem configuring a delegation. We have various /24s for
which we provide PTR records. If I create a zone file for
188.134.63.in-addr.arpa and add PTR records, they resolve just fine. In
other words, if this is my zone, I can resolve 63.134.188.13:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
 2009121524; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
   IN  NS  dauth1.joink.com.
   IN  NS  dauth2.joink.com.
13 IN  PTR midwest1st.com.

But that isn't what we want to do for this particular zone. We want to
delegate all queries concerning 188.134.63.in-addr.arpa to
ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says that's
fair game, so here's how I configured the zone:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
 2009121524; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
   IN  NS  ns1.midwestfirst.com.
   IN  NS  ns2.midwestfirst.com.


Mutatis mutandis, that's the configuration that Albitz & Liu show for
delegating forward lookup zones (p. 232). It isn't quite how they show
reverse lookup zones (more on this in a moment), and unfortunately, it
doesn't work:

[r...@linux1 joink-domains]# dig -x 63.134.188.13 +trace

; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options:  printcmd
.   360 IN  NS  B.ROOT-SERVERS.NET.
.   360 IN  NS  M.ROOT-SERVERS.NET.
.   360 IN  NS  K.ROOT-SERVERS.NET.
.   360 IN  NS  E.ROOT-SERVERS.NET.
.   360 IN  NS  L.ROOT-SERVERS.NET.
.   360 IN  NS  A.ROOT-SERVERS.NET.
.   360 IN  NS  J.ROOT-SERVERS.NET.
.   360 IN  NS  G.ROOT-SERVERS.NET.
.   360 IN  NS  C.ROOT-SERVERS.NET.
.   360 IN  NS  F.ROOT-SERVERS.NET.
.   360 IN  NS  H.ROOT-SERVERS.NET.
.   360 IN  NS  I.ROOT-SERVERS.NET.
.   360 IN  NS  D.ROOT-SERVERS.NET.
;; Received 272 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms

63.in-addr.arpa.86400   IN  NS  DILL.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  Y.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  INDIGO.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  Z.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  BASIL.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  HENNA.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  X.ARIN.NET.
;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 76 ms

188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH1.JOINK.COM.
188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH2.JOINK.COM.
;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET) in 75 ms

188.134.63.in-addr.arpa. 3600   IN  SOA dauth1.joink.com.
noc.joink.com.
200
9121525 86400 3600 777600 3600
;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM) in 0 ms

As I said, this isn't quite how Albitz & Liu show delegation for reverse
lookup zones. Nevertheless, the only difference that I see between what I
have configured and what they show is that I'm working with
188.134.63.in-addr.arpa, while they're working one level higher, at the
equivalent of 134.63.in-addr.arpa. Accordingly, they have to specify name
servers for 188 within the zone, whereas I can (I had thought) inhereit that
data from the zone. Maybe not, though, since it isn't working!

I even tried adding the "generate" command that they propose:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
 2009121526; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
IN  NS  ns1.midwestfirst.com.
IN  NS  ns2.midwestfirst.com.
$GENERATE 1-255 IN  NS  ns1.midwestfirst.com.
$GENERATE 1-255 IN  NS  ns2.midwestfirst.com.

But no dice:

; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options:  printcmd
.   360 IN  NS  I.ROOT-SERVERS.NE

Re: Delegating in reverse lookup zones

[Chris Buxton]

It's not a valid delegation unless you control the parent zone.

ARIN is delegating the /24 reverse zone to you. You therefore have four options 
that give control of the PTR records to the midwestfirst.com servers.

Option 1: Ask ARIN to change the delegation. This is the most "correct" option, 
and the easiest.

Option 2: Configure your two servers as slaves of the zone. That is, on 
dauth1.joink.com, change your zone statement from type master to type slave, 
adding a masters statement:

zone "188.134.63.in-addr.arpa." {
type slave;
masters { 65.113.74.3; 65.113.74.4; };
file "188.134.63.in-addr.arpa";
};

Update your zone statement on dauth2 to match (changing the masters line only).

The disadvantage of this approach is that midwestfirst.com's name servers need 
to permit zone transfers to your name servers. Technically, this is a simple 
issue; however, when dealing with customers, it can often be hard to explain.

Option 3: Rename the PTR records into a zone that is controlled by the two 
intended servers. This way, you still have a master zone named 
"188.134.63.in-addr.arpa.", and the contents of that zone look something like 
this:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
 2009121524; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
   IN  NS  dauth1.joink.com.
   IN  NS  dauth2.joink.com.
   IN  DNAME   188.134.63.rev.midwestfirst.com.

Then tell midwestfirst.com that their reverse zone's name is 
"188.134.63.rev.midwestfirst.com.", not "188.134.63.in-addr.arpa.". The 
contents of the zone are otherwise unchanged. (You can also achieve this effect 
with a destination zone named something like "mw.188.134.63.in-addr.arpa.", but 
in that case, you must use a $GENERATE statement instead of a DNAME record.)

The disadvantage of this approach is that you have to convince your customer 
that their zone name is changed from what is normal. This, again, is a simple 
technical issue that can be difficult to get through to a customer.

Option 4: Use your zone as you had written it, with one minor correction:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
 2009121526; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
IN  NS  ns1.midwestfirst.com.
IN  NS  ns2.midwestfirst.com.
$GENERATE 1-254 $   IN  NS  ns1.midwestfirst.com.
$GENERATE 1-254 $   IN  NS  ns2.midwestfirst.com.

Note that I've added a "$" after the range in the $GENERATE statements. The 
disadvantage here is that the customer needs to create separate reverse zones 
for each IP address. If they try to create one large reverse zone containing 
all of these records, named "188.134.63.in-addr.arpa.", bad things will happen 
- it'll work some of the time, but not all of the time, even when the same 
caching server is involved. Inconsistency makes you look bad.

And of course trying to convince a customer to create 254 reverse zones, for 
individual IP's, is not a task I would relish.

Chris Buxton
Professional Services
Men & Mice

On Dec 15, 2009, at 10:52 AM, Simon Dodd wrote:

> I'm having a problem configuring a delegation. We have various /24s for which 
> we provide PTR records. If I create a zone file for 188.134.63.in-addr.arpa 
> and add PTR records, they resolve just fine. In other words, if this is my 
> zone, I can resolve 63.134.188.13:
> 
> $TTL   6h
> @   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
>  2009121524; Serial number
>  86400 ; Refresh
>  3600  ; Retry
>  777600; Expire
>  3600) ; Minimum TTL
>IN  NS  dauth1.joink.com.
>IN  NS  dauth2.joink.com.
> 13 IN  PTR midwest1st.com.
> 
> But that isn't what we want to do for this particular zone. We want to 
> delegate all queries concerning 188.134.63.in-addr.arpa to 
> ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says that's 
> fair game, so here's how I configured the zone:
> 
> $TTL   6h
> @   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
>  2009121524; Serial number
>  86400 ; Refresh
>  3600  ; Retry
>   

Re: Delegating in reverse lookup zones

[Kevin Darcy]

Simon Dodd wrote:
I'm having a problem configuring a delegation. We have various /24s 
for which we provide PTR records. If I create a zone file for 
188.134.63.in-addr.arpa and add PTR records, they resolve just fine. 
In other words, if this is my zone, I can resolve 63.134.188.13 
:


$TTL   6h
@   345600  IN SOA  dauth1.joink.com . 
noc.joink.com . (

 2009121524; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
   IN  NS  dauth1.joink.com .
   IN  NS  dauth2.joink.com .
13 IN  PTR midwest1st.com .

But that isn't what we want to do for this particular zone. We want to 
delegate all queries concerning 188.134.63.in-addr.arpa to 
ns1.midwestfirst.com  and 
ns2.midwestfirst.com . Albitz & Liu 4th 
says that's fair game, so here's how I configured the zone:


$TTL   6h
@   345600  IN SOA  dauth1.joink.com . 
noc.joink.com . (

 2009121524; Serial number
 86400 ; Refresh
 3600  ; Retry
 777600; Expire
 3600) ; Minimum TTL
   IN  NS  ns1.midwestfirst.com 
.
   IN  NS  ns2.midwestfirst.com 
.



Mutatis mutandis, that's the configuration that Albitz & Liu show for 
delegating forward lookup zones (p. 232). It isn't quite how they show 
reverse lookup zones (more on this in a moment), and unfortunately, it 
doesn't work:


[r...@linux1 joink-domains]# dig -x 63.134.188.13 +trace

; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options:  printcmd
.   360 IN  NS  B.ROOT-SERVERS.NET 
.
.   360 IN  NS  M.ROOT-SERVERS.NET 
.
.   360 IN  NS  K.ROOT-SERVERS.NET 
.
.   360 IN  NS  E.ROOT-SERVERS.NET 
.
.   360 IN  NS  L.ROOT-SERVERS.NET 
.
.   360 IN  NS  A.ROOT-SERVERS.NET 
.
.   360 IN  NS  J.ROOT-SERVERS.NET 
.
.   360 IN  NS  G.ROOT-SERVERS.NET 
.
.   360 IN  NS  C.ROOT-SERVERS.NET 
.
.   360 IN  NS  F.ROOT-SERVERS.NET 
.
.   360 IN  NS  H.ROOT-SERVERS.NET 
.
.   360 IN  NS  I.ROOT-SERVERS.NET 
.
.   360 IN  NS  D.ROOT-SERVERS.NET 
.

;; Received 272 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms

63.in-addr.arpa.86400   IN  NS  DILL.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  Y.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  INDIGO.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  Z.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  BASIL.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  HENNA.ARIN.NET 
.
63.in-addr.arpa.86400   IN  NS  X.ARIN.NET 
.
;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET 
) in 76 ms


188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH1.JOINK.COM 
.
188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH2.JOINK.COM 
.
;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET 
) in 75 ms


188.134.63.in-addr.arpa. 3600   IN  SOA dauth1.joink.com 
. noc.joink.com . 
200  
9121525 86400 3600 777600 3600
;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM 
) in 0 ms


As I said, this isn't quite how Albitz & Liu show delegation for 
reverse lookup zones. Nevertheless, the only difference that I see 
between w

Re: Delegating in reverse lookup zones

[Joseph S D Yao]

On Tue, Dec 15, 2009 at 01:52:50PM -0500, Simon Dodd wrote:
> I'm having a problem configuring a delegation. We have various /24s for
> which we provide PTR records. If I create a zone file for
> 188.134.63.in-addr.arpa and add PTR records, they resolve just fine. In
> other words, if this is my zone, I can resolve 63.134.188.13:
...


Mr. Dodd,

When you created "joink.com", you had to list the name servers in the
zone file for that zone, but you also had to register with the ".com"
domain and have them put the SAME IDENTICAL name server information in
the ".com" zone files.

If you create a new zone "east.joink.com", you would have to list the
name servers in the zone file for that zone, but you would also have to
put the SAME IDENTICAL name server information in the "joink.com" zone
files.

Reverse DNS is exactly the same as forward DNS, but with numbers.  When
you create a zone 188.134.63.in-addr.arpa, you must contact the owners
of the 134.63.in-addr.arpa zone and ask them to put the SAME IDENTICAL
name server information in the "134.63.in-addr.arpa" zone files.

I stress SAME IDENTICAL name server information because the next part is
so often overlooked.  If you ever change the name server information for
188.134.63.in-addr.arpa, or joink.com, or the hypothetical subdomain
east.joink.com, you MUST MUST MUST notify the owners of the parent zone
so that they can change the information in the parent zone files to once
again be the SAME IDENTICAL name server information as in your newly
revised zone files.

I hope that this helps!


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegating in reverse lookup zones

[Barry Margolin]

In article ,
 Chris Buxton  wrote:

> It's not a valid delegation unless you control the parent zone.
> 
> ARIN is delegating the /24 reverse zone to you. You therefore have four 
> options that give control of the PTR records to the midwestfirst.com servers.

A fifth option is to use RFC 2317-style classless delegation for all 256 
entries in the reverse domain:

$GENERATE 0-255 $   IN  CNAME  $.0/24
0/24 IN NS ns1.midwestfirst.com.
0/24 IN NS ns2.midwestfirst.com.

Then have the customer change the name of their reverse zone to 
0/24.188.134.63.in-addr.arpa.

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

Re: Delegating in reverse lookup zones

[Joseph S D Yao]

On Tue, Dec 15, 2009 at 01:52:50PM -0500, Simon Dodd wrote:
...
> But that isn't what we want to do for this particular zone. We want to
> delegate all queries concerning 188.134.63.in-addr.arpa to
> ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says that's
> fair game, so here's how I configured the zone:
...


I'm sorry!  I read that too quickly the first time.

The simpler answer is, instead of delegating to YOU, have the owner of
134.63.in-addr.arpa delegate to MidwestFirst.

If you do not wish to do this, then DON'T have a zone file at all.
Instead of the zone being "type master;" have it be "type forward;".
And list "forwarders { 65.113.74.3; 65.113.74.4; };" [that being the IP
addresses of the two name servers with the actual information].  Then
you will be proxying their domains back to people who query you.

The problem is, of course, that if they list their own name servers as
the domain's name servers, then the information will be inconsistent
between parent and child.  For consistency, they should list your name
servers.  If they are sufficiently enlightened or security-conscious as
to have separate resolving name servers and authoritative name servers,
then their resolving name servers can have the same "forward" zone
declaration as your name servers.


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Doug Barton]

Chris Thompson wrote:
> (Evan Hunt)
>> Adding SHA-2 to 9.6.x would violate our policy of making major
>> functional changes only in major releases, so I don't expect we'll
>> do that.  Given the odd circumstances you mentioned, I won't say for
>> certain that we won't--but I doubt it.
>>
>> 9.7.0 is going to be final in a little over a month, which is fortunate
>> timing.
> 
> (But it's not too obvious to me that adding support for a new signing
> algorithm should necessarily be considered a "major functional change".)

Yes, I remembered Evan's statement from a while back, and didn't
respond at the time because I wanted to think about it some more.
Having thought about it, I agree with you that in my mind it's not a
"major functional change," and I strongly believe that adding support
for it in 9.6 is the right thing to do.

To expand on that a little more (and to slightly agree with Stephane)
it's already been necessary for anyone who wants to _validate_ to have
migrated to 9.6 for some time now. 9.6 has proven to be a good
release, and everyone that I've recommended upgrading to it has been
thoroughly satisfied. Therefore (within the "validator" demographic)
we've got a pretty good installed base for whom a minor version
upgrade would not be a problem, and will likely happen when 9.6.2 is
released in any case. Expecting that installed base to upgrade to an
unproven .0 release with a lot of new features (read, untried code
paths) is not realistic. And it should go without saying that this is
with all due respect to the fine people who actually write BIND code.
I know they work hard to get it right, but I also know we're _all_ human.

OTOH for those that want to _sign_ their zones I'm have been telling
people for a while now that they need to start working with 9.7. I
even created a FreeBSD port for the RC version (which I have not done
for previous RCs) to help accelerate that process.

BIND 9.6.2 is in the "b1" phase atm, which means that there is plenty
of time to get SHA2 in there and get the release out before a signed
root goes live. I encourage the folks at ISC to do so, and if you
agree I encourage you to make your voice heard.


Doug

-- 

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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

Re: Delegating in reverse lookup zones

[Joseph S D Yao]

On Tue, Dec 15, 2009 at 02:42:37PM -0500, Barry Margolin wrote:
...
> A fifth option is to use RFC 2317-style classless delegation for all 256 
> entries in the reverse domain:
> 
> $GENERATE 0-255 $   IN  CNAME  $.0/24
> 0/24 IN NS ns1.midwestfirst.com.
> 0/24 IN NS ns2.midwestfirst.com.
> 
> Then have the customer change the name of their reverse zone to 
> 0/24.188.134.63.in-addr.arpa.
...


My first reaction was that RFC 2317 was not intended for /24's.  But
darned if it wouldn't work, and would solve the parent/child consistency
problem I mentioned in my last response.  The problem it raises, of
course, is that not everybody understands what they're seeing when they
look at RFC-2317 configurations.  But if those who need to, do, this is
not a problem.


-- 
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegating in reverse lookup zones

[Chris Thompson]

On Dec 15 2009, Simon Dodd wrote:


I'm having a problem configuring a delegation. We have various /24s for
which we provide PTR records. If I create a zone file for
188.134.63.in-addr.arpa and add PTR records, they resolve just fine. In
other words, if this is my zone, I can resolve 63.134.188.13:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
2009121524; Serial number
86400 ; Refresh
3600  ; Retry
777600; Expire
3600) ; Minimum TTL
  IN  NS  dauth1.joink.com.
  IN  NS  dauth2.joink.com.
13 IN  PTR midwest1st.com.

But that isn't what we want to do for this particular zone. We want to
delegate all queries concerning 188.134.63.in-addr.arpa to
ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says that's
fair game, so here's how I configured the zone:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
2009121524; Serial number
86400 ; Refresh
3600  ; Retry
777600; Expire
3600) ; Minimum TTL
  IN  NS  ns1.midwestfirst.com.
  IN  NS  ns2.midwestfirst.com.


You can't "delegate" the *whole* of a zone like that. You are claiming
to have an authoritative version of the zone, which contains no PTR
records ... and incidentally, that the official servers are those in
at ns*.midwestern.com. So you are in fact claiming to be something
like a "stealth slave" for the zone, but you are still authoritative,
and the rest of the world is going to believe your responses saying
that the PTR records don't exist.


Mutatis mutandis, that's the configuration that Albitz & Liu show for
delegating forward lookup zones (p. 232). It isn't quite how they show
reverse lookup zones (more on this in a moment), and unfortunately, it
doesn't work:

[r...@linux1 joink-domains]# dig -x 63.134.188.13 +trace

; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
;; global options:  printcmd
.   360 IN  NS  B.ROOT-SERVERS.NET.
.   360 IN  NS  M.ROOT-SERVERS.NET.
.   360 IN  NS  K.ROOT-SERVERS.NET.
.   360 IN  NS  E.ROOT-SERVERS.NET.
.   360 IN  NS  L.ROOT-SERVERS.NET.
.   360 IN  NS  A.ROOT-SERVERS.NET.
.   360 IN  NS  J.ROOT-SERVERS.NET.
.   360 IN  NS  G.ROOT-SERVERS.NET.
.   360 IN  NS  C.ROOT-SERVERS.NET.
.   360 IN  NS  F.ROOT-SERVERS.NET.
.   360 IN  NS  H.ROOT-SERVERS.NET.
.   360 IN  NS  I.ROOT-SERVERS.NET.
.   360 IN  NS  D.ROOT-SERVERS.NET.
;; Received 272 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms

63.in-addr.arpa.86400   IN  NS  DILL.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  Y.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  INDIGO.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  Z.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  BASIL.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  HENNA.ARIN.NET.
63.in-addr.arpa.86400   IN  NS  X.ARIN.NET.
;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 76 ms

188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH1.JOINK.COM.
188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH2.JOINK.COM.
;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET) in 75 ms

188.134.63.in-addr.arpa. 3600   IN  SOA dauth1.joink.com.
noc.joink.com.
200
9121525 86400 3600 777600 3600
;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM) in 0 ms

As I said, this isn't quite how Albitz & Liu show delegation for reverse
lookup zones. Nevertheless, the only difference that I see between what I
have configured and what they show is that I'm working with
188.134.63.in-addr.arpa, while they're working one level higher, at the
equivalent of 134.63.in-addr.arpa. 


Big difference. Big BIG difference. NS records only indicate a delegation
when they are *not* at the zone apex.


  Accordingly, they have to specify name
servers for 188 within the zone, whereas I can (I had thought) inhereit that
data from the zone. Maybe not, though, since it isn't working!

I even tried adding the "generate" command that they propose:

$TTL   6h
@   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
2009121526; Serial n

Re: Delegating in reverse lookup zones

[Simon Dodd]

Thanks for the replies, everyone; I think the consensus is that having ARIN
redelegate is the correct solution, and that's fine by me. (As mentioned, my
marching orders were to do this without redelegating, but if that's the
correct way to do it, I can make that case.)

-Simon

On Tue, Dec 15, 2009 at 3:18 PM, Chris Thompson  wrote:

> On Dec 15 2009, Simon Dodd wrote:
>
>  I'm having a problem configuring a delegation. We have various /24s for
>> which we provide PTR records. If I create a zone file for
>> 188.134.63.in-addr.arpa and add PTR records, they resolve just fine. In
>> other words, if this is my zone, I can resolve 63.134.188.13:
>>
>> $TTL   6h
>> @   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
>>2009121524; Serial number
>>86400 ; Refresh
>>3600  ; Retry
>>777600; Expire
>>3600) ; Minimum TTL
>>  IN  NS  dauth1.joink.com.
>>  IN  NS  dauth2.joink.com.
>> 13 IN  PTR midwest1st.com.
>>
>> But that isn't what we want to do for this particular zone. We want to
>> delegate all queries concerning 188.134.63.in-addr.arpa to
>> ns1.midwestfirst.com and ns2.midwestfirst.com. Albitz & Liu 4th says
>> that's
>> fair game, so here's how I configured the zone:
>>
>> $TTL   6h
>> @   345600  IN SOA  dauth1.joink.com. noc.joink.com. (
>>2009121524; Serial number
>>86400 ; Refresh
>>3600  ; Retry
>>777600; Expire
>>3600) ; Minimum TTL
>>  IN  NS  ns1.midwestfirst.com.
>>  IN  NS  ns2.midwestfirst.com.
>>
>
> You can't "delegate" the *whole* of a zone like that. You are claiming
> to have an authoritative version of the zone, which contains no PTR
> records ... and incidentally, that the official servers are those in
> at ns*.midwestern.com. So you are in fact claiming to be something
> like a "stealth slave" for the zone, but you are still authoritative,
> and the rest of the world is going to believe your responses saying
> that the PTR records don't exist.
>
>
>  Mutatis mutandis, that's the configuration that Albitz & Liu show for
>> delegating forward lookup zones (p. 232). It isn't quite how they show
>> reverse lookup zones (more on this in a moment), and unfortunately, it
>> doesn't work:
>>
>> [r...@linux1 joink-domains]# dig -x 63.134.188.13 +trace
>>
>> ; <<>> DiG 9.2.1 <<>> -x 63.134.188.13 +trace
>> ;; global options:  printcmd
>> .   360 IN  NS  B.ROOT-SERVERS.NET.
>> .   360 IN  NS  M.ROOT-SERVERS.NET.
>> .   360 IN  NS  K.ROOT-SERVERS.NET.
>> .   360 IN  NS  E.ROOT-SERVERS.NET.
>> .   360 IN  NS  L.ROOT-SERVERS.NET.
>> .   360 IN  NS  A.ROOT-SERVERS.NET.
>> .   360 IN  NS  J.ROOT-SERVERS.NET.
>> .   360 IN  NS  G.ROOT-SERVERS.NET.
>> .   360 IN  NS  C.ROOT-SERVERS.NET.
>> .   360 IN  NS  F.ROOT-SERVERS.NET.
>> .   360 IN  NS  H.ROOT-SERVERS.NET.
>> .   360 IN  NS  I.ROOT-SERVERS.NET.
>> .   360 IN  NS  D.ROOT-SERVERS.NET.
>> ;; Received 272 bytes from 12.109.94.5#53(12.109.94.5) in 1 ms
>>
>> 63.in-addr.arpa.86400   IN  NS  DILL.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  Y.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  INDIGO.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  Z.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  BASIL.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  HENNA.ARIN.NET.
>> 63.in-addr.arpa.86400   IN  NS  X.ARIN.NET.
>> ;; Received 180 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 76 ms
>>
>> 188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH1.JOINK.COM.
>> 188.134.63.in-addr.arpa. 86400  IN  NS  DAUTH2.JOINK.COM.
>> ;; Received 95 bytes from 192.35.51.32#53(DILL.ARIN.NET) in 75 ms
>>
>> 188.134.63.in-addr.arpa. 3600   IN  SOA dauth1.joink.com.
>> noc.joink.com.
>> 200
>> 9121525 86400 3600 777600 3600
>> ;; Received 100 bytes from 63.134.128.150#53(DAUTH1.JOINK.COM) in 0 ms
>>
>> As I said, this isn't quite how Albitz & Liu show delegation for reverse
>> lookup zones. Nevertheless, the only difference that I see between what I
>> have configured and what they show is that I'm working with
>> 188.134.63.in-addr.arpa, while they're working one level hi

Re: Delegating in reverse lookup zones

[Doug Barton]

Simon Dodd wrote:
> Thanks for the replies, everyone; I think the consensus is that having
> ARIN redelegate is the correct solution, and that's fine by me. (As
> mentioned, my marching orders were to do this without redelegating, but
> if that's the correct way to do it, I can make that case.)

It IS the correct and simplest way to do it, yes.

You CAN handle the whole zone like an RFC 2317 delegation if you want
to, but that's kind of silly.


Doug

-- 

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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

Re: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Doug Barton]

Evan Hunt wrote:
>> BIND 9.6.2 is in the "b1" phase atm, which means that there is plenty
>> of time to get SHA2 in there and get the release out before a signed
>> root goes live. I encourage the folks at ISC to do so, and if you
>> agree I encourage you to make your voice heard.
> 
> We hear you. 

That's as much as I can hope for, thanks. :)

Doug

-- 

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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

Re: Delegating in reverse lookup zones

[Chris Buxton]

On Dec 15, 2009, at 11:42 AM, Barry Margolin wrote:

> In article ,
> Chris Buxton  wrote:
> 
>> It's not a valid delegation unless you control the parent zone.
>> 
>> ARIN is delegating the /24 reverse zone to you. You therefore have four 
>> options that give control of the PTR records to the midwestfirst.com servers.
> 
> A fifth option is to use RFC 2317-style classless delegation for all 256 
> entries in the reverse domain:
> 
> $GENERATE 0-255 $   IN  CNAME  $.0/24
> 0/24 IN NS ns1.midwestfirst.com.
> 0/24 IN NS ns2.midwestfirst.com.
> 
> Then have the customer change the name of their reverse zone to 
> 0/24.188.134.63.in-addr.arpa.

That approach was included with my option 3. I prefer the DNAME approach 
(instead of individual CNAME's) in this case, but that's just my opinion.

I would never recommend following that RFC's pattern of addr/mask (i.e. 0/24 in 
this case). Use something else, like "mw", as the artificially-added label.


Chris Buxton
Professional Services
Men & Mice

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

Re: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Evan Hunt]

> BIND 9.6.2 is in the "b1" phase atm, which means that there is plenty
> of time to get SHA2 in there and get the release out before a signed
> root goes live. I encourage the folks at ISC to do so, and if you
> agree I encourage you to make your voice heard.

We hear you.  Expect a decision in the next few days.

--
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: Handling of RSASHA256 and RSASHA512 in BIND 9.6.0 and BIND 9.6.0-P1

[Mark Andrews]

In message , Chris Tho
mpson writes:
> (But it's not too obvious to me that adding support for a new signing
> algorithm should necessarily be considered a "major functional change".)

If it was *just* adding a new signing algorithm then yes it would be a minor
change.  A lot more happened under the hood to support the new algorithms
on all platforms.  Remember crypto support on some platforms is pretty
old and doesn't support SHA256/512 + RSA directly so we had to use more
primative methods on these platforms.

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