#3972 Some DNS records created via IPA CLI/WebUI cannot be updated via nsupdate
Opened 10 years ago by pspacek. Modified 4 years ago

The problem envisioned in [ticket #12]]([https://fedorahosted.org/bind-dyndb-ldap/ticket/12|bind-dyndb-ldap) is there.

Generally, the problem is that single record can be encoded in various ways and FreeIPA interfaces has no clue about the proper syntax:
For example:

record.example.com 500 IN TXT "test"

is the same as

record.example.com 500 IN TXT test

and that is the same as

record.example.com 500 IN TXT \116est

User can use any form when writing to LDAP, but then bind-dyndb-ldap has hard time when the record is modified.

I can see two solutions:

  • use DNS Python to convert strings to canonical form in FreeIPA framework (which is only partial solution)

    import dns.rdata
    d = dns.rdata
    d.from_text(1, 16, t)
    "a" "b"
    <DNS IN TXT rdata: "a" "b">
    d.from_text(1, 16, t)
    \097 \098
    <DNS IN TXT rdata: "a" "b">

  • teach 389 DS about DNS syntaxes (which is ultimate solution)

    • I think that this could be done as very thin wrapper around BIND parser, which is available in bind-libs package (/usr/include/bind9/dns/rdata.h, dns_rdata_fromtext and dns_rdata_totext)
    • It would mean 100 % data compatibility

I forgot to mention some nice "side-effects" of 389 plugin:

  • It will not possible to add duplicate of a record (i.e. the same data encoded in different way, which is not allowed in DNS)
  • Constrains like maximum length of TXT and other records will be enforced (which are not enforced at the moment)
  • IP address syntax will be checked on DS side

This could be implemented as a 389 DS syntax plug-in. A syntax plug-in is responsible for syntax checking, normalization, comparison, and filter/index related operations

How do you see things working with regards to adding DNS records? Do you want DS to normalize the value before storing it, or do you want to DS store it as provided (assuming it passes your validation checks)?

What about searching? Will you be using the DNS record attribute as a part of a search filter? If you aren't normlizing the attributes prior to storing them, you will need to define custom matching rules that are able to determine if two values are "equal" according to BIND. If the values are normalized before storing them, you could just use one of the regular string comparison matching rules (like CIS).

Replying to [comment:2 nkinder]:

How do you see things working with regards to adding DNS records? Do you want DS to normalize the value before storing it, or do you want to DS store it as provided (assuming it passes your validation checks)?
I assume that record modification is less likely than reading, so normalizing the value before storing sounds like a good idea. This will be the simpler variant, if I understand correctly, right? (All the normalization code is available in bind-libs, so we just want to wrap it up.)

What about searching? Will you be using the DNS record attribute as a part of a search filter?
We don't use attribute value directly in search filter, but there are some operations where match on attribute value is necessary:

  • Modifications which delete particular value from an object:

    dn: idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test
    changetype: modify
    delete: tXTRecord
    tXTRecord: random string
    -

  • Search based on idnsName attribute (which should have DNS syntax - the idnsName) in DN:

    command line : ldapsearch -H ldap://ipa.test:389 -x -D "cn=Directory manager" -W -b "idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test" -s base -a always "(objectClass=)" ""

    baseObject : idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test

    scope : baseObject (0)

    filter : (objectClass=*)

    attributes : *

(Now I realized that the same applies to example of modification mentioned above.)

If you aren't normlizing the attributes prior to storing them, you will need to define custom matching rules that are able to determine if two values are "equal" according to BIND. If the values are normalized before storing them, you could just use one of the regular string comparison matching rules (like CIS).
I don't know what CIS means but I hope that I got the overall message :-) Generally, the normalization should do the trick. Theoretically in some cases it could be simpler to use comparison functions provided by bind-libs, but I'm not 100 % sure about that.

I tried to quickly read http://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Plug-in_Guide/index.html but I can't find any section dedicated to syntax plugins... Is it a problem with my eyes or should I open a bug for that? :-)

Thank you for your time, Nathan!

Replying to [comment:4 pspacek]:

Replying to [comment:2 nkinder]:

How do you see things working with regards to adding DNS records? Do you want DS to normalize the value before storing it, or do you want to DS store it as provided (assuming it passes your validation checks)?
I assume that record modification is less likely than reading, so normalizing the value before storing sounds like a good idea. This will be the simpler variant, if I understand correctly, right? (All the normalization code is available in bind-libs, so we just want to wrap it up.)

It might be simpler. It will require some investigation to be sure.

What about searching? Will you be using the DNS record attribute as a part of a search filter?
We don't use attribute value directly in search filter, but there are some operations where match on attribute value is necessary:
* Modifications which delete particular value from an object:
{{{
dn: idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test
changetype: modify
delete: tXTRecord
tXTRecord: random string
-
}}}

We will need to use the BIND functions for comparison here if we want to allow the value specified in the modify operation to be equivalent to the value in the database as considered by BIND (not a string match).

  • Search based on idnsName attribute (which should have DNS syntax - the idnsName) in DN:
    {{{

command line : ldapsearch -H ldap://ipa.test:389 -x -D "cn=Directory manager" -W -b "idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test" -s base -a always "(objectClass=)" ""

baseObject : idnsname=name,idnsname=ipa.test,cn=dns,dc=ipa,dc=test

scope : baseObject (0)

filter : (objectClass=*)

attributes : *

}}}

DNs are special, so I think you might have to have the search base that the client specifies match the normalized form in the database. This will require some investigation.

(Now I realized that the same applies to example of modification mentioned above.)

If you aren't normlizing the attributes prior to storing them, you will need to define custom matching rules that are able to determine if two values are "equal" according to BIND. If the values are normalized before storing them, you could just use one of the regular string comparison matching rules (like CIS).
I don't know what CIS means but I hope that I got the overall message :-) Generally, the normalization should do the trick. Theoretically in some cases it could be simpler to use comparison functions provided by bind-libs, but I'm not 100 % sure about that.

Sorry, CIS is "case ignore string". It's basically like strcasecmp(). I think we will have to use the BIND comparison functions to cover the modify operation case you listed above.

I tried to quickly read http://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Plug-in_Guide/index.html but I can't find any section dedicated to syntax plugins... Is it a problem with my eyes or should I open a bug for that? :-)

Sure. It's very uncommon to add syntax plug-ins, as everyone tends to just use the standard LDAP syntaxes. I am not aware of any syntax plug-ins outside of the ones contained in the 389 DS source tree, so this task might end up being a case study for creating the documentation. :)

Thank you for your time, Nathan!

No problem. I'll file a 389 DS trac ticket about this as well.

A 389 DS trac ticket has been opened for the new syntax plug-in request:

https://fedorahosted.org/389/ticket/47564

Follow up ticket for applying the syntax plugin: #3998.

For now, we should at least normalize the values with FreeIPA normalizers. Moving to 3.4. Can be done together with #3169.

Martin, this is related to your effort in #3169. python-dns should be able to do the heavy lifting for you.

Moving unfinished November tickets to January.

#4311 is duplicate of this ticket.

Isn't this ticket also a duplicate of #3205?

As this includes nontrivial development in the DS (plugin) and there is not enough time in 4.0, I am moving to next feature release - 4.2.

Processing leftovers from 4.2 backlog - this ticket was found as suitable for consideration in next big feature release - 4.4.

Metadata Update from @pspacek:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.5 backlog

7 years ago

Metadata Update from @mbasti:
- Issue assigned to tkrizek (was: mbasti)
- Issue close_status updated to: None

6 years ago

Metadata Update from @tkrizek:
- Assignee reset

4 years ago

Login to comment on this ticket.

Metadata