Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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.
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 03/10/2015 07:24 PM, 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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 11.3.2015 08:13, Martin Kosek wrote: On 03/10/2015 07:24 PM, 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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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. The problem with subtypes and ACIs though is that I think ACIs do not care about the subtype unless you explicit mention them. So perhaps bind_dyndb_ldap should refuse to use a generic type that shadows DNSSEC relevant records ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 Done! Simo. Related tickets === https://fedorahosted.org/freeipa/ticket/4939 https://fedorahosted.org/bind-dyndb-ldap/ticket/157 [0] http://tools.ietf.org/html/rfc3597 [1] http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 [5] http://tools.ietf.org/html/rfc3597#section-5 -- Petr^2 Spacek -- Simo Sorce * Red Hat, Inc * New York -- 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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? Petr^2 Spacek Done! Simo. Related tickets === https://fedorahosted.org/freeipa/ticket/4939 https://fedorahosted.org/bind-dyndb-ldap/ticket/157 [0] http://tools.ietf.org/html/rfc3597 [1] http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4 [5] http://tools.ietf.org/html/rfc3597#section-5 -- Petr^2 Spacek -- 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
On 03/10/2015 03:53 PM, 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 0A01
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
copypasting 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 0A01 will be represented as:
GenericRecord;TYPE65280: \# 4 0A01
CLI
===
$ ipa dnsrecord-add zone.example owner \
--generic-type=65280 --generic-data='\# 4 0A01'
$ ipa dnsrecord-show zone.example owner
Record name: owner
TYPE65280 Record: \# 4 0A01
CLI is inconsistent with current one. We have 2 modes: structured and
unstructured. With simo's proposal it should work better when specifying
multiple values.
we use different option name for structured mod/add and unstructured
even if the record has only one part, it could be:
$ ipa dnsrecord-add zone.example owner \
--generic-rec={65280 \# 4 0A01, 62347 \# 0}
$ ipa dnsrecord-add zone.example owner --structured \
--generic-value={65280 \# 4 0A01, 62347 \# 0}
For mod the same. If we stick with this, Web UI should be quite easy and
quick to create.
ACK? :-)
Almost.
We should refrain from using subtypes when not necessary, and in this
case it is not necessary.
Use:
GenericRecord: 65280 \# 4 0A01
Done!
Simo.
+1, it would also simplify code.
Related tickets
===
https://fedorahosted.org/freeipa/ticket/4939
https://fedorahosted.org/bind-dyndb-ldap/ticket/157
[0] http://tools.ietf.org/html/rfc3597
[1]
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
[5] http://tools.ietf.org/html/rfc3597#section-5
--
Petr^2 Spacek
--
Petr Vobornik
--
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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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
Re: [Freeipa-devel] Generic support for unknown DNS RR types (RFC 3597)
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 0A01 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 copypasting 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 0A01 will be represented as: GenericRecord;TYPE65280: \# 4 0A01 CLI === $ ipa dnsrecord-add zone.example owner \ --generic-type=65280 --generic-data='\# 4 0A01' $ ipa dnsrecord-show zone.example owner Record name: owner TYPE65280 Record: \# 4 0A01 ACK? :-) Almost. We should refrain from using subtypes when not necessary, and in this case it is not necessary. Use: GenericRecord: 65280 \# 4 0A01 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 -
