Great, you are welcome :)
On 27.12.2016 13:41, Maciej Drobniuch wrote:
Martin,
Your troubleshooting style put me on the right track.
The alternative DNS servers had Ipv6 AAAA records that did not resolv
properly.
After deleting those records adding A records (with reverse PTR check)
and adding host works fine. The PTR record is created in the GUI and
works fine.
Thank you very much for your time and help with this!
Cheers!
M.
On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch
<m...@collective-sense.com <mailto:m...@collective-sense.com>> wrote:
# dig soa 0.0.10.in-addr.arpa.
; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3,
ADDITIONAL: 8
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INSOA
;; ANSWER SECTION:
0.0.10.in-addr.arpa.86400INSOAfreeipa1.cs.int
<http://freeipa1.cs.int>. hostmaster.cs.int
<http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600
;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int <http://freeipa1.cs.int>.
0.0.10.in-addr.arpa.86400INNSfreeipa2.cs.int <http://freeipa2.cs.int>.
0.0.10.in-addr.arpa.86400INNSkrkfreeipa.cs.int
<http://krkfreeipa.cs.int>.
;; ADDITIONAL SECTION:
freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200
freeipa2.cs.int <http://freeipa2.cs.int>.1200INA10.0.1.200
krkfreeipa.cs.int <http://krkfreeipa.cs.int>.1200INA10.0.2.6
;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: wto gru 27 07:33:41 EST 2016
;; MSG SIZE rcvd: 333
On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:
I just noticed previously you sent wrong dig, I need
dig 0.0.10.in-addr.arpa. SOA instead of the A rtype
On 27.12.2016 13:21, Maciej Drobniuch wrote:
# python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print
a.rrset.name <http://a.rrset.name>'
0.0.10.in-addr.arpa.
On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:
On 27.12.2016 13:04, Maciej Drobniuch wrote:
$ dig 0.0.10.in-addr.arpa
; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY:
1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA
;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int
<http://freeipa1.cs.int>. hostmaster.cs.int
<http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600
;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE rcvd: 111
Hmm, this query doesn't contain ANSWER section, that may
be reason why python-dns failed.
could you check with:
python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN");
print a.rrset.name <http://a.rrset.name>'
On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:
On 27.12.2016 12:07, Maciej Drobniuch wrote:
Hi Martin!
Thank you for your time!
On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:
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?
I have the reverse zone added.
0.0.10.in-addr.arpa.
Do you know maybe how python/ipa is determining
what's the dns server for the internal zone?
As far I understood this is not a "access rights
issue". It's a DNS PTR resolution problem with
python(ipa's using python) ?
It doesn't care about resolver, python-dns is
checking SOA records, it removes labels from left
and tries to find best match zone
what returns dig 0.0.10.in-addr.arpa. SOA ?
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.
I've intentionally hid our internal ip space,
sorry, good catch my finger has slipped :).
So is the 0.0.10.in-addr.arpa. an authoritative
zone? Or what dig returned in authority section.
;; 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
Happy new year!
--
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
Collective-Sense,LLC
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
--
Best regards
Maciej Drobniuch
Network Security Engineer
Collective-Sense,LLC
--
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
