[Fedora-directory-users] Re: dns-ldap to Fedora Directory Server

[Dan Cox]

I dug through the RFCs. It appears the aRecord attribute was defined 
first as stated in RFC1274 (1991). Remember, these are all X.500 RFCs. 
Shortly thereafter, RFC1279 (1991) came out defining dNSRecord, as the 
preferred method for storing DNS attributes in X.500, but failed to 
recommend an OID.  Years later, an internet draft recommendation 
draft-ietf-asid-ldap-domains-01 (1997) recommended the dNSRecord 
attribute use the same OID as aRecord. This appears to be what Netscape 
has adopted and incorrectly attributed to 'Internet directory pilot' 
(RFC 1274). To add to the confusion, the schema this attribute is stored 
in hints towards RFC 2247, which bears no mention of dNSRecord or the 
draft recommendation.

Also note that the 28pilot.ldif schema contains the following statement:
#
# Schema from the pilot RFCs, especially RFC 1274, that is no longer
# recommended by Netscape for use in new deployments.  Please be aware
# that future RFCs that succeed RFC 1274 may deprecate some or all of
# these attribute types and classes.
#

This appears to not be the case according to RFC 3383 (2002 - current 
best practices for LDAP) where aRecord is mentioned and dNSRecord is 
not. So, one must assume that Netscape was in error since dNSRecord 
never made it into any RFC. Perhaps it should be fixed in the schema? 
s/dNSRecord/aRecord and move it to 28pilot.ldif? Perhaps keeping 
dNSRecord as an alias for compatability purposes.

CC'ing the FDS list for any thoughts.

Dan-

Daniel Williams wrote:

> It's really the old Netscape/iPlanet DS, which uses the " Netscape 
> RFC1274 " to define how domain names are stored in LDAP.
> Take a look at this 
> http://devel.it.su.se/cgi-bin/local/cvsweb.cgi/sukat-schema/pilot.schema?rev=1.1.1.1&content-type=text/x-cvsweb-markup&sortby=rev 
>
> But any way, I added the aRecord attribute to the dNSRecord and every 
> thing works fine, nice...
>
> Also, I setup a BIND 9.3.x flat file slave from the BIND 9.3 LDAP 
> server and every thing work great there as well.
>
> Thanks Dan for your help.....
>
> -Daniel
>
> venaas at ivanova.venaas.no wrote:
>
>> On Thu, Jul 14, 2005 at 09:16:00PM -0500, Dan Cox wrote:
>>  
>>
>>> Yes, I've done the conversion. The problem is the dnszone schema is 
>>> based on a deprecated RFC. The immediate conflict is with the 
>>> aRecord attribute, which uses the OID of the newer RFC spec 
>>> attribute dNSRecord.
>>>   
>>
>>
>> So the problem is that dnszone uses the same attribute name but a
>> different OID? Not sure I understood this correctly. What is their
>> syntax for aRecord, and where is it defined? It should not be a
>> problem using their aRecord definition if the syntax can hold the
>> necessary information.
>>
>> RFC 1274 says:
>>
>> 9.3.22.  DNS ARecord
>>
>>   The A Record attribute type specifies a type A (Address) DNS
>>   resource
>>   record [6] [7].
>>
>>     aRecord ATTRIBUTE
>>         WITH ATTRIBUTE-SYNTAX
>>             DNSRecordSyntax
>>     ::= {pilotAttributeType 26}
>>
>> and
>>
>>     DNSRecordSyntax ATTRIBUTE-SYNTAX
>>             IA5String
>>             MATCHES FOR EQUALITY
>>
>> and this should be fine. Have they somehow managed to break with this?
>>
>> So what is the FDS server? Is it really Netscape/iPlanet or something
>> else?
>>
>> Stig
>>
>>  
>>
>>> Here is the workaround:
>>> 1. convert the dnszone.schema to FDS format using the conversion 
>>> script on the web site.
>>> 2. save it to something like 99dns.ldif in 
>>> /opt/fedora-ds/slapd-*/config/schema/ directory.
>>> 3. edit 99dns.ldif and completely remove the aRecord attribute line.
>>> 4. edit 05rfc2247.ldif, find the dNSRecord attribute line and change 
>>> it to this:
>>> attributeTypes: ( 0.9.2342.19200300.100.1.26 NAME ( 'aRecord' 
>>> 'dNSRecord' )DESC 'Pilot attribute type' SYNTAX 
>>> 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'Internet directory pilot' )
>>>
>>> So we've basically tacked on the aRecord as an attribute alias name. 
>>> Note the aRecord is actually the primary name, making dNSRecord the 
>>> alias. This is important because if this is reversed, then it will 
>>> not work due to the way the LDAP server is queried. This IS a hack, 
>>> since the the format of the aRecord is not the same as dNSRecord in 
>>> the RFCs; however the directory server doesn't enforce the syntax 
>>> rules. So this shouldn't be a problem unless you use some other 
>>> services which rely on valid dNSRecord attribute syntax.
>>>
>>> I've seen a pretty good performance boost since moving from OpenLDAP 
>>> to FDS. I'm curious if others see the same results.
>>>
>>> Dan-
>>>
>>> Daniel Williams wrote:
>>>
>>>   
>>>
>>>> Hello,
>>>> Has anyone tried this?
>>>>
>>>> I'm working on getting the dNSZone moved over but the " Netscape " 
>>>> -- uses the same OID.
>>>>
>>>> Thanks up front.
>>>>
>>>> -Daniel
>>>> _______________________________________________
>>>> Dns-ldap mailing list
>>>> Dns-ldap at uninett.no
>>>> http://tyholt.uninett.no/mailman/listinfo/dns-ldap
>>>>     
>>>
>>> _______________________________________________
>>> Dns-ldap mailing list
>>> Dns-ldap at uninett.no
>>> http://tyholt.uninett.no/mailman/listinfo/dns-ldap
>>>
>>>   
>>
>>
>>  
>>
>
> _______________________________________________
> Dns-ldap mailing list
> Dns-ldap at uninett.no
> http://tyholt.uninett.no/mailman/listinfo/dns-ldap