[Freeipa-users] Error in IPA webinterface then DNS name contains \032 (<space>)

[Petr Vobornik]

On 03/22/2016 09:59 AM, Troels Hansen wrote:
> I have noticed a bug in the IPA webinterface,  under DNS Zones -> and clicking
> on a zone that contains a DNS record containig space (\032)
>
> Currently, I get: "LIFX\032Bulb: DNS resource record not found"
>
> However, after clicking OK, it displays the rest of the records.
>
> Its in no way a pretty DNS record, but still working.
> The reason for it being there is that I have enabled ddns updates from out DHCP
> server, and it works without any problems, except this crappy WIFI light bulb.
>
> The DNS record is in the IPA database:
>
>     Record name: LIFX\032Bulb
>     A record: 192.168.20.252
>     TXT record: "009143ca16c9890339c7ec33825e0da5ce"
>
> I can dig it:
> # dig "LIFX Bulb.casalogic.lan" A
> ..........
> ;; ANSWER SECTION:
> LIFX\032Bulb.casalogic.lan. 1800 IN    A    192.168.20.252
>
> However, something goes wrong in the web interface.
>
> I'm running IPA 4.2.0
>
> --
>
> Med venlig hilsen
>
> *Troels Hansen*

Tried it to reproduce on 4.3 development branch. It works for me in Web 
UI. But I get the error in CLI:

$ ipa dnsrecord-find my.zone.test.
... other records ...
   Record name: LIFX\032Bulb
   A record: 10.34.58.132
   TXT record: 009143ca16c9890339c7ec33825e0da5ce


$ ipa dnsrecord-show my.zone.test. LIFX\032Bulb
ipa: ERROR: LIFX032Bulb: DNS resource record not found

$ ipa dnsrecord-show my.zone.test. "LIFX Bulb"
   Record name: LIFX\032Bulb
   A record: 10.34.58.132
   TXT record: 009143ca16c9890339c7ec33825e0da5ce

web ui uses API command:
{"method":"dnsrecord_show","params":[["my.zone.test.","LIFX\\032Bulb"],{"all":true,"rights":true,"structured":true,"version":"2.163"}]}

Could you check what is yours?
1. open developer tool in browser (usually F12)
2. Network tab
3. Refresh the page, look at new request to ipa/session/json
4. examine "Request Payload"
some old example in FF: 
https://pvoborni.fedorapeople.org/images/devtools.png


I would say that there weren't any changes in 4.2 -> 4.3 it this area. 
So not sure why the behavior in your case is opposite.

Anyway it suggests minor encoding issue.
-- 
Petr Vobornik