Subject: DNAME [4.8]: DNAME and CIDR Blocks in in-addr.arpa

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 12 Oct 2006 12:23:43 +0200

Issue [4.8]:
   Is DNAME the Way to go for CIDR Blocks in in-addr.arpa?  Should this
   be addressed by this document?

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Peter Koch <[email-masked]>
Date: Thu, 12 Oct 2006 16:20:43 +0200

>    be addressed by this document?

I'd like to suggest we close this issue, since this topic would, if at all,
belong in an addendum to or update of RFC 2317/BCP 20.
That said, a property of DNAME is that all descendants of its owner are
treated equally, something that 'Classless delegation' was explicitly designed
to avoid. DNAMEs _could_ be used for prefixes shorter than /24 instead of
'mass delegations': for a /17, instead of 128 delegations install 128
DNAME RRs (and maybe one delegation). Still, I don't think that would be
in scope for 2672bis.

-Peter

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Oct 2006 10:55:15 +1000

> DNAME RRs (and maybe one delegation). Still, I don't think that would be

	I agree with Peter this is RFC 2317bis fodder.

	RFC 2317bis itself is long overdue and if it isn't on the
	dnsops adgenda it should be.
 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 30 Oct 2006 10:15:18 -0500

At 12:23 +0200 10/12/06, Wouter Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Issue [4.8]:

No.  Maybe.  If anything - say why DNAME isn't a replacement.

Let's say you are an ISP with 192.0.2./24 and are assigning to 
customers ranges like 192.0.2.16/28 and 192.0.2.32/28.  Further you 
want to allow the customers to have their own reverse map DNS (how 
nice of you!).

In the zone 2.0.192.in-addr.arpa, you would want to have these records:

16.2.0.192.in-addr.arpa. CNAME 16.reverse-map.customer1.example.
17.2.0.192.in-addr.arpa. CNAME 17.reverse-map.customer1.example.
...
31.2.0.192.in-addr.arpa. CNAME 31.reverse-map.customer1.example.
32.2.0.192.in-addr.arpa. CNAME 32.rev-map.sushi-and-tires.example.
33.2.0.192.in-addr.arpa. CNAME 33.rev-map.sushi-and-tires.example.
...
33.2.0.192.in-addr.arpa. CNAME 33.rev-map.sushi-and-tires.example.

And so on.  A DNAME wouldn't work because you don't assign the same 
"new" suffix to queries that "come in" to the zone.

The, I believe, implementation-specific BINDism "$GENERATE" acts 
better - as it is a zone "filler" and not a rewrite rule:

$GENERATE 16-31 $.2.0.192.in-addr.arpa. CNAME $.reverse-map.customer1.example.
$GENERATE 32-47 $.2.0.192.in-addr.arpa. CNAME 
$.rev-map.sushi-and-tires.example.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.