On 12.3.2015 12:21, Petr Spacek wrote: > On 11.3.2015 17:02, Martin Kosek wrote: >> On 03/11/2015 04:55 PM, Petr Spacek wrote: >>> On 11.3.2015 15:45, Martin Kosek wrote: >>>> On 03/11/2015 03:38 PM, Petr Spacek wrote: >>>>> On 11.3.2015 15:28, Martin Kosek wrote: >>>>>> On 03/11/2015 12:43 PM, Petr Spacek wrote: >>>>>>> On 11.3.2015 11:34, Jan Cholasta wrote: >>>>>>>> Dne 11.3.2015 v 11:12 Petr Spacek napsal(a): >>>>>>>>> On 10.3.2015 20:04, Simo Sorce wrote: >>>>>>>>>> On Tue, 2015-03-10 at 19:24 +0100, Petr Spacek wrote: >>>>>>>>>>> On 10.3.2015 18:36, Simo Sorce wrote: >>>>>>>>>>>> On Tue, 2015-03-10 at 18:26 +0100, Petr Spacek wrote: >>>>>>>>>>>>> On 10.3.2015 17:35, Simo Sorce wrote: >>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> [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 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> GenericRecord;TYPE256->UriRecord. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>> Hmm, it does not sound like a thing we should care in this case. >>>>>>>>>>>>> DNS >>>>>>>>>>>>> tree is >>>>>>>>>>>>> not meant for direct consumption by LDAP clients (compare with >>>>>>>>>>>>> cn=compat). >>>>>>>>>>>>> >>>>>>>>>>>>> IMHO the only two clients we should care are FreeIPA framework and >>>>>>>>>>>>> bind-dyndb-ldap so I do not see this as a problem, really. If >>>>>>>>>>>>> someone >>>>>>>>>>>>> wants to >>>>>>>>>>>>> access DNS tree by hand - sure, use a standard compliant client! >>>>>>>>>>>>> >>>>>>>>>>>>> Working ACI and LDAP filters sounds like good price for >>>>>>>>>>>>> supporting only >>>>>>>>>>>>> standards compliant clients. >>>>>>>>>>>>> >>>>>>>>>>>>> AFAIK OpenLDAP works well and I suspect that ApacheDS will work >>>>>>>>>>>>> too because >>>>>>>>>>>>> Eclipse has nice support for sub-types built-in. If I can draw >>>>>>>>>>>>> some >>>>>>>>>>>>> conclusions from that, sub-types are not a thing aliens forgot >>>>>>>>>>>>> here when >>>>>>>>>>>>> leaving Earth one million years ago :-) >>>>>>>>>>>>> >>>>>>>>>>>>>> The problem with subtypes and ACIs though is that I think ACIs >>>>>>>>>>>>>> do not >>>>>>>>>>>>>> care about the subtype unless you explicit mention them. >>>>>>>>>>>>> IMHO that is exactly what I would like to see for GenericRecord. >>>>>>>>>>>>> It >>>>>>>>>>>>> allows us >>>>>>>>>>>>> to write ACI which allows admins to add any GenericRecord and at >>>>>>>>>>>>> the >>>>>>>>>>>>> same time >>>>>>>>>>>>> allows us to craft ACI which allows access only to >>>>>>>>>>>>> GenericRecord;TYPE65280 for >>>>>>>>>>>>> specific group/user. >>>>>>>>>>>>> >>>>>>>>>>>>>> So perhaps bind_dyndb_ldap should refuse to use a generic type >>>>>>>>>>>>>> that >>>>>>>>>>>>>> shadows DNSSEC relevant records ? >>>>>>>>>>>>> Sorry, this cannot possibly work because it depends on up-to-date >>>>>>>>>>>>> blacklist. >>>>>>>>>>>>> >>>>>>>>>>>>> How would the plugin released in 2015 know that highly sensitive >>>>>>>>>>>>> OPENPGPKEY >>>>>>>>>>>>> type will be standardized in 2016 and assigned number XYZ? >>>>>>>>>>>> >>>>>>>>>>>> Ok, show me an example ACI that works and you get my ack :) >>>>>>>>>>> >>>>>>>>>>> Am I being punished for something? :-) >>>>>>>>>>> >>>>>>>>>>> Anyway, this monstrosity: >>>>>>>>>>> >>>>>>>>>>> (targetattr = "objectclass || txtRecord;test")(target = >>>>>>>>>>> "ldap:///idnsname=*,cn=dns,dc=ipa,dc=example";)(version 3.0;acl >>>>>>>>>>> "permission:luser: Read DNS Entries";allow (compare,read,search) >>>>>>>>>>> userdn = >>>>>>>>>>> "ldap:///uid=luser,cn=users,cn=accounts,dc=ipa,dc=example";;) >>>>>>>>>>> >>>>>>>>>>> Gives 'luser' read access only to txtRecord;test and *not* to the >>>>>>>>>>> whole >>>>>>>>>>> txtRecord in general. >>>>>>>>>>> >>>>>>>>>>> $ kinit luser >>>>>>>>>>> $ ldapsearch -Y GSSAPI -s base -b >>>>>>>>>>> 'idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example' >>>>>>>>>>> SASL username: luser@IPA.EXAMPLE >>>>>>>>>>> >>>>>>>>>>> # txt, ipa.example., dns, ipa.example >>>>>>>>>>> dn: idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example >>>>>>>>>>> objectClass: top >>>>>>>>>>> objectClass: idnsrecord >>>>>>>>>>> tXTRecord;test: Guess what is new here! >>>>>>>>>>> >>>>>>>>>>> Filter '(tXTRecord;test=*)' works as expected and returns only >>>>>>>>>>> objects with >>>>>>>>>>> subtype ;test. >>>>>>>>>>> >>>>>>>>>>> The only weird thing I noticed is that search filter >>>>>>>>>>> '(tXTRecord=*)' does not >>>>>>>>>>> return the object if you have access only to an subtype with >>>>>>>>>>> existing value >>>>>>>>>>> but not to the 'vanilla' attribute. >>>>>>>>>>> >>>>>>>>>>> Maybe it is a bug? I will think about it for a while and possibly >>>>>>>>>>> open a >>>>>>>>>>> ticket. Anyway, this is not something we need for implementation. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> For completeness: >>>>>>>>>>> >>>>>>>>>>> $ kinit admin >>>>>>>>>>> $ ldapsearch -Y GSSAPI -s base -b >>>>>>>>>>> 'idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example' >>>>>>>>>>> SASL username: admin@IPA.EXAMPLE >>>>>>>>>>> >>>>>>>>>>> # txt, ipa.example., dns, ipa.example >>>>>>>>>>> dn: idnsname=txt,idnsname=ipa.example.,cn=dns,dc=ipa,dc=example >>>>>>>>>>> objectClass: top >>>>>>>>>>> objectClass: idnsrecord >>>>>>>>>>> tXTRecord: nothing >>>>>>>>>>> tXTRecord: something >>>>>>>>>>> idnsName: txt >>>>>>>>>>> tXTRecord;test: Guess what is new here! >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> And yes, you assume correctly that (targetattr = "txtRecord") gives >>>>>>>>>>> access to >>>>>>>>>>> whole txtRecord including all its subtypes. >>>>>>>>>>> >>>>>>>>>>> ACK? :-) >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ACK. >>>>>>>>> >>>>>>>>> Thank you. Now to the most important and difficult question: >>>>>>>>> Should the attribute name be "GenericRecord" or "UnknownRecord"? >>>>>>>>> >>>>>>>>> I like "GenericRecord" but Honza prefers "UnknownRecord" so we need a >>>>>>>>> third >>>>>>>>> opinion :-) >>>>>>>> >>>>>>>> GenericRecord sounds like something that may be used for any record >>>>>>>> type, >>>>>>>> known or unknown. I don't think that's what we want. We want users to >>>>>>>> use it >>>>>>>> only for unknown record types and use appropriate <type>Record >>>>>>>> attribute for >>>>>>>> known attributes. >>>>>>>> >>>>>>>> The RFC is titled "Handling of *Unknown* DNS Resource Record (RR) >>>>>>>> Types". The >>>>>>>> word "generic" is used only when referring to encoding of RDATA. >>>>>>> >>>>>>> Okay, be it 'UnknownRecord'. >>>>>>> >>>>>>> Petr^2 Spacek >>>>>> >>>>>> I am just afraid it is quite general name, that may collide with other >>>>>> attribute names. If it would be named "idnsUnknownRecord", it would be >>>>>> more >>>>>> unique. But I assume we cannot add idns prefix for records themselves... >>>>> >>>>> Good point. What about UnknownDNSRecord? >>>> >>>> Maybe. Question is how consistent we want to be with other DNS record names >>>> (arecord, ptrrecord) and how consistent we want to be with Uninett schema >>>> (details in https://fedorahosted.org/bind-dyndb-ldap/wiki/LDAPSchema) and >>>> if >>>> this new record would be discussed with them and added to their OID space. >>> >>> Currently my intention is to contact Uninett and try to standardize it when >>> we >>> finally agree on something. >>> >> >> I think we agreed on UnknownRecord or it's variant, so please feel free to >> contact and ask them. I think they will be more surprised with the subtype >> than >> with the actual name :-) > > Sure. I e-mailed dr...@uninett.no with the latest version of proposal and link > to this thread.
For the record, design page available on https://fedorahosted.org/bind-dyndb-ldap/wiki/Design/UnknownRecord It simply summarizes this thread, I did not do any changes to it. E-mail ping-pong with upstream is in progress. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
