Project

General

Profile

Actions

Bug #2668

open

Foreman appears to be incorrectly checking the local resolvers rather than SOA

Added by Jon Fautley almost 11 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
DNS
Target version:
-
Difficulty:
trivial
Triaged:
Fixed in Releases:
Found in Releases:

Description

It would appear that Foreman is checking the existence of DNS records (A/PTR, for provisioning) by querying the resolvers configured on the local system, rather than those configured in the managed zone's SOA.

This is irrespective of the setting of query_local_nameservers.


Related issues 2 (1 open1 closed)

Related to Foreman - Bug #13696: Rebuild Config deletes PTR records but does not add themNewActions
Has duplicate Foreman - Bug #3526: reverse_dns_record_attrs definition is missing the :resolver attributeDuplicate10/26/2013Actions
Actions #1

Updated by Dominic Cleal almost 11 years ago

  • Assignee deleted (Dominic Cleal)

It looks like this is specifically on PTR records, the original error was: "Failed to save: Conflict DNS PTR Records 123.12.123.1/<old.hostname> already exists"

I see app/models/orchestration/dns.rb queries the domain model for its SOA nameservers and gets a new DNS resolver with these configured, but doesn't do the equivalent for the subnet and reverse DNS zone.

Actions #2

Updated by Dominic Cleal over 10 years ago

  • Has duplicate Bug #3526: reverse_dns_record_attrs definition is missing the :resolver attribute added
Actions #3

Updated by Dominic Cleal about 8 years ago

  • Related to Bug #13696: Rebuild Config deletes PTR records but does not add them added
Actions #4

Updated by Simon Wydooghe almost 8 years ago

I can confirm this issue. I've got a dnsmasq server as my 'main' DNS, which Foreman uses. The Foreman host has a BIND server which only serves the domains managed by Foreman. The dnsmasq server forwards any requests to these domains to the BIND server. Caching on the dnsmasq server caused Foreman to believe there were conflicting PTR records. Turning off the caching on the dnsmasq server resolved the issue.

Actions #5

Updated by Ewoud Kohl van Wijngaarden about 7 years ago

  • Description updated (diff)

I wonder why the Foreman is doing a DNS request at all. I thought the Proxy did this so it shouldn't be needed. This also requires that the foreman has an entire view of the system and while that's generally what you want with DNS, there are situations where firewalls can be in the way.

Actions #6

Updated by Zdenek Janda over 6 years ago

  • Priority changed from Normal to Urgent
  • Difficulty set to trivial

I did hit into this now as well, this feature should be turned off entirely, or atleast add configuration possiblity to turn this off. Imagine this situation, you have in DNS *.example.com, which is CNAME to host1.example.com A 191.168.0.1. Now you want to create host2.example.com with 191.168.0.2, but bum, Conflict IPv4 DNS record because it did resolve host1.example.com A 191.168.0.1. And this is happening even when foreman has DNS proxy set for this subnet - instead doing it via proxy (which would work), it uses local resolver and everything is broken. I even added codewrap around that creates correct A record before foreman host is created, but this fails too, as it takes some time to DNS refresh so foreman can resolve it good, which again was workarounded by some sleep() but this all is just not right.

Actions #7

Updated by Marek Hulán over 6 years ago

  • Priority changed from Urgent to Normal

Thanks for your comment, I'm afraid this does not qualify to Urgent Priority, so resetting it back.

Actions

Also available in: Atom PDF