On 22.12.2016 10:57, Maciej Drobniuch wrote:
Hi Martin
Appreciate your help!
On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:
On 22.12.2016 09:37, Maciej Drobniuch wrote:
Hi Martin
Thank you for reply.
1. The dig is returning proper PTR record. I've added it manually
to the zone and it's working.
I was asking for SOA and zone name, IMO there is nothing secret
about reverse zone name from private address space
what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'
# python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn;
print resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.
It looks that python-dns failed to find proper zone, what is supposed to
be authoritative zone for that record in your system?
How do your reverse zones look?
2. The problem exists while adding host entries or A records with
"create reverse" option.
That's why I asked to run dig, the code uses DNS system to
determine zone.
3. If I'll bind a host with ipa-client-install the PTR record
gets created in the reverse zone and it works
Ok
Manually creating the PTR record works fine as well.
4. The resolv.conf file has only the IPA server IP
addres/localhost added.
Have you changed it recently?
Yes, it pointed to outside 8.8.8.8, so the OS did not see the local
reverse zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've manually
created the ptr)
# dig -x 10.0.0.165
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR
;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
<http://prdfrmprb01.cs.int>.
;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int <http://freeipa1.cs.int>.
This authority section looks suspicious, I would expect something like
0.0.10.in-addr.arpa.
Back to question about your reverse zones.
;; ADDITIONAL SECTION:
freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE rcvd: 124
Martin
Cheers!
M.
On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:
Hello all :)
On 20.12.2016 01:33, Maciej Drobniuch wrote:
Hi All!
I get the following message while adding a new hostname.
"The host was added but the DNS update failed with: DNS
reverse zone in-addr.arpa. for IP address 10.0.0.165 is not
managed by this server"
IPA failed to get correct reverse zone, can you try dig -x
10.0.0.165 what will be in SOA answer?
What is the name of reverse zone you have on IPA DNS server?
Martin
The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone
- all OK
While adding a new host, the A record is being created but
the PTR fails with the message above.
Reinstalling centos+IPA worked once but I had to reinstall
again because of problems with kerberos(probably dependencies).
Not sure what is the root cause of the issue.
VERSION: 4.4.0, API_VERSION: 2.213
CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar
6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
Any help appreciated!
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-sense LLC
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-sense LLC
--
Best regards
Maciej Drobniuch
Network Security Engineer
2410 Camino Ramon, Suite 129
San Ramon, CA 94583
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
