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)". 3, Its dn is not in "ldapsearch -Y GSSAPI -b idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com" output.
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 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
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.fedorahoste... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
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.fedorahoste...
Do not reply to spam on the list, report it:
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.fedorahoste...
Do not reply to spam on the list, report it:
freeipa-users@lists.fedorahosted.org