Bug 784820 - Conditional forwarding does not work for sub-zones
Summary: Conditional forwarding does not work for sub-zones
Keywords:
Status: CLOSED DUPLICATE of bug 787526
Alias: None
Product: Fedora
Classification: Fedora
Component: bind-dyndb-ldap
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-26 11:03 UTC by Martin Kosek
Modified: 2013-04-30 23:50 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-09 14:52:13 UTC
Type: ---


Attachments (Terms of Use)

Description Martin Kosek 2012-01-26 11:03:07 UTC
Description of problem:
Conditional forwarding does not work when the forwarded zone is a sub-zone of another zone in LDAP.

My zones:

dn: idnsname=external.example.com,cn=dns,SUFFIX
idnsAllowDynUpdate: FALSE
idnsAllowQuery: any
idnsAllowTransfer: none
idnsForwarders: 10.16.78.142
idnsName: external.example.com
idnsSOAexpire: 1209600
idnsSOAmName: ns.exampe.com.
idnsSOAminimum: 3600
idnsSOArName: hostmaster.external.example.com.
idnsSOArefresh: 3600
idnsSOAretry: 900
idnsSOAserial: 2012260101
idnsZoneActive: TRUE
nSRecord: ns.exampe.com.
objectClass: top
objectClass: idnsrecord
objectClass: idnszone

dn: idnsname=example.com,cn=dns,SUFFIX
idnsAllowDynUpdate: FALSE
idnsAllowQuery: any
idnsAllowTransfer: none
idnsName: example.com
idnsSOAexpire: 1209600
idnsSOAmName: ns.exampe.com.
idnsSOAminimum: 3600
idnsSOArName: hostmaster.example.com.
idnsSOArefresh: 3600
idnsSOAretry: 900
idnsSOAserial: 2012260101
idnsZoneActive: TRUE
nSRecord: ns.exampe.com.
objectClass: top
objectClass: idnsrecord
objectClass: idnszone


Requests for zone external.example.com were not forwarded to the other DNS server but were answered (unsuccessfully) by DNS server with zone example.com

When I removed the zone example.com, the conditional forwarding worked.

Version-Release number of selected component (if applicable):
bind-9.8.1-4.P1.fc16.x86_64
bind-dyndb-ldap-1.0.0-0.2.b1.fc16.x86_64

How reproducible:

Steps to Reproduce:
1. Create a zone example.com and a sub-zone external.example.com
2. Set forwarders in idnsForwarders in external.example.com
3. Try to resolve external.example.com (dig -t soa external.example.com)
  
Actual results:
The request is not answered

Expected results:
The request is answered by configured forwarder.

Comment 1 Adam Tkac 2012-02-08 17:50:28 UTC
After inspection this is actually expected behavior.

When nameserver is authoritative for certain zone (example.com in this case) and you configure forwarding for it's subdomain and there is no delegation from domain to forwarded subdomain (i.e. there is no delegation example.com. -> external.example.com.) then named doesn't start forwarding and sends reply from it's authoritative zone database.

To explain it more straightforward, authoritative data is always preferred over recursion (forwarding is specific kind of recursion). So if authoritative zone example.com. says there is no external.example.com. domain (even when you configured forwarding for it), named responds with NXDOMAIN.

When you configure zones this way then situation is different:

- authoritative zone "example.com"
- delegation to "forward.example.com" from "example.com" (you can point to nonexistant server)
- forward zone "sub.forward.example.com"

then forwarding for "sub.forward.example.com" should work because based on example.com authoritative zone, this domain might exist. Note this scenario currently doesn't work as well due to bug #787526. I'm leaving this bug opened to retest that second scenario really works when bug #787526 gets fixed.

Comment 2 Adam Tkac 2012-02-09 14:52:13 UTC
As I expected forwarding for subdomains didn't work due to bug #787526. Closing as duplicate.

*** This bug has been marked as a duplicate of bug 787526 ***


Note You need to log in before you can comment on or make changes to this bug.