2:45 a.m.
Well, I found the problem. It was dnssec.
Turning it off in the named.conf solved the problem, and because IPA only
forwards two internal domains we don't actually need it.
Am Fr., 20. Nov. 2020 um 09:28 Uhr schrieb Alexander Bokovoy <
abokovoy(a)redhat.com>:
On pe, 20 marras 2020, Boris Behrens via FreeIPA-users wrote:
>Ok,
>the IPA ui tells me:
>DNS Server 10.0.0.205: query 'service.consul. SOA': The DNS response does
>not contain an answer to the question: service.consul. IN SOA.
>
>But the TCPdump tells me that it got answered:
>08:10:01.466563 IP (tos 0x0, ttl 64, id 36617, offset 0, flags [DF], proto
>UDP (17), length 63)
> 10.0.255.12.56423 > 10.0.0.205.53: [bad udp cksum 0x1416 -> 0x9fa4!]
>28861+ SOA? service.consul. (35)
>08:10:01.468357 IP (tos 0x0, ttl 63, id 32897, offset 0, flags [none],
>proto UDP (17), length 233)
> 10.0.0.205.53 > 10.0.255.12.56423: [udp sum ok] 28861* q: SOA?
>service.consul. 1/3/3 consul. SOA ns.consul. hostmaster.consul. 1605856201
>3600 600 86400 0 ns: consul. NS stack1.node.fra1.consul., consul. NS
>mgmt5.node.fra1.consul., consul. NS stack3.node.fra1.consul. ar:
>stack1.node.fra1.consul. A 10.0.240.11, mgmt5.node.fra1.consul. A
>10.0.0.205, stack3.node.fra1.consul. A 10.0.240.13 (205)
>
>Someone got an idea what I am missing?
You are missing SOA for service.consul. The DNS server answered with
information for consul., not service.consul.
Compare with this:
# dig -t soa ipa.test.
; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc32 <<>> -t soa ipa.test.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29443
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f9b1a2e9136aa9d0446585935fb77de17dea9e2618d645f3 (good)
;; QUESTION SECTION:
;ipa.test. IN SOA
;; ANSWER SECTION:
ipa.test. 86400 IN SOA master.ipa.test.
hostmaster.ipa.test. 1605454312 3600 900 1209600 3600
;; AUTHORITY SECTION:
ipa.test. 86400 IN NS master.ipa.test.
;; ADDITIONAL SECTION:
master.ipa.test. 1200 IN A 10.0.104.240
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Nov 20 08:27:13 UTC 2020
;; MSG SIZE rcvd: 149
You are getting response for your superior DNS domain, not the domain
you asked for.
>
>Am Do., 19. Nov. 2020 um 16:50 Uhr schrieb Boris Behrens <bb(a)kervyn.de>:
>
>> Hi,
>>
>> I have a very strange problem:
>>
>> I would like to add a CNAME to the IPA DNS server, that resolves to an
>> internal domain which is forwarded from our central DNSmasq to our
consul.
>>
>> I created a zone called test.boris and added a CNAME record
>> cname.test.boris IN CNAME cname.stage.consul.
>>
>> The DNSmasq config forwards consul to 10.1.2.3:8600.
>>
>> When I now query for the cname.test.boris. I get
>> cname.test.boris. in CNAME cname.stage.consul.
>> cname.stage.consul. NXDOMAIN.
>> After some debugging I came to the conclusion that the NXDOMAIN response
>> comes from freeIPA which tries to resolv this, but consul. is not in the
>> world wide root zone it does not work.
>>
>> Now I added a forward zone which tells IPA to forward this request back
to
>> DNSmasq.
>> In the TCP dump I can trace the package and I see that DNSmasq send the
>> correct address back to freeIPA which answers with an empty A record.
>>
>> What am I doing wrong?
>>
>> --
>> Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend
im
>> groüen Saal.
>>
>
>
>--
>Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im
>groüen Saal.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im
groüen Saal.