Re: Allowing resolution of off-server CNAMEs
On Fri, Jul 08, 2011 at 10:26:16AM -0700, Chris Buxton wrote: On Jul 8, 2011, at 9:11 AM, Joseph S D Yao wrote: I'd rather that recursion controls only control recursion. And not forwarding - have separate forwarding controls, says I. Forwarding is a response to a recursive query. For an iterative query, even if you have recursion enabled, the server won't forward the query. Therefore, it is logical that it be controlled with the same settings as recursion. What problem are you trying to solve? A dangling CNAME such as you describe is a normal behavior that caching resolvers are easily able to follow. Thanks to those who responded. The real problem is not with sub.tld.example, but with otherzone.faraway.example which works most of the time in most of the world. When it fails, people do an MSW 'nslookup' targeted at my system, and see nothing until I have described to them several times how to get a CNAME record with MSW 'nslookup' and what it means. Yes, not as secure. But less time explaining why. And I realize I have gotten sloppy about the difference between recursive and iterative - bad me! -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Allowing resolution of off-server CNAMEs
On 7/8/2011 12:11 PM, Joseph S D Yao wrote:
It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere. IMHBUCO.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone tld.example {
type master;
file data/zone.tld.example;
};
};
zone.tld.example:
$TTL3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
target CNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record. Of course, I
says to myself, it is trying to do recursion, which is not allowed. I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation. I added to the view:
zone sub.tld.example {
type forward;
forward only;
forwarders { ns1.sub's IP; ns2.sub's IP; };
};
Still not working. Unless I allow recursion! Which is SUPPOSED to be
an entirely etc.
Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?
Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*) I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
Joe,
Look at how RFC 1034 distinguishes recursive from iterative:
- In any system that has a distributed database, a particular name
server may be presented with a query that can only be answered by
some other server. The two general approaches to dealing with this
problem are recursive, in which the first server pursues the query
for the client at another server, and iterative, in which the
server refers the client to another server and lets the client
pursue the query.
I think it's pretty clear that what BIND calls forwarding is just a
subset of what the standards consider recursive resolution, and the
distinction you're trying to make between forwarding and recursion
isn't sanctioned by the standards. Moreover, in terms of bits and bytes,
a forwarded query *is* recursive (it has the RD set).
Maybe you need to ask yourself why you want to run a non-authoritative
nameserver in the first place (?) Are you following best practices for
purposes of security? Well, if you selectively poke forwarding holes
in that non-authoritative wall, then you're deviating from the best
practices and compromising your security. Think about it: when you
forward, you're trusting your forwarders (usually either by IP address
or TSIG key), validating their responses (hopefully there's enough
randomness to prevent a Kaminsky-style attack), populating a cache, etc.
All the things that have led to security issues in the past. It's
exactly those things which led to the authoritative-only best practice
in the first place -- it simplifies the interaction, reduces the number
of moving parts, and thus prevents all sorts of issues. I don't think
you want to be in the position of creating a *false*, Potemkin-Village
sense of security by claiming outwardly to be authoritative-only, yet
all the while engaging in questionable forwarding practices behind the
proverbial facade. Authoritative-only means authoritative-only: no
recursive resolution allowed, not even on the back-end and/or going by a
different name (forwarding).
- Kevin
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Allowing resolution of off-server CNAMEs
On 07/08/2011 05:11 PM, Joseph S D Yao wrote: It should be possible to set up an authoritative-only name server so that it does not recurse for anyone [except perhaps itself], but still allow someone to get a full resolution of a name whose canonical name is elsewhere. IMHBUCO. Why? The recursive resolver that is querying the authoritative will follow the CNAME anyway, since you're not authoritative for it. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Allowing resolution of off-server CNAMEs
It should be possible to set up an authoritative-only name server so
that it does not recurse for anyone [except perhaps itself], but still
allow someone to get a full resolution of a name whose canonical name is
elsewhere. IMHBUCO.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone tld.example {
type master;
file data/zone.tld.example;
};
};
zone.tld.example:
$TTL3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
target CNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record. Of course, I
says to myself, it is trying to do recursion, which is not allowed. I
will fix it so that it does not have to do recursion, but to do
forwarding, which is an entirely completely and totally different
operation. I added to the view:
zone sub.tld.example {
type forward;
forward only;
forwarders { ns1.sub's IP; ns2.sub's IP; };
};
Still not working. Unless I allow recursion! Which is SUPPOSED to be
an entirely etc.
Any ideas how to have a conceptually correct non-recursive authoritative
name server but still allow it to serve the A records?
Yes, I could have a slaved copy of the zone, but the master copy of the
zone is on an appliance, and one support person was horrified that I
used the GUI they supplied to do something else that BIND can do but
that is not part of the specific value-added software they supply.
(*sigh*) I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
--
/*\
**
** Joe Yao j...@tux.org - Joseph S. D. Yao
**
\*/
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Allowing resolution of off-server CNAMEs
On Jul 8, 2011, at 9:11 AM, Joseph S D Yao wrote:
I'd rather that recursion controls only control recursion.
And not forwarding - have separate forwarding controls, says I.
Forwarding is a response to a recursive query. For an iterative query, even if
you have recursion enabled, the server won't forward the query. Therefore, it
is logical that it be controlled with the same settings as recursion.
What problem are you trying to solve? A dangling CNAME such as you describe is
a normal behavior that caching resolvers are easily able to follow.
I started with this:
view all {
match-clients { any; };
allow-query { any; };
allow-query-cache { any; }; // Only on those RHEL servers
// which allowed it (*sigh*)
allow-recursion { none; };
zone tld.example {
type master;
file data/zone.tld.example;
};
};
zone.tld.example:
$TTL 3h
@ SOA ...
@ NS ns1.tld.example.
@ NS ns2.tld.example.
sub NS ns1.sub.tld.example.
sub NS ns2.sub.tld.example.
ns1 A ...
ns2 A ...
ns1.sub A ...
ns2.sub A ...
targetCNAME target.sub
In this case, trying to look up target.tld.example directly from
ns1.tld.example just gets you the CNAMEs but no A record.
This is normal and expected. The recursing resolver will then work on the
CNAME's target; your server will provide a referral to the subdomain, which
means just one more query should net it the final answer. This works, unless
you have some special reason why it won't in your case.
Consider the resolution path of www.apple.com. This involves several of these
dangling CNAME records in series, where the target is not in the same domain
and therefore the authoritative name server for each CNAME does not give a
referral. And yet it works just fine.
$ dig www.apple.com +norec @nserver.apple.com
; DiG 9.8.0-P2 www.apple.com +norec @nserver.apple.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 57811
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.apple.com. IN A
;; ANSWER SECTION:
www.apple.com. 1800IN CNAME www.isg-apple.com.akadns.net.
;; Query time: 21 msec
;; SERVER: 17.254.0.50#53(17.254.0.50)
;; WHEN: Fri Jul 8 10:23:36 2011
;; MSG SIZE rcvd: 73
$ dig www.isg-apple.com.akadns.net +norec @usw2.akadns.net
; DiG 9.8.0-P2 www.isg-apple.com.akadns.net +norec @usw2.akadns.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52429
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.isg-apple.com.akadns.net. IN A
;; ANSWER SECTION:
www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net.
;; Query time: 77 msec
;; SERVER: 64.211.42.194#53(64.211.42.194)
;; WHEN: Fri Jul 8 10:24:31 2011
;; MSG SIZE rcvd: 82
$ dig www.apple.com.edgekey.net +norec @usw6.akam.net
; DiG 9.8.0-P2 www.apple.com.edgekey.net +norec @usw6.akam.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1407
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.apple.com.edgekey.net. IN A
;; ANSWER SECTION:
www.apple.com.edgekey.net. 21600 IN CNAME e3191.c.akamaiedge.net.
;; Query time: 16 msec
;; SERVER: 96.17.144.195#53(96.17.144.195)
;; WHEN: Fri Jul 8 10:25:07 2011
;; MSG SIZE rcvd: 76
$ dig e3191.c.akamaiedge.net +norec @n8c.akamaiedge.net
; DiG 9.8.0-P2 e3191.c.akamaiedge.net +norec @n8c.akamaiedge.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 57748
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;e3191.c.akamaiedge.net.IN A
;; ANSWER SECTION:
e3191.c.akamaiedge.net. 20 IN A 184.85.109.15
;; Query time: 23 msec
;; SERVER: 69.22.163.131#53(69.22.163.131)
;; WHEN: Fri Jul 8 10:25:43 2011
;; MSG SIZE rcvd: 56
Regards,
Chris Buxton
BlueCat Networks
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
