more on DNS

[Robert L Ullmann <[e-mail]>]

Hi,

This is my current take on the DNS implications of CATNIP/TUBA:

I exchanged mail with a few people re .# vs .NSAP; several people
like .#, but both Postel and Mockapetris do not. So we use .NSAP (;-)

The extra .00 sel stays. I imagine user installation manuals in the near
future will say something like "You always have to add another .00 at
the end of the address for historical reasons; don't worry about it."
Any explanation will be far too voluminous for the quick-start guide.

The forward syntax is thus:

emu      IN  NSAP  47.0005.80.005a00.0000.0001.e137.08002010726e.00
         IN  A     129.6.55.32
	 IN  NSAP  C0.0000.81.06.37.20.00

the last being the CATNIP IP address under the AFI=192 assumption. (pending
a real assignment)

The pointers should use the existing PTR RR (agreed already; it is
technically valid).

However, IMO, the names should be octet based. If some allocation is 
actually done on a nibble and needs a corresponding delegation, it will
simply be done with 16xN NS records. (take into account all the notes
below when evaluating this please) Leading zeros are always there.

The inverse records are then:

$ORIGIN 37.e1.01.00.00.00.00.00.5a.00.80.05.00.47.nsap.
00.6e.72.10.20.00.08	PTR	emu.ncsl.nist.gov.
; and in another zone:
$ORIGIN 06.81.00.00.c0.nsap.
00.20.37		PTR	emu.ncsl.nist.gov.

(This has a nice symmetry.)

CATNIP specifies that DNS software should be able to generate "new"
DNS records (the NSAPs and PTRs to NSAP) *automatically* from the "old"
(A and PTR to A) records, generating new zones and zone delegations
as required.

DNS software should also be able to automatically update NS records
for delegated zones by reference to the authoritative servers (this
should be done now, it isn't an IPng item.) This makes off-octet
delegations much easier to maintain, both for CIDR and CATNIP.
(Has anyone seen a profile for an NSAP format that calls for non-octet
aligned delegations?)

DNS software should also be able to automatically generate PTR zones,
given a list of the "forward" zones that contain the requisite information.
(this is also independent of IPng.) This also makes PTR zones easier
to maintain independently of alignment.

If IPng commits to providing DNS software that automatically generates the
new RRs (not *necessarily* on the authoritative servers, remember!), this
will eliminate the foremost "transition" problem. CATNIP specifies this
as a requirement for vendors to implement in their DNS software.

----

When we can resolve the remaining difference (the exact name format in
the PTRs; I believe we will end up always using octets; we are beyond
sub-octet bit-twiddling except where forced to :-) I think we should
submit the I-D defining the NSAP RR and the .NSAP. part of the name
space as an RFC. Note that the specification of an RR is not subject
to the same standards track; it is "definitional" status, documenting
assigned code points. (cf RFC1183, which _defines_ several RRs.) The
draft does need to be revised to be a little less CLNP-specific, right?
Maybe even mention CATNIP? <grin>

----

Best Regards,
Robert
[phone]