a month ago - last edited a month ago
I'm writing to you because I made an import via the tool diw from Bind.
Everything is fine except that I have errors concerning the glue record PTRs that are used for NS.
For example, I have the following thing:
test2.zone.com IN A 172.24.80.10
test.zone.com IN NS test2.zone.com
In the INFOBLOX it creates me with the import tool (in the reverse zones):
- a PTR with 172.24.80.10: 172.24.80.10 (which is very strange by the way)
- a HOST with test2.zone.com: 172.24.80.10
That's why when I make an nslookup of 172.24.80.10, I get 2 results whereas I should have only one (the HOST)
So I would just delete this PTR, except that it is in SYSTEM - Auto-created by Add Zone therefore impossible
Any Ideas ?
a month ago
Ideally, going by just the example provided by you, it would not create dual PTR records for the same IP. It should only have one set of Glue record (A and PTR) for the NS. As a workaround, you can try disabling the "Create Hosts" check box from the Advanced tab in DIW tool to prevent the Hosts records from being created.
However, I would recommend creating a Ticket with Infoblox Support to check if duplicates are being created due to a misconfiguration and achieve an better solution.
a month ago
I think the Host is correct, but I have a PTR that refers to itself and that's very strange and not correct. And I do not think the system really uses it.
I would like to know how to delete it? In addition to this PTR and HOST, I have a NS record and a forward zone :
- test.zone2.com NS 172.24.80.10 (which is also SYSTEM - Auto-created by Add Zone)
- Forward zone test.zone.com : Forwarder : 172.24.80.10.
Thank you in advance !
a month ago
Any object that shows as auto-created is there because of another configuration that requires it. These can be a little tricky to narrow down because you could see these auto-created records for a number of different configurations, such as:
- Any name server assigned to a zone.
- Any forwarder for a forwarding zone.
- Any Grid member.
- Managed (Microsoft) servers.
You might be able to narrow down what is triggering this record by using the global search feature. If you look at the top right-hand corner of your GUI, you should see a magnifying glass. In the Search window, switch to the Advanced tab and type the name for the PTR record (not the IP address) and leave the filter at "Type equals All". In the results, look for any type that does not match up with an A or PTR record and this should hopefully narrow down a property or zone configuration that is triggering this.
If nothing stands out, there is a scenario where database for older versions of NIOS was not always updated correctly for auto-generated records and they can become 'orphaned'. To rule this out, you can try the following command:
To validate auto-generated records:
set dns-auto-gen check
To validate and fix auto-generated records:
set dns-auto-gen renew
These commands, by default, will page through a limited number of zones at a time. If you have a large number of zones, this can be a bit unwieldy. I would recommend that you enable logging in your SSH window and change the page size to make this a bit easier. You could even set the page size to 0 so that it can run through all zones without requiring any intervention.
If you are still stuck, I would recommend consulting with Infoblox Support and they can help with anyanalysis that you require.