RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 869323 - It is not possible to disable forwarding on per-zone basics
Summary: It is not possible to disable forwarding on per-zone basics
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: bind-dyndb-ldap
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Adam Tkac
QA Contact: Namita Soman
URL:
Whiteboard:
Depends On: 869658
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-23 15:17 UTC by Petr Spacek
Modified: 2013-04-30 23:52 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Disable forwading on per-zone basics Reason: Some setups require to disable forwading per-zone. For example company servers are configured as authoritative for non-public zone and have global forwarding turned on. When the non-public zone contains delegation for non-public subdomain, the zone must have explicitly disable forwarding otherwise the glue won't be returned. Result (if any): Server can return delegation glue for private zones when global forwarding is turned on.
Clone Of:
Environment:
Last Closed: 2013-02-21 08:58:30 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0359 0 normal SHIPPED_LIVE bind-dyndb-ldap bug fix and enhancement update 2013-02-20 20:53:11 UTC

Description Petr Spacek 2012-10-23 15:17:56 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/bind-dyndb-ldap/ticket/98

It is necessary in cases where:
* global forwarder is defined
* IPA serves 'parent' zone, e.g. 'test.'
* delegation records (e.g. A+NS) are present for subordinate zone, e.g. 'sub.test.'

In that case BIND will forward all queries for 'sub.test.'. This will break DNS if global forwarder don't know zone 'sub.test.'.

It is usual situation - global forwarder is caching DNS server from ISP but 'sub.test.' is some internal name.
Comment 1 Namita Soman 2012-10-24 12:27:59 UTC 
steps to reproduce are available in ticket
Comment 6 Michael Gregg 2013-01-22 23:18:02 UTC 
I verified this using a per zone forwarder instead of a global forwarder, but, apparently it's all the same code. 

Verified against ipa-server-3.0.0-9.el6.x86_64

The IP address of zippyvm11 is 10.14.5.226
The IP address of zippyvm4 is 10.14.5.136

[root@zippyvm4 ~]# ipa dnszone-add example.com --name-server=zippyvm4.testrelm.com. --admin-email=hostmaster.example.com.
  Zone name: example.com
  Authoritative nameserver: zippyvm4.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358895286
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM
                      krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;


[root@zippyvm4 ~]#  ipa dnsrecord-add example.com ns.sub --a-rec=10.14.5.226
  Record name: ns.sub
  A record: 10.14.5.226

[root@zippyvm4 ~]# ipa dnsrecord-add example.com sub --ns-rec=ns.sub.example.com.
  Record name: sub
  NS record: ns.sub.example.com.

[root@zippyvm4 ~]# ipa dnszone-mod --forwarder=10.14.5.226 example.com
  Zone name: example.com
  Authoritative nameserver: zippyvm4.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358895375
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
  Zone forwarders: 10.14.5.226

[root@zippyvm11 ~]# ipa dnszone-add sub.example.com --name-server zippyvm11.testrelm.com.
Administrator e-mail address [hostmaster.sub.example.com.]: 
  Zone name: sub.example.com
  Authoritative nameserver: zippyvm11.testrelm.com.
  Administrator e-mail address: hostmaster.sub.example.com.
  SOA serial: 1358896319
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

[root@zippyvm11 ~]# ipa dnsrecord-add sub.example.com client --a-rec 10.14.5.226
  Record name: client
  A record: 10.14.5.226

[root@zippyvm4 ~]# dig client.sub.example.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> client.sub.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40603
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;client.sub.example.com.		IN	A

;; ANSWER SECTION:
client.sub.example.com.	86400	IN	A	10.14.5.226

;; AUTHORITY SECTION:
sub.example.com.	86400	IN	NS	zippyvm11.testrelm.com.

;; ADDITIONAL SECTION:
zippyvm11.testrelm.com.	1200	IN	A	10.14.5.226

;; Query time: 15 msec
;; SERVER: 10.14.5.136#53(10.14.5.136)
;; WHEN: Tue Jan 22 18:14:48 2013
;; MSG SIZE  rcvd: 105

[root@zippyvm4 ~]# ipa dnszone-mod example.com --forwarder=
  Zone name: example.com
  Authoritative nameserver: zippyvm4.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358896093
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
[root@zippyvm4 ~]# dig client.sub.example.com

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> client.sub.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19492
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;client.sub.example.com.		IN	A

;; Query time: 93 msec
;; SERVER: 10.14.5.136#53(10.14.5.136)
;; WHEN: Tue Jan 22 18:15:26 2013
;; MSG SIZE  rcvd: 40


I do seem to be able to remove the per-zone forwarder.
Comment 7 Petr Spacek 2013-01-23 09:04:35 UTC 
(In reply to comment #6)
> I verified this using a per zone forwarder instead of a global forwarder,
> but, apparently it's all the same code.
Sorry, there are fundamental differences between global and per-zone forwarders and thus test you did is invalid. This difference should be clearer in next version of bind-dyndb-ldap, per-zone forwarders will be separated from normal zones completely.

Server with zone "example.com" (i.e. "zippyvm4") has to have global forwarder set - you can pick any other server which doesn't know about zones "example.com." and "sub.example.com.". DNS server assigned by DHCP could be good enough. Do not set any IP addresses for per-zone forwarders.

Zones and records are created properly except forwarding setting, so this part can be reused.

When asking "zippyvm4" directly with global forwarder enabled:
- Resolution of "example.com" should succeed.
- Resolution of "sub.example.com" should fail because requests are forwarded to global forwarder - and the global forwarder doesn't know about zone sub.example.com.

Second step is about changing forward policy in zone "example.com", *not globally*:
- Add forward policy "none" to zone "example.com".
- Resolution of "sub.example.com" should succeed if forward policy is "none" *in the zone "example.com"*.
Comment 8 Michael Gregg 2013-01-24 01:55:49 UTC 
New attempt. I think I have gone through the verification steps this time.

I guess I'll leave the bug status "on_qa" until I get confirmation of the verification.
:

<Add a global forwarder that does not know about iexample.com or sub.iexample.com>

[root@zippyvm11 ~]# ipa  dnsconfig-mod --forwarder=10.14.63.12
  Global forwarders: 10.14.63.12

<add iexample.com to zippyvm11>
[root@zippyvm11 ~]# ipa dnszone-add iexample.com --name-server=zippyvm11.testrelm.com. --admin-email=hostmaster.example.com.
  Zone name: iexample.com
  Authoritative nameserver: zippyvm11.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358990481
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

<Ensure that resolution of sub.iexample.com fails and make sure iexample.com succeeds.>

[root@zippyvm11 ~]# dig sub.iexample.com SOA +multiline @127.0.0.1
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> sub.iexample.com SOA +multiline @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 15130
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;sub.iexample.com.	IN SOA
;; AUTHORITY SECTION:
iexample.com.		0 IN SOA zippyvm11.testrelm.com. hostmaster.example.com. (
				1358990482 ; serial
				3600       ; refresh (1 hour)
				900        ; retry (15 minutes)
				1209600    ; expire (2 weeks)
				3600       ; minimum (1 hour)
				)
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 23 20:23:43 2013
;; MSG SIZE  rcvd: 108

[root@zippyvm11 ~]# dig iexample.com SOA +multiline @127.0.0.1
;; ANSWER SECTION:
iexample.com.		86400 IN SOA zippyvm11.testrelm.com. hostmaster.example.com. (
				1358990482 ; serial
				3600       ; refresh (1 hour)
				900        ; retry (15 minutes)
				1209600    ; expire (2 weeks)
				3600       ; minimum (1 hour)
				)
;; AUTHORITY SECTION:
iexample.com.		86400 IN NS zippyvm11.testrelm.com.

< Good, now ensure the forwarding section for iexample.com is none> 
[root@zippyvm11 ~]# ipa dnszone-mod --forwarder='' iexample.com


<Now I have followed the replication steps, but I am pretty sure I have not verified the bug yet, as I haven't disables any per-zone forward. The global forwarder doesn't know about sub.iexample.com, and the forwarder section for iexample.com is set to none. Where is the forwarder to the server that does know about sub.iexample.com. The replication steps seem incomplete.>
<What I think needs to happen is that a new zone (iexample.com)needs to be forwarded to server2. This will make sub.iexample.com resolve on server1. Then, 'NONE' needs to be written into the forwarder section for the sub domain iexample.com on server1. This should disable forwarding for that zone (similar to the ticket description) and break resolution for sub.iexample.com> 

<Like this:>
[root@zippyvm11 ~]# ipa dnszone-mod --forwarder='10.14.5.136' iexample.com
  Zone name: iexample.com
  Authoritative nameserver: zippyvm11.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358991998
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
  Zone forwarders: 10.14.5.136
[root@zippyvm11 ~]# dig client.sub.iexample.com @127.0.0.1
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> client.sub.iexample.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25927
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;client.sub.iexample.com.	IN	A
;; ANSWER SECTION:
client.sub.iexample.com. 86400	IN	A	10.14.5.226
;; AUTHORITY SECTION:
sub.iexample.com.	86400	IN	NS	zippyvm4.testrelm.com.
;; ADDITIONAL SECTION:
zippyvm4.testrelm.com.	1200	IN	A	10.14.5.136


< Now, disable forwarding for iexample.com on zippyvm11.>

[root@zippyvm11 ~]# ipa dnszone-mod --forwarder='' iexample.com
  Zone name: iexample.com
  Authoritative nameserver: zippyvm11.testrelm.com.
  Administrator e-mail address: hostmaster.example.com.
  SOA serial: 1358991998
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;

<This does disable forwarding on a per zone basis, entries in sub.iexample.com no longer work, and it doesn't>

[root@zippyvm11 ~]# dig client.sub.iexample.com @127.0.0.1

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> client.sub.iexample.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6477
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;client.sub.iexample.com.	IN	A

;; AUTHORITY SECTION:
iexample.com.		3600	IN	SOA	zippyvm11.testrelm.com. hostmaster.example.com. 1358992261 3600 900 1209600 3600

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 23 20:51:41 2013
;; MSG SIZE  rcvd: 115
Comment 9 Petr Spacek 2013-01-24 14:32:49 UTC 
Forwarders are very confusing. I will try to explain how it should work without and then with forwarders:

A) Normal DNS delegation is done via NS+A/AAAA record pair.
There is nice article about DNS delegation on Zytrax's site: http://www.zytrax.com/books/dns/ch9/delegate.html

I would recommend to examine how normal delegation works in real DNS. Following command will print all steps done during resolution of name "www.iana.org". These steps start from the root of the DNS tree "" (sometimes denoted as ".") to the last "www" component of the name:
$ dig +trace +all +comments +nodnssec www.iana.org

You will see several queries on the way from DNS root "." to "www.iana.org". Please examine "question" section: All queries except the last one are for "NS" record, i.e. resolver is looking for the name server responsible for zone containing name "www.iana.org". Each reply with NS record contains also so called "glue record", i.e. IP address of name server.
E.g. 
;; QUESTION SECTION:
;.				IN	NS
;;;;;;;;;;;; Following NS record creates "delegation" to (potentially another) name server.
;;;;;;;;;;;; Note: It would be impossible to contact server "c.root-servers.net." if glue record wasn't preset!
;; AUTHORITY SECTION:
.			518400	IN	NS	c.root-servers.net.
;; ADDITIONAL SECTION:
;;;;;;;;;;;; following record is so called "glue" record
c.root-servers.net.	6	IN	A	192.33.4.12

Note: List of root servers (serving root zone ".") is well known, so each resolver knows where it should start with the resolution process.



How to configure two zones on different servers and delegete sub-zone to another server (without any forwarding):
E.g. we want to create zone "iexample.test" on server named "zippyvm11.fqdn." and zone "sub.iexample.test" on server "zippyvm4.fqdn.".

There is an important detail in the example above: Name servers *do not* belong to the zones they serve (names "zippyvm11.fqdn." and "zippyvm4.fqdn." are not part of zones "iexample.test" and "sub.iexample.test"). This detail allows you to create zones without adding so called "glue" A/AAAA records to the zones, see the Zytrax article (above) for details.

# Create empty zone on "iexample.test"
[zippyvm11]$ ipa dnszone-add "iexample.test" --name-server="zippyvm11.fqdn." --admin-email="hostmaster.zippyvm11.fqdn."

# Add some TXT record for test purposes
[zippyvm11]$ ipa dnsrecord-add "iexample.test" testrec --txt-data="record from zippyvm11"


# Jump to zippyvm4 and create new zone "sub.iexample.test"
[zippyvm4]$ ipa dnszone-add "sub.iexample.test" --name-server="zippyvm4.fqdn." --admin-email="hostmaster.zippyvm4.fqdn."

# Add some other TXT record for test purposes
[zippyvm4]$ ipa dnsrecord-add "sub.iexample.test" testrec --txt-data="record from zippyvm4"


# Now "delegate" sub-domain from zippyvm11 to zippyvm4. Delegation is done by creating a NS record.
# Note: Parent zone "iexample.test" has to contain exactly same NS (and potentially also glue) records as sub-zone "sub.iexample.test". This has to be done manually.
[zippyvm11]$ ipa dnsrecord-add "iexample.test" sub --ns-hostname="zippyvm4.fqdn."


# Now you should be able to resolve records from all zones via zippyvm11.
# Note: All forwarding has to be disabled! (Including global forwarders set by IPA installation in /etc/named.conf.)
[zippyvm11]$ dig -t ANY testrec.iexample.test
[zippyvm11]$ dig -t ANY testrec.sub.iexample.test

# Important note: In lab environment you will not be able to resolve records from parent zone "iexample.test" from "second level" name server "zippyvm4". In this particular case it is expected, because there is no top-level zone "test", so it is impossible to find delegation from root zone "." to "test". As a result there is no path between root "." and zone "iexample.test", so resolution is impossible. This problem should never happen in public Internet.


Before I start with forwarders I have to explain how delegation works from name server's point of view.

E.g.:
1) Client asked server "zippyvm11" for record "testrec.sub.iexample.test".
2) Server found deepest *local zone* matching the requested name, i.e. "iexample.test".
3) Now the server looks for the requested name in current zone ("iexample.test"). Search goes from right side of the name to the left side, label by label.
4) In our case server found matching name "sub.iexample.test".
5) Found name contains NS record - delegation point was found!
6) Server stops *local* search process in current zone and constructs a request to server specified by found NS record.
7) Request is sent to the name server specified by NS record. Process I'm describing starts again from point (1) on this particular server.
8) Received reply (from a subordinate server) is returned back to the client.

Note: Any records "under" delegation point "sub.iexample.test" on server hosting "iexample.test" will be hidden - that is expected behaviour. E.g. theoretical record "testrec2.sub.iexample.test" created on server "zippyvm11" will not be resolvable at all, because delegation point is always found sooner than local record "testrec2".



B) Per-zone (conditional) forwarding
IPA tools are very confusing in this aspect. There is no real "zone" (i.e. database) for per-zone forwarders. "Per-zone forwarder" is a name for rule "Forward received queries for names *belonging to this domain* to <this configured> server blindly. Relay all obtained replies back to the client."

AFAIK this behaviour is not covered by any real standard. I described how it works in BIND 9, other name server can implement other behaviour.

E.g. we have zone "iexample.test" (including the delegation as described in example A above) and "per-zone forwarder" for domain "fwd.test.":
a) Any query for names in domain "fwd.test." are blindly forwarded to server specified by configuration.
b) Any query for names in domain "iexample.test" are processed without any change, as described in example A above.



C) Global forwarders
Global forwarders behave differently from per-zone forwarders. Also, global forwarders affect all zones, not only subset of zones on the server.

By setting of global forwarders on the name server you say "this name server is not allowed to communicate with any other servers except global forwarders specified <here>".

This is very significant difference from per-zone forwarding. With global forwarders configured, *all* queries are sent to global forwarders, including *queries caused by delegation to another servers*.

Back to the example above:
1) Client sent query for name "testrec.sub.iexample.test" to "zippyvm11" and global forwarder is configured on "zippyvm11".
2) Server "zippyvm11" found delegation point for "sub.iexample.test" as described above.
3) Server "zippyvm11" is forbidden to communicate directly with subordinate server "zippyvm4", so "zippyvm11" is forced to send the query to configured global forwarder.
4) Global forwarder e.g. doesn't know how to reach zone "sub.iexample.test" and returns and error.
5) Error is returned to the client - resolution failed because of improperly configured global forwarder.

This bugzilla entry is about overriding global forwarders on per-zone basics. Forward policy "none" disables forwarding for particular zone.

E.g. forward policy "none" was configured for zone "iexample.test" on server "zippyvm11". In this situation all delegation points *inside this zone* are processed in the same way as in example A above, i.e. in the same way as without any forwarder configured.


Makes it sense? Is it understandable? Please give me feedback. I will try to create some wiki page with all the information above.


And now back to the test ... Necessary steps are:
1) Configure two zones on two different servers as described above in example A.
2) Configure sub-zone delegation between servers as described above in example A.
3) At this point - test records from both zones (iexample.test and sub.iexample.test) should be resolvable when you are asking the parent server ("zippyvm11").
4) Configure some global forwarder on parent server "zippyvm11". Global forwarder has to be some server which doesn't know about zones "iexample.test" and "sub.iexample.test". DNS server assigned from DHCP in lab could be ok.
5) At this point - test records from parent zone "iexample.test" should be resolvable. Records from zone "sub.iexample.test" should be non-resolvable. (Again asking only the "parent" server "zippyvm11".)
6) Configure forward policy "none" for zone "iexample.test" on server "zippyvm11".
7) At this point - resolution results have to be same as in step (3).
Comment 11 Michael Gregg 2013-01-28 22:07:15 UTC 
Thanks for the explanation Peter, though, I still seem to be having problems. 

I am following your suggested steps, but the ns entry for iexample.test doesn't seem to be working. 

[root@zippyvm11 ~]# ipa dnszone-add "iexample.test" --name-server="zippyvm11.testrelm.com." --admin-email="hostmaster.zippyvm11.fqdn."
  Zone name: iexample.test
  Authoritative nameserver: zippyvm11.testrelm.com.
  Administrator e-mail address: hostmaster.zippyvm11.fqdn.
  SOA serial: 1359409537
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;
[root@zippyvm11 ~]# ipa dnsrecord-add "iexample.test" testrec --txt-data="record from zippyvm11"
  Record name: testrec
  TXT record: record from zippyvm11

to zippyvm4

[root@zippyvm4 ~]# ipa dnszone-add "sub.iexample.test" --name-server="zippyvm4.testrelm.com." --admin-email="hostmaster.zippyvm4.fqdn."
  Zone name: sub.iexample.test
  Authoritative nameserver: zippyvm4.testrelm.com.
  Administrator e-mail address: hostmaster.zippyvm4.fqdn.
  SOA serial: 1359409639
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM krb5-self * AAAA; grant TESTRELM.COM
                      krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;
[root@zippyvm4 ~]# ipa dnsrecord-add "sub.iexample.test" testrec --txt-data="record from zippyvm4"
  Record name: testrec
  TXT record: record from zippyvm4

on zippyvm11

[root@zippyvm11 ~]# ipa dnsrecord-add "iexample.test" sub --ns-hostname="zippyvm4.testrelm.com."
  Record name: sub
  NS record: zippyvm4.testrelm.com.

I am still unable to resolve testrec.sub.iexample.test

It appears that the NS entry doesn't seem to be populating. As on zippyvm11 dig is reporting that the nameserver for iexample.test is zippyvm11, despite the addition of the NS entry here:
[root@zippyvm11 ~]# ipa dnsrecord-find "iexample.test" sub 
  Record name: sub
  NS record: zippyvm4.testrelm.com.
----------------------------
Number of entries returned 1
----------------------------


The dig query of iexample.test:

[root@zippyvm11 ~]# dig -t ANY iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> -t ANY iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44345
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;iexample.test.			IN	ANY
;; ANSWER SECTION:
iexample.test.		86400	IN	SOA	zippyvm11.testrelm.com. hostmaster.zippyvm11.fqdn. 1359409890 3600 900 1209600 3600
iexample.test.		86400	IN	NS	zippyvm11.testrelm.com.
;; ADDITIONAL SECTION:
zippyvm11.testrelm.com.	1200	IN	A	10.14.5.226
;; Query time: 1 msec
;; SERVER: 10.14.5.226#53(10.14.5.226)
;; WHEN: Mon Jan 28 17:03:21 2013
;; MSG SIZE  rcvd: 144


I would expect the NS of iexample.test to be zippyvm4.testrelm.com.

Sorry for the problems.
Comment 13 Petr Spacek 2013-01-29 09:43:43 UTC 
I don't see any problem in dig outputs in comment #11, the problem could be hidden somewhere. Please add whole output from:

[zippyvm11]# dig -t ANY testrec.sub.iexample.test

There is an potential pitfall:
All names contained in NS records have to have proper A/AAAA records somewhere (it is related to glue records as I mentioned in comment #9). Delegating server (zippyvm11) has to be able to resolve NS name to valid IP address.

Please check that "zippyvm4.testrelm.com." and "zippyvm11.testrelm.com." are resolvable to valid IP address when asking server "zippyvm11".

Zone delegation will not work if NS name->IP address resolution is not possible. In that case /var/log/messages should contain some error messages about invalid NS records/missing A/AAAA records. Error messages should pop-up when adding or changing a zone without valid NS/A/AAAA/SOA records, nothing is logged when clients only asks for records.

It is necessary to provide valid A/AAAA records for both names to ensure proper name->IP resolution (when asking zippyvm11). The zone "testrelm.com" is present on server "zippyvm11", right? In that case zone "testrelm.com" should contain A records for "zippyvm11" and "zippyvm4".


Note about NS records and dig results: NS records declare "who is responsible for the answer in ANSWER section".

I.e.
[root@zippyvm11 ~]# dig -t ANY iexample.test
contains correct NS record:
iexample.test.		86400	IN	NS	zippyvm11.testrelm.com.

This is correct, because you created zone "iexample.test" on server "zippyvm11.testrelm.com.", i.e. this server is authoritative for this zone.

The situation with "sub.iexample.com" is similar - you delegated the authority (responsibility) to server "zippyvm4.testrelm.com.", so NS record should look like:
sub.iexample.test.		86400	IN	NS	zippyvm4.testrelm.com.
(even when asking zippyvm11)

Server zippyvm11 says "I'm not responsible for this sub-domain, authoritative data are provided by server zippyvm4.testrelm.com."


ADDITIONAL section should contain NS name->IP address translation, i.e. A/AAAA records necessary for reaching sub-ordinate servers.
Comment 14 Michael Gregg 2013-01-29 21:47:34 UTC 
The dig you asked for returns no useful looking output.

[root@zippyvm11 ~]# dig -t ANY testrec.sub.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> -t ANY testrec.sub.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;testrec.sub.iexample.test.	IN	ANY

;; Query time: 212 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 29 16:44:13 2013
;; MSG SIZE  rcvd: 43


I suspect the problem comes down to the fact that there exists a NS record for IPA in the sub domain, here:
[root@zippyvm11 ~]# ipa dnsrecord-find "iexample.test" sub
  Record name: sub
  NS record: zippyvm4.testrelm.com.
----------------------------
Number of entries returned 1
----------------------------


But that nameserver doesn't come up on a dig:
[root@zippyvm11 ~]# dig -t SOA +multiline sub.iexample.test
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> -t SOA +multiline sub.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40266
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;sub.iexample.test.	IN SOA
;; Query time: 145 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 29 16:45:58 2013
;; MSG SIZE  rcvd: 35

zippyvm4.testrelm.com is resolvable on zippyvm11

[root@zippyvm11 ~]# dig zippyvm4.testrelm.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.16.rc1.el6 <<>> zippyvm4.testrelm.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58167
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;zippyvm4.testrelm.com.		IN	A
;; ANSWER SECTION:
zippyvm4.testrelm.com.	86400	IN	A	10.14.5.136
;; AUTHORITY SECTION:
testrelm.com.		86400	IN	NS	zippyvm11.testrelm.com.
testrelm.com.		86400	IN	NS	zippyvm1.testrelm.com.
;; ADDITIONAL SECTION:
zippyvm11.testrelm.com.	1200	IN	A	10.14.5.226
zippyvm1.testrelm.com.	1200	IN	A	10.14.5.133
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 29 16:46:36 2013
;; MSG SIZE  rcvd: 134

So, I am having problems enabling per zone forwarding as per your instructions.
Comment 15 Namita Soman 2013-01-30 05:56:58 UTC 
I realize - this bz is going too long with all the test run data pasted here.... 

I tried the below:
machines:
cloud-qe-12.testrelm.com
cloud-qe-4.testrelm.com

on cloud-qe-12.testrelm.com:
# ipa dnszone-add "iexample.test" --name-server="cloud-qe-12.testrelm.com." --admin-email="hostmaster.testrelm.com."
  Zone name: iexample.test
  Authoritative nameserver: cloud-qe-12.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1359521112
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM
                      krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

# ipa dnsrecord-add "iexample.test" testrec --txt-data="record from cloud-qe-12"
  Record name: testrec
  TXT record: record from cloud-qe-12

on cloud-qe-4.testrelm.com:
# ipa dnszone-add "sub.iexample.test" --name-server="cloud-qe-4.testrelm.com." --admin-email="hostmaster.cloud-qe-4.testrelm.com."
  Zone name: sub.iexample.test
  Authoritative nameserver: cloud-qe-4.testrelm.com.
  Administrator e-mail address: hostmaster.cloud-qe-4.testrelm.com.
  SOA serial: 1359523370
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  BIND update policy: grant TESTRELM.COM krb5-self * A; grant TESTRELM.COM
                      krb5-self * AAAA; grant TESTRELM.COM krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

# ipa dnsrecord-add "sub.iexample.test" testrec --txt-data="record from cloud-qe-4"
  Record name: testrec
  TXT record: record from cloud-qe-4

on cloud-qe-12.testrelm.com:
# ipa dnsrecord-add "iexample.test" sub --ns-hostname="cloud-qe-4.testrelm.com."
ipa: ERROR: Nameserver 'cloud-qe-4.testrelm.com.' does not have a corresponding A/AAAA record

# ipa host-add cloud-qe-4.sub.testrelm.com --ip-address=10.16.96.111 
ipa: ERROR: DNS zone sub.testrelm.com not found

# ipa host-add cloud-qe-4.testrelm.com --ip-address=10.16.96.111 
------------------------------------
Added host "cloud-qe-4.testrelm.com"
------------------------------------
  Host name: cloud-qe-4.testrelm.com
  Principal name: host/cloud-qe-4.testrelm.com
  Password: False
  Keytab: False
  Managed by: cloud-qe-4.testrelm.com

# ipa dnsrecord-add "iexample.test" sub --ns-hostname="cloud-qe-4.testrelm.com."
  Record name: sub
  NS record: cloud-qe-4.testrelm.com.

# vim /etc/named.conf
commented forwarder ip in:
  forwarders {
                10.14.63.12;
        };

# service named restart
Stopping named: .[  OK  ]
Starting named: [  OK  ]

# dig -t ANY testrec.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45305
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;testrec.iexample.test.		IN	ANY

;; ANSWER SECTION:
testrec.iexample.test.	86400	IN	TXT	"record" "from" "cloud-qe-12"

;; AUTHORITY SECTION:
iexample.test.		86400	IN	NS	cloud-qe-12.testrelm.com.

;; ADDITIONAL SECTION:
cloud-qe-12.testrelm.com. 1200	IN	A	10.16.96.103

;; Query time: 0 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 00:52:22 2013
;; MSG SIZE  rcvd: 129


# dig -t ANY testrec.sub.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.sub.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51424
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;testrec.sub.iexample.test.	IN	ANY

;; ANSWER SECTION:
testrec.sub.iexample.test. 86400 IN	TXT	"record" "from" "cloud-qe-4"

;; AUTHORITY SECTION:
sub.iexample.test.	86400	IN	NS	cloud-qe-4.testrelm.com.

;; ADDITIONAL SECTION:
cloud-qe-4.testrelm.com. 86400	IN	A	10.16.96.111

;; Query time: 2 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 00:52:17 2013
;; MSG SIZE  rcvd: 131



Looks good to me...but Petr...thoughts?
Comment 16 Petr Spacek 2013-01-30 09:53:32 UTC 
Namita, it seems good up to now, but next steps are required:
(In reply to comment #9)
> And now back to the test ... Necessary steps are:
> 1) Configure two zones on two different servers as described above in
> example A.
> 2) Configure sub-zone delegation between servers as described above in
> example A.
> 3) At this point - test records from both zones (iexample.test and
> sub.iexample.test) should be resolvable when you are asking the parent
> server ("zippyvm11").
<<<--- you stopped here, please proceed with next steps:

> 4) Configure some global forwarder on parent server "zippyvm11". Global
> forwarder has to be some server which doesn't know about zones
> "iexample.test" and "sub.iexample.test". DNS server assigned from DHCP in
> lab could be ok.
(In worst case you can use some nonexistent global forwarder, e.g. "documentation IP" 192.0.2.1.)
> 
> 5) At this point - test records from parent zone "iexample.test" should be
> resolvable. Records from zone "sub.iexample.test" should be non-resolvable.
> (Again asking only the "parent" server "zippyvm11".)
> 
> 6) Configure forward policy "none" for zone "iexample.test" on server
> "zippyvm11".
> 
> 7) At this point - resolution results have to be same as in step (3).

Greg, I really don't know what is wrong in your configuration, sorry. Ping me, I can investigate it directly on the machines.
Comment 17 Petr Spacek 2013-01-30 11:58:11 UTC 
Greg, I finally found the cause of problems you encountered:

(In reply to comment #9)
> And now back to the test ... Necessary steps are:
> 1) Configure two zones on two different servers as described above in
> example A.
> 2) Configure sub-zone delegation between servers as described above in
> example A.
> 3) At this point - test records from both zones (iexample.test and
> sub.iexample.test) should be resolvable when you are asking the parent
> server ("zippyvm11").
<<<--- This verification step failed, because you had global forwarder set at this point.
Global forwarding should be disabled at this moment and should be enabled in next step (4).

# following (strange :-) command will delete all global forwarders from LDAP
$ ipa dnsconfig-mod --forwarder=
# also check /etc/named.conf and comment all IP addresses in "forwarders" section out

> 4) Configure some global forwarder on parent server "zippyvm11". Global
> forwarder has to be some server which doesn't know about zones
> "iexample.test" and "sub.iexample.test". DNS server assigned from DHCP in
> lab could be ok.
> 
> 5) At this point - test records from parent zone "iexample.test" should be
> resolvable. Records from zone "sub.iexample.test" should be non-resolvable.
> (Again asking only the "parent" server "zippyvm11".)
<<<--- At this point you should see the same problem (intentionally created) as you encountered in step (3): sub.iexample.test is not resolvable but iexample.test is resolvable.
This is caused by forwarding mechanism as described in comment #9: Query for "sub.iexample.test" is forwarded to global forwarder which doesn't know about this domain, so global forwarder returns NXDOMAIN and the same reply is relayed to the client (dig).

> 6) Configure forward policy "none" for zone "iexample.test" on server
> "zippyvm11".
$ ipa dnszone-mod --forward-policy=none iexample.test

> 7) At this point - resolution results have to be same as in step (3).
Comment 19 Namita Soman 2013-01-30 13:24:51 UTC 
So moving on....

# vim /etc/named.conf 
uncommented the ip, so forwrader section is:
 forwarders {
                10.14.63.12;
        };


# service named restart
Stopping named: .[  OK  ]
Starting named: [  OK  ]

# dig -t ANY testrec.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51850
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;testrec.iexample.test.		IN	ANY

;; ANSWER SECTION:
testrec.iexample.test.	86400	IN	TXT	"record" "from" "cloud-qe-12"

;; AUTHORITY SECTION:
iexample.test.		86400	IN	NS	cloud-qe-12.testrelm.com.

;; ADDITIONAL SECTION:
cloud-qe-12.testrelm.com. 1200	IN	A	10.16.96.103

;; Query time: 0 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 08:17:27 2013
;; MSG SIZE  rcvd: 129



# dig -t ANY testrec.sub.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.sub.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25512
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;testrec.sub.iexample.test.	IN	ANY

;; Query time: 222 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 08:17:37 2013
;; MSG SIZE  rcvd: 43


Verified: test records from parent zone "iexample.test" should be resolvable. Records from zone "sub.iexample.test" should be non-resolvable.


# ipa dnszone-mod --forward-policy=none iexample.test
  Zone name: iexample.test
  Authoritative nameserver: cloud-qe-12.testrelm.com.
  Administrator e-mail address: hostmaster.testrelm.com.
  SOA serial: 1359551820
  SOA refresh: 3600
  SOA retry: 900
  SOA expire: 1209600
  SOA minimum: 3600
  Active zone: TRUE
  Allow query: any;
  Allow transfer: none;
  Forward policy: none


# dig -t ANY testrec.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52989
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;testrec.iexample.test.		IN	ANY

;; ANSWER SECTION:
testrec.iexample.test.	86400	IN	TXT	"record" "from" "cloud-qe-12"

;; AUTHORITY SECTION:
iexample.test.		86400	IN	NS	cloud-qe-12.testrelm.com.

;; ADDITIONAL SECTION:
cloud-qe-12.testrelm.com. 1200	IN	A	10.16.96.103

;; Query time: 0 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 08:19:50 2013
;; MSG SIZE  rcvd: 129



# dig -t ANY testrec.sub.iexample.test

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6 <<>> -t ANY testrec.sub.iexample.test
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26039
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;testrec.sub.iexample.test.	IN	ANY

;; ANSWER SECTION:
testrec.sub.iexample.test. 86400 IN	TXT	"record" "from" "cloud-qe-4"

;; AUTHORITY SECTION:
sub.iexample.test.	86400	IN	NS	cloud-qe-4.testrelm.com.

;; ADDITIONAL SECTION:
cloud-qe-4.testrelm.com. 86400	IN	A	10.16.96.111

;; Query time: 2 msec
;; SERVER: 10.16.96.103#53(10.16.96.103)
;; WHEN: Wed Jan 30 08:19:58 2013
;; MSG SIZE  rcvd: 131


Verified: resolution results have to be same as in step (3).
Comment 20 Namita Soman 2013-01-30 13:35:08 UTC 
Petr took a look...marking verified

verified using:
ipa-server-3.0.0-24.el6.x86_64
bind-dyndb-ldap-2.3-2.el6.x86_64
Comment 22 errata-xmlrpc 2013-02-21 08:58:30 UTC 
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.

http://rhn.redhat.com/errata/RHBA-2013-0359.html
Note You need to log in before you can comment on or make changes to this bug.