@pemensik where the LDAP schema comes from?

I added just new types from iana.org database. I did create it from existing types already present. Although I do not understand schema too much, I just imitated existing entries already in bind-dyndb-ldap. Does it have other primary source than already mentioned COSINE database?

Added types I thought might be useful in LDAP database too. Especially URI for kerberos should help. But it does not try syntax checking on LDAP side.

The only source of this is: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

Any my by-hand adaptation. AFAIK it does not attempt to validate the format of this record, but I understood that is done for most of records anyway.

No, it does not work this way. Somebody have to register and own the LDAP schema OIDs. Were they registered by someone in IANA PEN?

I cannot find anyone owning 1.3.6.1.4.1.2428.20.1.48, for example:

attributeTypes: ( 1.3.6.1.4.1.2428.20.1.48 
 NAME 'dNSKEYRecord' 
 DESC 'DNSKEY RR, RFC 4034' 
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 
 EQUALITY caseIgnoreIA5Match 
 SUBSTR caseIgnoreIA5SubstringsMatch )

Where did you get that 1.3.6.1.4.1.2428.20.1.48 OID? The OID for the new attribute or class must be registered somewhere to not stomp over someone else. I can register these in Red Hat's namespace, for example, but then your PR cannot be used as it is. :-)

oh. I expected some of that subspace were already dedicated for DNS records, because existing records even like DSRecord shared common prefix and last number were just IANA allocated number, so there should not be a conflict.

So there are like MIB files in SNMP. I have no idea where to find public trees of already registered names. Is there something like public registry?

Ah, I see. Original aRecord has official registration and is publicly visible: https://oidref.com/0.9.2342.19200300.100.1.26

But a lot of existing records in the schema does not have any registered records there, not even AAAA record. https://oidref.com/1.3.6.1.4.1.2428.20.1 is almost empty. Seems even Petr Špaček added values into this without registering them to Red Hat, even when he were still working there in 2015.

I do not know what is the correct process for these records, but it seems instructions on the top of that schema file should be adjusted somehow. It does not seem 2.16.840.1.113730.3.8.5 is registered to freeipa like it is suggested.

There seems to be existing enterprise number for Fedora and Red Hat. I expect it should be assigned somehow. But since FreeIPA has a lot of definitions similar I am sure, maybe just a new group should be dedicated for DNS records in any valid range. But I expect we cannot renumber existing old records, even if they refer to wrong organization.

https://www.iana.org/assignments/enterprise-numbers/?q=fedora

Ah, but at least URIRecord was added into ipa-server-common long ago. It seems this is not updated copy in documentation and maybe should just point to https://pagure.io/freeipa/blob/master/f/install/share/60ipadns.ldif, where it seems actually used schema resides. That already supports URI record for example, but no other object. And it should be updated there only, because that file is used as an actual schema.

I have found oldest reference to uninett OIDs at RIPE 50 bind9 ldap presentation. Links inside are all gone, including any schemas if they ever existed. I have found schema in bind 9.11 for DLZ plugin, but that uses different OID.

Okay, here should be just added note that this is unmaintained and old copy. The rest should be added into freeipa directly.

Created freeipa PR instead. This would not be used anyway. https://github.com/freeipa/freeipa/pull/7966. I think we want to add here that this copy is not used and should not be updated. Nothing else.

FreeIPA OIDs are part of the Red Hat IANA tree, managed internally at Red Hat. We have control on our side to store them and upstream FreeIPA project allocates OIDs from that subtree.