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