An update: 

After named-pkcs11.service being restarted, the PTR record is resolvable via "nslookup" or "host". 

Thanks.

Kathy. 

On Tue, Dec 14, 2021 at 2:17 PM Kathy Zhu <kzhu@nuro.ai> wrote:
Hi Rob,

Thank you for your reply. 

I looked it up using both "nslookup" and "host" commands. 

Adding idnsname=90.91 filter did not get me wanted results:

# ldapsearch -Y GSSAPI -b idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com idnsname=90.91

SASL/GSSAPI authentication started

SASL username: admin@EXAMPLE.COM

SASL SSF: 256

SASL data security layer installed.

# extended LDIF

#

# LDAPv3

# base <idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com> with scope subtree

# filter: idnsname=90.91

# requesting: ALL

#


# search result

search: 4

result: 32 No such object

matchedDN: cn=dns,dc=example,dc=com


# numResponses: 1

# 


I do not know the history of using xxx.xxx format reverse zones instead of discrete zones, I will suggest the team use discrete zones instead. 

For my learning, I wish someone could explain why xxx.xxx format reverse zones do not work. 

Many thanks! 

Kathy. 

On Tue, Dec 14, 2021 at 12:20 PM Rob Crittenden <rcritten@redhat.com> wrote:
Kathy Zhu via FreeIPA-users wrote:
> Hi List, 
>
> I created a PTR record "90.91" in "0.10.inaddr.arpa." zone via GUI, then
> found: 
>
> 1, I can see the record via GUI 
> 2, When I looked it up on the command line, I got "not found: 3(NXDOMAIN)".

How did you look?

> 3, Its dn is not in "ldapsearch -Y GSSAPI -b 
> idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com" output. 
>

You can add the target idnsname=90.91, e.g.

ldapsearch -Y GSSAPI -b
idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com idnsname=90.91

> Above 3 explained why the record could not be resolved. However, why
> does this happen? I can see the record in GUI, where is this record?

I'm not a DNS expert by far, but this format looks a bit off. I tend to
be simplistic and have actual zones for each reverse, so I'd have
created 91.0.10.inaddr.arpa. and added 90 to it.

I was able to duplicate what you see though using the ##.## format.

So I don't know if what you're doing is wrong or if it's something in
bind-dyndb-ldap, but having discrete zones is a workaround.

rob

> I created more PTR records for testing, they are all the same way - can
> be seen in GUI, but not resolvable and not in ldapsearch output. 
>
> Any idea for me to troubleshoot this?
>
> Many thanks. 
>
> Kathy 
>
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>