On Tue, 2015-03-10 at 16:19 +0100, Petr Spacek wrote:
> On 10.3.2015 15:53, Simo Sorce wrote:
> > 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
> >> ). Here is the proposal:
> >> LDAP schema
> >> ===========
> >> - 1 new attribute:
> >> ( <OID> NAME 'GenericRecord' DESC 'unknown DNS record, RFC 3597' EQUALITY
> >> caseIgnoreIA5Match SYNTAX 18.104.22.168.4.1.1422.214.171.124.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 :
> >> 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  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
> I was considering that too but I can see two main drawbacks:
> 1) It does not work very well with DS ACI (targetattrfilter, anyone?). Adding
> generic write access to GenericRecord == ability to add TLSA records too,
> which you may not want. IMHO it is perfectly reasonable to limit write access
> to certain types (e.g. to one from private range).
> 2) We would need a separate substring index for emulating filters like
> (type==65280). AFAIK GenericRecord;TYPE65280 should work with presence index
> which will be handy one day when we decide to handle upgrades like
> Another (less important) annoyance is that conversion tools would have to
> mangle record data instead of just converting attribute name->record type.
> I can be convinced that subtypes are not necessary but I do not see clear
> advantage of avoiding them. What is the problem with subtypes?
Poor support by most clients, so it is generally discouraged.
The problem with subtypes and ACIs though is that I think ACIs do not
care about the subtype unless you explicit mention them.
So perhaps bind_dyndb_ldap should refuse to use a generic type that
shadows DNSSEC relevant records ?
Simo Sorce * Red Hat, Inc * New York
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code