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. -- 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
