Our current implementation has multiple dots(.) names in the hostname ,details mentioned below & we're using below setting while configuring the IPA/Redhat IDM server with integrated DNS.
Hostname : testing-infra-01-dal1.testing.stg.avtar.local realm_name: avtar.local domain_name: avtar.local
Once the setup completes ., we're getting below error . We're suspecting its related to multiple dots in the hostname. Considering the fact we cannot rename these hostname , please suggest how to resolve it . Is there a possibility to resolve it or we have to install/configure BIND DNS separately.
Does this error really prevents us from registering other machines within our environment having similar multi dot pattern in hostnames ? +++++++++++++++++++++ ipapython.dnsutil: DEBUG The DNS query name does not exist: testing-infra-01-dal1.testing.stg.avtar.local. ipaserver.dns_data_management: ERROR unable to resolve host name testing-infra-01-dal1.testing.stg.avtar.local. to IP address, ipa-ca DNS record will be incomplete ++++++++++++++++++++
Did you select mDNS’s TLD .local on purpose? Or was this an inheritance.
On 3 Mar 2019, at 14:49, Vivek Aggarwal via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Our current implementation has multiple dots(.) names in the hostname ,details mentioned below & we're using below setting while configuring the IPA/Redhat IDM server with integrated DNS.
Hostname : testing-infra-01-dal1.testing.stg.avtar.local realm_name: avtar.local domain_name: avtar.local
Once the setup completes ., we're getting below error . We're suspecting its related to multiple dots in the hostname. Considering the fact we cannot rename these hostname , please suggest how to resolve it . Is there a possibility to resolve it or we have to install/configure BIND DNS separately.
Does this error really prevents us from registering other machines within our environment having similar multi dot pattern in hostnames ? +++++++++++++++++++++ ipapython.dnsutil: DEBUG The DNS query name does not exist: testing-infra-01-dal1.testing.stg.avtar.local. ipaserver.dns_data_management: ERROR unable to resolve host name testing-infra-01-dal1.testing.stg.avtar.local. to IP address, ipa-ca DNS record will be incomplete ++++++++++++++++++++ _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Yes its inheritance & it was done on purpose to generate TLS certificates as per hostnames.
Hence kindly suggest how to configure IPA to accommodate this mDNS’s TLD.
In that case I don’t know how to help (but someone else might). As per https://tools.ietf.org/html/rfc6762 .local isn’t supposed to be used the way you are using it at this time, and it will conflict with pretty much any standard system. I don’t know how to patch/override that without breaking a whole lot of other systems.
On 3 Mar 2019, at 17:43, Vivek Aggarwal via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Yes its inheritance & it was done on purpose to generate TLS certificates as per hostnames.
Hence kindly suggest how to configure IPA to accommodate this mDNS’s TLD. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Thanks John,
It would be nice if you can elaborate bit more & share your advise on:-
i) Whats wrong in the current hostname convention as still i dont have clear understanding what is that which is causing a problem in the current setup? .. any links/thoughts which can explain this will be of great help .
ii) Is ".local" is a problem or can i use any other TLD like ".int" ?
iii) Thirdly what is the recommendation for naming Hostname FQDN , does it shouldnot have multiple sub domains ??
Please bear with my questions in case these look bit naive. Thanks a lot for sparing time in answering my concerns.
Your specific issue might not be because the .local TLD, but .local is a special ‘reserved’ name for multicast DNS. You can use any other (including fake) TLD that is not registered. There are some other TLDs that are ’special’, like the one used for reverse-IP records in APIPA. Best to avoid such things as not all network software takes care of those special names the way they should.
Some hosts might treat .local special and ignore DNS servers or DNS query responses that are not from mDNS. Some hosts might first query DNS and then mDNS, some might do it the other way around. Some systems disable mDNS or .local mDNS if a static .local zone is detected which breaks Bonjour and ZeroConf in most configurations.
In my experience, mixing mDNS and DNS by introducing a .local is just going to create more problems.
I would suggest registering a DNS name but not using it externally, just internally. For example, you could take something like my-internal-domain.net http://my-internal-domain.net/ but simply not host anything externally and remove all records, maybe even disable name servers. There probably are better conventions for this, but using a ‘real’ (but dead to the outside) has served me well.
Multiple subdomains shouldn’t be a problem, but there probably are limits to the depth of subzones. For my setups, I usually don’t go deeper than 2 levels, i.e. sub1.sub0.ipa.net http://sub1.sub0.ipa.net/. I do tend to make dedicated subzones with NS delegations when I go deeper than 1 level, but in theory, if you only have 1 sublevel, you can leave it as-is and IPA will register your hosts with a dot in the name in the record effectively creating a virtual subzone. There is nothing bad about that, but depending on the management functionaliteit you are trying to create your needs may call for a different setup.
One of the important parts of domain naming isn’t as much about IPA’s idea on domains, but very much depends on how kerberos likes names. So if you can’t provide a strong enough guideline in the IPA community or documentation, try the ones for Kerberos (which IPA uses): https://web.mit.edu/kerberos/krb5-1.12/doc/admin/realm_config.html https://web.mit.edu/kerberos/krb5-1.12/doc/admin/realm_config.html The same can be (partially) said about Microsof’s AD naming suggestions, as their system also depends on correct naming, uses Kerberos and uses SRV records to find the correct servers for services: https://social.technet.microsoft.com/wiki/contents/articles/34981.active-dir... https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx
One of the quotes from the above sources:
In the past, lots of people chose to use a dummy, unofficial TLD (top-level-domain) for their internal network, like domain.lan, domain.local of domain.internal (and also domain.internalhost)
But this can get you in serious trouble. Because these names are not supported by internet standards, the most important RFC on this is: RFC 2606 http://tools.ietf.org/html/rfc2606 (http://tools.ietf.org/html/rfc2606%C2%A0%C2%A0 http://tools.ietf.org/html/rfc2606 ) This RFC standard is very explicit on choosing domain names for private testing and documentation
Other sources condense the suggestions into:
Option 1: Use a valid TLD (Top Level Domain, also known as routable domain) registered to your company. Some examples of this are company.ca or company.com; Option 2: Use a subdomain of a valid TLD that is registered to your company Option 3: Use non-TLD name (or non-routable domain). (But not an RFC reserved name!)
John
On 3 Mar 2019, at 19:08, Vivek Aggarwal via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Thanks John,
It would be nice if you can elaborate bit more & share your advise on:-
i) Whats wrong in the current hostname convention as still i dont have clear understanding what is that which is causing a problem in the current setup? .. any links/thoughts which can explain this will be of great help .
ii) Is ".local" is a problem or can i use any other TLD like ".int" ?
iii) Thirdly what is the recommendation for naming Hostname FQDN , does it shouldnot have multiple sub domains ??
Please bear with my questions in case these look bit naive. Thanks a lot for sparing time in answering my concerns. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Thanks John , its means a lot of help.
Just out of curiosity , how you're able to search & share the specific RFC so quickly, is this something i also should also follow in terms of referring RFC docs to get clarity ?
Is there any RFC's website/links which you can share & will be of help for me as well , any guidance on this as well be appreciated ..
just learning ... many thanks.
btw, i've created a new machine with following settings , by abandoning the ".local" TLD
Hostname : testing-infra-01-dal1.testing.stg.avtar.test realm_name: avtar.test domain_name: avtar.test
But still getting the same error as below +++++++++++++++++++++++++++++++ ipapython.dnsutil: ERROR DNS query for testing-infra-01-dal13.testing.stg.avtar.test.1 failed: All nameservers failed to answer the query testing-infra-01-dal13.testing.stg.avtar.test. IN A: Server 127.0.0.1 UDP port 53 answered SERVFAIL ipaserver.dns_data_management: ERROR unable to resolve host name testing-infra-01-dal13.testing.stg.avtar.test. to IP address, ipa-ca DNS record will be incomplete ++++++++++++++++++++++++++++++++++++
And The entry in resolv.conf is as below search avtar.test nameserver 127.0.0.1 +++++++++++++++++++++++++++++++ But if i give "testing.stg.avtar.test" as my domain & realm name then things just work fine without any errors. Any comments on this behaviour , why is it working in this case??
On su, 03 maalis 2019, Vivek Aggarwal via FreeIPA-users wrote:
btw, i've created a new machine with following settings , by abandoning the ".local" TLD
Hostname : testing-infra-01-dal1.testing.stg.avtar.test realm_name: avtar.test domain_name: avtar.test
But still getting the same error as below +++++++++++++++++++++++++++++++ ipapython.dnsutil: ERROR DNS query for testing-infra-01-dal13.testing.stg.avtar.test.1 failed: All nameservers failed to answer the query testing-infra-01-dal13.testing.stg.avtar.test. IN A: Server 127.0.0.1 UDP port 53 answered SERVFAIL ipaserver.dns_data_management: ERROR unable to resolve host name testing-infra-01-dal13.testing.stg.avtar.test. to IP address, ipa-ca DNS record will be incomplete ++++++++++++++++++++++++++++++++++++
And The entry in resolv.conf is as below search avtar.test nameserver 127.0.0.1 +++++++++++++++++++++++++++++++ But if i give "testing.stg.avtar.test" as my domain & realm name then things just work fine without any errors. Any comments on this behaviour , why is it working in this case??
The installer is not accounting for such configurations and for a good reason. First, if your primary domain and realm avtar.test, .stg.avtar.test and .testing.stg.avtar.test are two DNS zones nested within avtar.test. For a DNS zone you need to properly set it up within the parent domain. There are no such things like multi-dot host names inside a DNS domain zone. See RFC1034 section 3.5:
---- The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less. ----
Second, for integrated DNS it is IPA master that you are deploying right now which is authoritative for avtar.test. It doesn't know anything about any child DNS zone in avtar.test at the time of deployment because by definition the zone is being created at this point and is empty.
You may create an IPA master outside the primary domain, if the DNS zone for that master's hostname is handled by something else resolvable at the moment of deployment via DNS (not /etc/hosts).
I'd suggest you to set up an IPA master in avtar.test. Then you can create .stg.avtar.test and .staging.stg.avtar.test zones. Finally, deploy a replica in .staging.stg.avtar.test.
If you need different environments for avtar.test and stg.avtar.test (looks like stg is staging deployment?), I'd suggest to deploy stg.avtar.test as the main staging environment separately from avtar.test. You can make sure avtar.test properly delegates .stg.avtar.test to your staging environment
See also DNS autodiscovery section in ipa-client-install manual page.
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Thanks Alexander for such a nice explanation.
I've a follow-up thing to ask , i understood your point that if i'm using primary domain and realm as "avtar.test" then .stg.avtar.test and .testing.stg.avtar.test are two DNS zones nested within avtar.test. and the integrated DNS in IPA master doesnt know anything about the sub-domains hence it is unable to resolve hostname "testing-infra-01-dal13.testing.stg.avtar.test"
But if i install Bind DNS server separately and configure "zone" as below well in this case BIND server is able to provide resolution for server "testing-infra-01-dal13.testing.stg.avtar.test" as its configured as "A record" in "/etc/bind/avtar.test" file. Please help in understand this variation in behaviour of Bind Server VS IDM integrated DNS. I mean is it something that BIND server can do resolution of its child domains implicitly whereas that is something not supported by IDM integrated DNS . Why there is not need in BIND server to configure sub domains of "avtar.test" domain. Kindly help. +++++++++++++++++++++++++++++ zone "avtar.test" IN { type master; file "/etc/bind/avtar.test"; }; +++++++++++++++++++++++++++++
On ma, 04 maalis 2019, Vivek Aggarwal via FreeIPA-users wrote:
Thanks Alexander for such a nice explanation.
I've a follow-up thing to ask , i understood your point that if i'm using primary domain and realm as "avtar.test" then .stg.avtar.test and .testing.stg.avtar.test are two DNS zones nested within avtar.test. and the integrated DNS in IPA master doesnt know anything about the sub-domains hence it is unable to resolve hostname "testing-infra-01-dal13.testing.stg.avtar.test"
But if i install Bind DNS server separately and configure "zone" as below well in this case BIND server is able to provide resolution for server "testing-infra-01-dal13.testing.stg.avtar.test" as its configured as "A record" in "/etc/bind/avtar.test" file.
It doesn't matter who provides these zones. When you deploy IPA master with integrated DNS, the record (and a DNS zone it should be in) does not exist yet, thus installer failing to find it and thus failing. You cannot create the zone and the record in the installer because we have no idea at this point what creating this DNS zone means and how it should be done. We only can do that for the immediate DNS zone we are installing.
Please help in understand this variation in behaviour of Bind Server VS IDM integrated DNS. I mean is it something that BIND server can do resolution of its child domains implicitly whereas that is something not supported by IDM integrated DNS . Why there is not need in BIND server to configure sub domains of "avtar.test" domain. Kindly help.
As I said, this is not about capability of an integrated DNS. It is about *availability* of the zones in question at the time of deployment.
If you make that zone available at the time of deployment by means of a separate DNS server, that's fine. You are, however, then will not be using integrated DNS.
You can always add more IPA masters after you created initial deployment -- if you'd configure additional DNS zones after the initial deployment and then add a replica in .testing.stg.avtar.test, that will be fine, regardless whether you are installing with integrated DNS or not.
Thanks you Alexander.
Since you represent Redhat team , i couldnt resist myself from asking below two questions as well . it would be great if you can provide guidance/suggestion on these too
1) We've a cloud environment , where updating resolv.conf file for accommodating our IDM DNS server entry is not recommended , though i've come across forums where people talk about applying the "chattr" command which will make resolv.conf as readonly but i refrain from doing that ,as its not a wise thing to do in cloud env. Hence as per your experience please share what should be our approach for configuring Redhat IDM DNS without changing the cloud provided resolv.conf .
2) I've gone through the docs for integrated Vault as part of IDM solution but didnt find enough detail like how under the hood data is getting stored securely in vault , how the security of secrets/data handled within vault provided by IDM . And is it recommended to use the integrated IDM vault for production grade env , i mean is it safe to do that ? please suggest
On to, 07 maalis 2019, Vivek Aggarwal via FreeIPA-users wrote:
Thanks you Alexander.
Since you represent Redhat team , i couldnt resist myself from asking below two questions as well . it would be great if you can provide guidance/suggestion on these too
- We've a cloud environment , where updating resolv.conf file for
accommodating our IDM DNS server entry is not recommended , though i've come across forums where people talk about applying the "chattr" command which will make resolv.conf as readonly but i refrain from doing that ,as its not a wise thing to do in cloud env. Hence as per your experience please share what should be our approach for configuring Redhat IDM DNS without changing the cloud provided resolv.conf .
All you need to do is to follow normal DNS zone deployment recommendations. In other words, you should be using a DNS zone that is delegated to you, it needs to be resolvable via upstream DNS servers your cloud provider maintains and so on. There is nothing specific on IPA side around it at all.
- I've gone through the docs for integrated Vault as part of IDM
solution but didnt find enough detail like how under the hood data is getting stored securely in vault , how the security of secrets/data handled within vault provided by IDM . And is it recommended to use the integrated IDM vault for production grade env , i mean is it safe to do that ? please suggest
The vault is stored in KRA facility of the Dogtag CA. See documentation about that in RHCS product documentation: https://access.redhat.com/documentation/en-us/red_hat_certificate_system/9/h...
ok thanks but we're kind of new to DNS zone deployment . Though i will search on google but thought of getting any direct pointers from your end that how to configure/setup
Many thanks for responding & helping us...it means a lot.
Hi Vivek,
On Fri, Mar 8, 2019 at 9:09 AM Vivek Aggarwal via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
ok thanks but we're kind of new to DNS zone deployment . Though i will search on google but thought of getting any direct pointers from your end that how to configure/setup
There is the upstream documentation page at: https://www.freeipa.org/page/Deployment_Recommendations
Please also see the caveats listed at: https://www.freeipa.org/page/DNS#Caveats
Regards, François
Many thanks for responding & helping us...it means a lot. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
François Cami -
John Keates -
Vivek Aggarwal