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