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

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 t

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

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

Re: Delegating in reverse lookup zones

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 mi

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

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.

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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

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

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 i

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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 zo

Re: Delegating in reverse lookup zones

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

Re: Delegating in reverse lookup zones

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

Delegating in reverse lookup zones

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

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

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 t

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

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