Re: [dnsext] draft-levine-dnsextlang-02

[Miek Gieben <[e-mail]>]

[ Quoting <[e-mail]> in "Re: [dnsext] draft-levine-dnsextlan..." ]
> > * NSEC3 has a salt length which isn't used in the text representation of the
> >   record. How is this handled?
> 
> There should probably be a qualifier for a length prefix on hex data, as
> there is for base64.

Can you just say "this is length of the NEXT item"? Or does it need to be
generic "this is the length of item <NAME of ITEM>, which is more of a pointer.
 
> HIP RDATA is horrible. It would be slightly easier if the length fields
> prefixed the data they describe. The non-standard base64 restriction is
> ugly. The rendezvois servers should probably be listed in separate RRs of
> a different type, which would also solve the base64 problem. I think that
> awkward RRtypes like this should have special case handling, e.g. describe
> the RDATA as a single field of HIP type, or just leave it to RFC 3597
> generic representation.

Agreed, using 3597 syntax for such ugly RRs is probably the best.

> Ideally in the future RRDATA layouts will be simpler than this.

Well, an idea I have floating in my mind is: if your (new) RR can not
be described in terms of dnsextlang, you should think of a different
syntax. Not supporting the HIP record would help in that regard.

> > * The IPSECKEY RR uses some internal subtyping: if "gatewaytype" is 0 there is no
> >   gateway. If it is 1 or 2 its an IP address and if its 3 the gateway is a
> >   domain name. How to encode that?
> 
> Again I think this has to be handled in special case code. Really they
> should have used a different RR type for each layout.

As you said, why not avoid this whole mess and use 3597?

> Another awkward case is the variable-length IPv6 address field in A6
> records, but that has been deprecated forcefully enough that it is no
> problem to handle with RFC 3597 generic layout.

Are we now creating a hall of shame for badly designed RRs? :)

 Regards,

-- 
    Miek Gieben