Just as there is a "default-less core" to Internet routing, there is
also a "forwarding-less core" to Internet DNS, and your nameservers --
congratulations -- are in that core. The queries you get from other
nameservers in the core are non-recursive, defined to mean "give me
whatever information you have, but don't ask anyone else about the
name". And your nameservers dutifully comply. Ergo, they don't forward.
As someone else pointed out, there could theoretically be (non-core)
resolvers out there configured to resolve directly from your box. But
for an authoritative nameserver on the Internet, this would be the
exception rather than the rule -- mostly your nameserver will be talking
to other nameservers, not to forwarding or stub resolvers.
If you have some devices that are capable of *proxying* DNS requests
between the internal box and the Internet, you could delegate the
subdomain to those devices. But a true, standards-complying nameserver
will never forward a non-recursive query. The absence of the RD
(recursion desired) flag on the query specifically told it that the
client didn't want that.
- Kevin
Wim Livens wrote:
I'm trying to delegate a subdomain to a server that is not directly
accessible from the internet, yet be able to resolve names in the
subdomain from the internet. I understood 'forwarding' would be the
solution but I can't get it to work completely:
I have on both ns1 and ns2 which are authoritive for company.com
(irrelevant parts ommited):
zone "company.com" {
type master;
}
zone "sub.company.com" {
type forward;
forwarders { 10.0.0.10; }; //devbox
};
options {
allow-recursion { any; }; //temporary, just to test
};
And the company.com zonefile:
NS ns1.company.com.
NS ns2.company.com.
sub NS devbox.company.com.
devbox.company.com A 10.0.0.10
devbox is an internal box running a specialized DNS server written in
Perl that answers:
stuff.sub.company.com. A X.X.X.X
sub.company.com. NS devbox.company.com.
ns1/ns2 are dual homed (internet/intranet). devbox is accessible from
ns1/ns2 but not from the internet.
Resolving from a client somewhere outside on the internet seems to work:
client:~$ dig stuff.sub.company.com a @ns1.company.com
;; ANSWER SECTION:
stuff.sub.company.com. 1M IN A X.X.X.X
;; AUTHORITY SECTION:
sub.company.com. 1H IN NS devbox.company.com.
;; ADDITIONAL SECTION:
devbox.company.com. 1H IN A 10.0.0.10
However:
client:~$ dig stuff.sub.company.com a
...times out
I tried from various known-to-work clients with various nameservers in
resolv.conf, none work except for ns1/ns2 itself.
Any ideas what I'm doing wrong ? How is it possible that a direct query
from anywhere in the world to ns1/ns2 works, but a caching/forwarder is
unable to resolve it ?
Thanks,
Wim.
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
