[Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)

[Simo Sorce]

On Tue, 2015-03-10 at 15:32 +0100, Petr Spacek wrote:
> Hello,
> 
> I would like to discuss Generic support for unknown DNS RR types (RFC 3597
> [0]). Here is the proposal:
> 
> LDAP schema
> ===========
> - 1 new attribute:
> ( <OID> NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY
> caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
> 
> The attribute should be added to existing idnsRecord object class as MAY.
> 
> This new attribute should contain data encoded according to ​RFC 3597 section
> 5 [5]:
> 
> The RDATA section of an RR of unknown type is represented as a
>    sequence of white space separated words as follows:
> 
>       The special token \# (a backslash immediately followed by a hash
>       sign), which identifies the RDATA as having the generic encoding
>       defined herein rather than a traditional type-specific encoding.
> 
>       An unsigned decimal integer specifying the RDATA length in octets.
> 
>       Zero or more words of hexadecimal data encoding the actual RDATA
>       field, each containing an even number of hexadecimal digits.
> 
>    If the RDATA is of zero length, the text representation contains only
>    the \# token and the single zero representing the length.
> 
> Examples from RFC:
>       a.example.   CLASS32     TYPE731         \# 6 abcd (
>                                                ef 01 23 45 )
>       b.example.   HS          TYPE62347       \# 0
>       e.example.   IN          A               \# 4 0A000001
>       e.example.   CLASS1      TYPE1           10.0.0.2
> 
> 
> Open questions about LDAP format
> ================================
> Should we include "\#" constant? We know that the attribute contains record in
> RFC 3597 syntax so it is not strictly necessary.
> 
> I think it would be better to follow RFC 3597 format. It allows blind
> copy&pasting from other tools, including direct calls to python-dns.
> 
> It also eases writing conversion tools between DNS and LDAP format because
> they do not need to change record values.
> 
> 
> Another question is if we should explicitly include length of data represented
> in hexadecimal notation as a decimal number. I'm very strongly inclined to let
> it there because it is very good sanity check and again, it allows us to
> re-use existing tools including parsers.
> 
> I will ask Uninett.no for standardization after we sort this out (they own the
> OID arc we use for DNS records).
> 
> 
> Attribute usage
> ===============
> Every DNS RR type has assigned a number [1] which is used on wire. RR types
> which are unknown to the server cannot be named by their mnemonic/type name
> because server would not be able to do name->number conversion and to generate
> DNS wire format.
> 
> As a result, we have to encode the RR type number somehow. Let's use attribute
> sub-types.
> 
> E.g. a record with type 65280 and hex value 0A000001 will be represented as:
> GenericRecord;TYPE65280: \# 4 0A000001
> 
> 
> CLI
> ===
> $ ipa dnsrecord-add zone.example owner \
>   --generic-type=65280 --generic-data='\# 4 0A000001'
> 
> $ ipa dnsrecord-show zone.example owner
> Record name: owner
> TYPE65280 Record: \# 4 0A000001
> 
> 
> ACK? :-)

Almost.
We should refrain from using subtypes when not necessary, and in this
case it is not necessary.

Use:
GenericRecord: 65280 \# 4 0A000001

Done!

Simo.

> 
> Related tickets
> ===============
> https://fedorahosted.org/freeipa/ticket/4939
> https://fedorahosted.org/bind-dyndb-ldap/ticket/157
> 
> [0] http://tools.ietf.org/html/rfc3597
> [1]
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
> [5] http://tools.ietf.org/html/rfc3597#section-5
> 
> -- 
> Petr^2 Spacek
> 


-- 
Simo Sorce * Red Hat, Inc * New York