[Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)

[Petr Spacek]

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

> You even used "*unknown* DNS record, RFC 3597" as description of the attribute
> yourself.
> 
>>
>>> Make sure it is abundantly clear in the docs what is the implication of
>>> giving access to the generic attribute w/o qualifications.
>>
>> Sure.