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 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
On Mon, Dec 14, 2009 at 08:05:40PM -0800,
Doug Barton do...@dougbarton.us 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
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.NET. .
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 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
In article mailman.1304.1260905564.14796.bind-us...@lists.isc.org, Chris Buxton cbux...@menandmice.com 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: 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 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
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
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 number
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 at 3:18 PM, Chris Thompson c...@cam.ac.uk 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 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.
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 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
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
On Dec 15, 2009, at 11:42 AM, Barry Margolin wrote: In article mailman.1304.1260905564.14796.bind-us...@lists.isc.org, Chris Buxton cbux...@menandmice.com 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
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
In message prayer.1.3.2.0912151543550.32...@hermes-1.csi.cam.ac.uk, 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
