Bug 1056202
Summary: | [RFE] Support DNS root zone | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Chinmay Paradkar <cparadka> |
Component: | ipa | Assignee: | Martin Kosek <mkosek> |
Status: | CLOSED ERRATA | QA Contact: | Namita Soman <nsoman> |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | cparadka, dpal, jcholast, ldelouw, mkosek, pspacek, pviktori, pvoborni, rcritten, rmainz, rvdwees, vanhoof, xdong |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ipa-4.1.0-6.el7 | Doc Type: | Enhancement |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-03-05 10:10:14 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1064025, 1113520 |
Description
Chinmay Paradkar
2014-01-21 16:59:45 UTC
I see 2 ways to fix this request: 1) Fix ipa and bind-dyndb-ldap to allow LDAP definition if the root zone ".". Currently, when I created it in LDAP by bypassing IPA validation, bind-dyndb-ldap refused to serve it: # ipa dnszone-add test. --name-server=a --ip-address=198.41.0.4 --admin-email root.`hostname`. Zone name: test. Authoritative nameserver: a Administrator e-mail address: root.vm-236.example.com. SOA serial: 1390377720 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant EXAMPLE.COM krb5-self * A; grant EXAMPLE.COM krb5-self * AAAA; grant EXAMPLE.COM krb5-self * SSHFP; Active zone: TRUE Dynamic update: FALSE Allow query: any; Allow transfer: none; # ldapmodify -h `hostname` -Y GSSAPI -ZZ SASL/GSSAPI authentication started SASL username: admin.ENG.BRQ.REDHAT.COM SASL SSF: 56 SASL data security layer installed. dn: idnsname=test.,cn=dns,dc=example,dc=com changetype: modrdn newrdn: idnsname=. deleteoldrdn: 1 modifying rdn of entry "idnsname=test.,cn=dns,dc=example,dc=com" # ipa dnszone-show . Zone name: . Authoritative nameserver: a Administrator e-mail address: root.vm-236.example.com. SOA serial: 1390377724 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; # ipa dnsrecord-find . Record name: @ NS record: a Record name: _kerberos TXT record: EXAMPLE.COM Record name: a A record: 198.41.0.4 ---------------------------- Number of entries returned 3 ---------------------------- The LDAP entry looks correct, howerver bind-dyndb-ldap refused to load it: Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to DNS name: empty label Jan 22 09:05:57 vm-236.example.com named[21522]: update_record (psearch) failed, dn 'idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' change type 0x0. Records can be outdated, run `rndc reload`: empty label Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn idnsname=_kerberos,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to DNS name: empty label Jan 22 09:05:57 vm-236.example.com named[21522]: update_record (psearch) failed, dn 'idnsname=_kerberos,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com' change type 0x0. Records can be outdated, run `rndc reload`: empty label Petr, do you think this is something that could be fixed in bind-dyndb-ldap? As we discussed before, there should be theoretically no obstacle on defining a root zone in LDAP. Or would we need also need to have a new attribute for zone type which would be then set to "hint"? 2) Disable the root hint in local /etc/named.conf. However, when I commented following sections: #forward first; #forwarders { # 10.0.0.1; #}; ... #zone "." IN { # type hint; # file "named.ca"; #}; I still got the root hint when testing it: # dig -t ns . ... j.root-servers.net. 604705 IN A 192.58.128.30 j.root-servers.net. 604705 IN AAAA 2001:503:c27::2:30 e.root-servers.net. 604705 IN A 192.203.230.10 ... Is this something compiled in named/dig? (In reply to Martin Kosek from comment #2) > I see 2 ways to fix this request: > > 1) Fix ipa and bind-dyndb-ldap to allow LDAP definition if the root zone > ".". Currently, when I created it in LDAP by bypassing IPA validation, > bind-dyndb-ldap refused to serve it: [...] > The LDAP entry looks correct, howerver bind-dyndb-ldap refused to load it: > Jan 22 09:05:57 vm-236.example.com named[21522]: failed to convert dn > idnsname=a,idnsname=.,cn=dns,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com to > DNS name: empty label [...] > Petr, do you think this is something that could be fixed in bind-dyndb-ldap? Yes I do, we can hack it around if it's necessary. > As we discussed before, there should be theoretically no obstacle on > defining a root zone in LDAP. Or would we need also need to have a new > attribute for zone type which would be then set to "hint"? It depends on the requirements from the field. It is not possible to just 'disable' root hints. Some hints have to be always present so DNS resolver know where to start. We have two possibilities: 1) Add support for 'hint's in LDAP: In practice it means that user has to create 'master' root zone on some internal server and then add IP addresses of this internal server to LDAP. 2) Amend zone parser so it will accept root name and use 'master' zone in LDAP as root. This mitigates requirement for another server from variant (1). The difference between 'hint' and 'master' zones are described at: ftp://ftp.isc.org/isc/bind9/9.9.4/doc/arm/Bv9ARM.ch06.html#id2592749 Note that 'hint' is not a real zone: https://lists.isc.org/pipermail/bind-users/2006-January/061082.html > 2) Disable the root hint in local /etc/named.conf. However, when I commented > following sections: > > #forward first; > #forwarders { > # 10.0.0.1; > #}; > > ... > > #zone "." IN { > # type hint; > # file "named.ca"; > #}; Note that in any case we would comment out hints in named.conf. This file is parsed before bind-dyndb-ldap is loaded. > > I still got the root hint when testing it: > > # dig -t ns . > ... > j.root-servers.net. 604705 IN A 192.58.128.30 > j.root-servers.net. 604705 IN AAAA 2001:503:c27::2:30 > e.root-servers.net. 604705 IN A 192.203.230.10 > ... > > Is this something compiled in named/dig? Yes, root hints for 'IN' DNS class are compiled to named - DNS resolver can't work without them. I'm curious what is the solution in case with plain BIND? Can we reach the requestor and ask him? (In reply to Petr Spacek from comment #3) > (In reply to Martin Kosek from comment #2) ... > > As we discussed before, there should be theoretically no obstacle on > > defining a root zone in LDAP. Or would we need also need to have a new > > attribute for zone type which would be then set to "hint"? > It depends on the requirements from the field. It is not possible to just > 'disable' root hints. Some hints have to be always present so DNS resolver > know where to start. Can we override them? I.e. have a '.' zone in LDAP which would contain alternative root hints? BTW by "attribute in LDAP" in my answer above I meant an attribute to specify the zone type, i.e. something like "idnstype" supporting "master" or "hint" value. Does that make sense? > > We have two possibilities: > 1) Add support for 'hint's in LDAP: In practice it means that user has to > create 'master' root zone on some internal server and then add IP addresses > of this internal server to LDAP. How the DNS clients are then supposed to be configured? Given than root hints are being compiled in, they would not even ask their default resolver for it, right? > ... > I'm curious what is the solution in case with plain BIND? Can we reach the > requestor and ask him? Good question. Chinmay, can you please ask customer what was their configuration of BIND and host machines (i.e. DNS clients) to allow them disable or replace the default root zone hints? Understanding what worked for them before could give us some hint what exactly do they want. (In reply to Martin Kosek from comment #4) > (In reply to Petr Spacek from comment #3) > > (In reply to Martin Kosek from comment #2) > ... > > > As we discussed before, there should be theoretically no obstacle on > > > defining a root zone in LDAP. Or would we need also need to have a new > > > attribute for zone type which would be then set to "hint"? > > It depends on the requirements from the field. It is not possible to just > > 'disable' root hints. Some hints have to be always present so DNS resolver > > know where to start. > > Can we override them? I.e. have a '.' zone in LDAP which would contain > alternative root hints? Yes we can try it, that is what I proposed as variant (1) in comment #3. I'm not sure how to force BIND to ignore built-in hints, it will be a delicate operation. May be that root hints will always be loaded first and then replaced by hints from LDAP later. Should I dig into it right now? Anyway, after some thinking I propose to use 'master' root zone instead of 'hints' zone. Master root zone has to be somewhere in any case, so why not use IPA? I guess that internal wiring in BIND will be simpler in this case. > BTW by "attribute in LDAP" in my answer above I meant an attribute to > specify the zone type, i.e. something like "idnstype" supporting "master" or > "hint" value. Does that make sense? I would create new object class for hint zones because hints will have different set of allowed attribures. Another advantage would be that older versions of bind-dyndb-ldap would not be confused by 'hint' zones. Again, I propose normal 'master' zones instead of 'hint' zone. > > We have two possibilities: > > 1) Add support for 'hint's in LDAP: In practice it means that user has to > > create 'master' root zone on some internal server and then add IP addresses > > of this internal server to LDAP. > > How the DNS clients are then supposed to be configured? Given than root > hints are being compiled in, they would not even ask their default resolver > for it, right? Well, we have to distinguish so-called 'stub resolver' and 'recursive/full resolver'. These articles explain the difference quite nicely: http://www.zytrax.com/books/dns/apa/resolver.html https://lists.isc.org/pipermail/bind-users/2009-November/078203.html Usually, an application uses stub resolver on local machine. This stub resolver simply forwards the query to configured name server configured in /etc/resolv.conf. The name server runs recursive resolver (e.g. inside BIND or unbound process) and this *recursive resolver uses hints*. As a result, you have to configure hints "only" on all internal name servers. Normal clients will use whatever is configured on internal servers. > > ... > > I'm curious what is the solution in case with plain BIND? Can we reach the > > requestor and ask him? > > Good question. Chinmay, can you please ask customer what was their > configuration of BIND and host machines (i.e. DNS clients) to allow them > disable or replace the default root zone hints? Understanding what worked > for them before could give us some hint what exactly do they want. I'm wondering "what is the benefit"? Clients can't get any answer from Internet if they are in isolated environment so I don't see a real value in this exercise. It could be even useful to let original hints in place and log attempts to reach server Internet server on routers or something like that. That would uncover worms and some other suspicious activity in the internal network. Upstream ticket: https://fedorahosted.org/freeipa/ticket/4149 This is now implemented upstream by git commits bff6d68ac200ea1ab543b090ab2763e2437a48ce, 1c9b7ec800b0cbdba6032ec4fd1d41cff6ce5e6d Commits mentioned in Comment 14 are in bind-dyndb-ldap. FreeIPA part (https://fedorahosted.org/freeipa/ticket/4149), i.e. allowing "." DNS zone, is not completed yet. Moving back to ASSIGNED. I have modified bug title to reflect current implementation. It allows you to serve DNS root zone (".") from IPA server. It is not directly related to root "hints". bind-dyndb-ldap 5.2 fully supports root zone and all known bugs were fixed. upstream added webui and ipa command to disable root hints ipa-4-1: https://fedorahosted.org/freeipa/changeset/c32b89d892f11da1aa4cc3f5c340e78ab189d8fd https://fedorahosted.org/freeipa/changeset/72e0b339539a780d895ef1eddab1d84008c2708f https://fedorahosted.org/freeipa/changeset/18460d629bd26e5f32c19abebe20568f53b7b58e https://fedorahosted.org/freeipa/changeset/637a082713ec5002aae149d9e65368907367a3b6 https://fedorahosted.org/freeipa/changeset/bf61689069a5f6215063beec3fc91873e4b6e091 https://fedorahosted.org/freeipa/changeset/c675808c43adf5db8673258596f9b43a9a21ed07 https://fedorahosted.org/freeipa/changeset/b7e3a990369d85dfd12165891cf9142d669a0259 master: https://fedorahosted.org/freeipa/changeset/f846e0d1efa222181f79c930a73e4c9940141bef https://fedorahosted.org/freeipa/changeset/94743a3f2635a52ecb6d9628e6e330399a192fb8 https://fedorahosted.org/freeipa/changeset/7bc17bb8528f3dbeaf70822ee952e67bd7cf08f5 https://fedorahosted.org/freeipa/changeset/7e24e241ba18dddba6cc217b1108c4874647c8de https://fedorahosted.org/freeipa/changeset/239adf9de40748caa9e1522c9cd04aedd5516c75 https://fedorahosted.org/freeipa/changeset/23620a40255c8f3963ce8ca012c34f340b2f780b https://fedorahosted.org/freeipa/changeset/bc2eaa145637e1947449ee53548243ab22059805 dns help page fixed: master: https://fedorahosted.org/freeipa/changeset/3f8cfdab269490e4935db7d296c3fc7f2fa552f5 ipa-4-1: https://fedorahosted.org/freeipa/changeset/0f2eb65f008777ebdee9b35f5f69bada66066484 Upstream ticket: https://fedorahosted.org/freeipa/ticket/4573 == USE CASE & LIMITATION == This RFE allows an administrator to create and manage root zone "." on IdM Server. Any DNS queries sent to the IdM DNS server will then use this configured zone instead of the public one, as pointed to by default DNS root hints available in BIND package (/var/named/named.ca) or other DNS resolvers. This will make the new root zone effective on all IdM clients that use standard glibc DNS queries and that do not use own recursive resolver like BIND or unbound. Clients using own recursive resolver would need to have updated their root hints to point at IdM DNS servers to have the new root zone applied. upstream, Web UI added force option to skip DNS check while modifying idnssoamname attribute of dns zone and while adding new NS record: master: https://fedorahosted.org/freeipa/changeset/741c31c2b428cf979db6a9d7cd91f88e5f247fb4 ipa-4-1: https://fedorahosted.org/freeipa/changeset/502bf5671306b873c36e12bc88139bb5a42f8657 Regression caused by this RFE found, affects ipa-server-install and --zone-mgr option: https://fedorahosted.org/freeipa/ticket/4663 I will link this ticket to this bug. Moving to ASSIGNED until 4663 is fixed. 4663 fixed upstream master: https://fedorahosted.org/freeipa/changeset/e971fad5c1235bb755e58d131f8183f1646770e6 ipa-4-1: https://fedorahosted.org/freeipa/changeset/75cdc50ba91a94682eac11f99995746be283f668 Minor regression was found in the installation, see https://fedorahosted.org/freeipa/ticket/4707 Moving back to ASSIGNED. Fixed upstream master: https://fedorahosted.org/freeipa/changeset/a7162e7766150aa7577a42747a4d583a425f7271 ipa-4-1: https://fedorahosted.org/freeipa/changeset/3ab75d70412921bf2362edefd6c9411cff7df92d Steps to verify: - install IPA server - add DNS root zone "." to it - add NS records for existing zones to the root zone to configure proper delegation. E.g. if IPA server had zone example.net. configured prior adding the root zone then please run: $ ipa dnsrecord-add . example.net --ns-rec=name.of.the.ipa.server.test. (repeat this for all non-root zones) - add some other records to the root zone - verify that all records you added are visible and resolvable (including dig) Verified on ipa-server-4.1.0-15.el7.x86_64: [root@mgmt9 ~]# ipa dnszone-add . Zone name: . Active zone: TRUE Authoritative nameserver: mgmt9.testrelm.test. Administrator e-mail address: hostmaster SOA serial: 1422547064 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant TESTRELM.TEST krb5-self * A; grant TESTRELM.TEST krb5-self * AAAA; grant TESTRELM.TEST krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root@mgmt9 ~]# ipa dnszone-find Zone name: . Active zone: TRUE Authoritative nameserver: mgmt9.testrelm.test. Administrator e-mail address: hostmaster SOA serial: 1422553403 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; Zone name: 4.16.10.in-addr.arpa. Active zone: TRUE Authoritative nameserver: mgmt9.testrelm.test. Administrator e-mail address: hostmaster.testrelm.test. SOA serial: 1422549642 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; Zone name: testrelm.test. Active zone: TRUE Authoritative nameserver: mgmt9.testrelm.test. Administrator e-mail address: hostmaster.testrelm.test. SOA serial: 1422549642 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Allow query: any; Allow transfer: none; ---------------------------- Number of entries returned 3 ---------------------------- [root@mgmt9 ~]# ipa dnsrecord-add . testrelm.test --ns-rec=mgmt9.testrelm.test. Record name: testrelm.test NS record: mgmt9.testrelm.test. [root@mgmt9 ~]# ipa dnsrecord-add . 4.16.10.in-addr.arpa --ns-rec=mgmt9.testrelm.test. Record name: 4.16.10.in-addr.arpa NS record: mgmt9.testrelm.test. [root@mgmt9 ~]# ipa dnsrecord-add . test_txt_record --txt-rec=ABC Record name: test_txt_record TXT record: ABC [root@mgmt9 ~]# ipa dnsrecord-find . Record name: @ NS record: mgmt9.testrelm.test., cloud-qe-19.testrelm.test. Record name: 4.16.10.in-addr.arpa NS record: mgmt9.testrelm.test. Record name: testrelm.test NS record: mgmt9.testrelm.test. Record name: test_txt_record TXT record: ABC ---------------------------- Number of entries returned 4 ---------------------------- [root@mgmt9 ~]# dig -t ns 4.16.10.in-addr.arpa. |grep mgmt9.testrelm.test. 4.16.10.in-addr.arpa. 86400 IN NS mgmt9.testrelm.test. mgmt9.testrelm.test. 1200 IN A 10.16.4.19 [root@mgmt9 ~]# dig -t ns testrelm.test. |grep mgmt9.testrelm.test. testrelm.test. 86400 IN NS mgmt9.testrelm.test. mgmt9.testrelm.test. 1200 IN A 10.16.4.19 [root@mgmt9 ~]# dig -t txt test_txt_record. |grep ABC test_txt_record. 86400 IN TXT "ABC" Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0442.html |