[Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
Petr Spacek
pspacek at redhat.com
Tue Apr 7 14:33:52 UTC 2015
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 at 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 at 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 drift at 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
More information about the Freeipa-devel
mailing list