rfc1918 ns records coming from internet are queried?

[David Sparks]

Problem: when querying asdf.ad.rice.edu, bind sends queries into my local
network (specifically to 10.129.92.100, which is not a ns) which I find
undesirable.

Is there any way to disable this behavior? Is it expected that bind queries
rfc1918 nameserver addresses from non-rfc1918 queries? I would've expected
something along the lines of "error: ... RFC 1918 response from Internet for ...".


$ dig @ns1.rice.edu asdf.ad.rice.edu

; <<>> DiG 9.4.1-P1 <<>> @ns1.rice.edu asdf.ad.rice.edu
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52793
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;asdf.ad.rice.edu. IN A

;; AUTHORITY SECTION:
ad.rice.edu. 3600 IN NS support-dc7.rice.edu.
ad.rice.edu. 3600 IN NS support-dc6.rice.edu.
ad.rice.edu. 3600 IN NS support-dc5.rice.edu.
ad.rice.edu. 3600 IN NS support-dc4.rice.edu.

;; ADDITIONAL SECTION:
support-dc7.rice.edu. 3600 IN A 10.136.93.4
support-dc6.rice.edu. 3600 IN A 128.42.18.16
support-dc5.rice.edu. 3600 IN A 10.129.92.100
support-dc4.rice.edu. 3600 IN A 128.42.18.223

;; Query time: 82 msec
;; SERVER: 128.42.209.32#53(128.42.209.32)
;; WHEN: Tue Nov 25 15:29:48 2008
;; MSG SIZE rcvd: 202

[Mark Andrews]

Post by David Sparks
Problem: when querying asdf.ad.rice.edu, bind sends queries into my local
network (specifically to 10.129.92.100, which is not a ns) which I find
undesirable.

Mark the servers as bogus.

Post by David Sparks
Is there any way to disable this behavior? Is it expected that bind queries
rfc1918 nameserver addresses from non-rfc1918 queries? I would've expected
something along the lines of "error: ... RFC 1918 response from Internet for
...".
; (1 server found)
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52793
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;asdf.ad.rice.edu. IN A
ad.rice.edu. 3600 IN NS support-dc7.rice.edu.
ad.rice.edu. 3600 IN NS support-dc6.rice.edu.
ad.rice.edu. 3600 IN NS support-dc5.rice.edu.
ad.rice.edu. 3600 IN NS support-dc4.rice.edu.
support-dc7.rice.edu. 3600 IN A 10.136.93.4
support-dc6.rice.edu. 3600 IN A 128.42.18.16
support-dc5.rice.edu. 3600 IN A 10.129.92.100
support-dc4.rice.edu. 3600 IN A 128.42.18.223
;; Query time: 82 msec
;; SERVER: 128.42.209.32#53(128.42.209.32)
;; WHEN: Tue Nov 25 15:29:48 2008
;; MSG SIZE rcvd: 202
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[David Sparks]

Post by Mark Andrews

Post by David Sparks
Problem: when querying asdf.ad.rice.edu, bind sends queries into my local
network (specifically to 10.129.92.100, which is not a ns) which I find
undesirable.

Mark the servers as bogus.

Doesn't that only work on a server by server basis? rice.edu is just an
example ... I'm looking for a way to set a policy that named wont query
rfc1918 nameserver addresses returned from a non-rfc1918 query. Would this be
a bad policy?

ds

Post by Mark Andrews

Post by David Sparks
Is there any way to disable this behavior? Is it expected that bind queries
rfc1918 nameserver addresses from non-rfc1918 queries? I would've expected
something along the lines of "error: ... RFC 1918 response from Internet for
...".
; (1 server found)
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52793
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;asdf.ad.rice.edu. IN A
ad.rice.edu. 3600 IN NS support-dc7.rice.edu.
ad.rice.edu. 3600 IN NS support-dc6.rice.edu.
ad.rice.edu. 3600 IN NS support-dc5.rice.edu.
ad.rice.edu. 3600 IN NS support-dc4.rice.edu.
support-dc7.rice.edu. 3600 IN A 10.136.93.4
support-dc6.rice.edu. 3600 IN A 128.42.18.16
support-dc5.rice.edu. 3600 IN A 10.129.92.100
support-dc4.rice.edu. 3600 IN A 128.42.18.223
;; Query time: 82 msec
;; SERVER: 128.42.209.32#53(128.42.209.32)
;; WHEN: Tue Nov 25 15:29:48 2008
;; MSG SIZE rcvd: 202

[Chris Buxton]

Post by David Sparks

Post by Mark Andrews

Post by David Sparks
Problem: when querying asdf.ad.rice.edu, bind sends queries into my local
network (specifically to 10.129.92.100, which is not a ns) which I find
undesirable.

Mark the servers as bogus.

Doesn't that only work on a server by server basis? rice.edu is just an
example ... I'm looking for a way to set a policy that named wont query
rfc1918 nameserver addresses returned from a non-rfc1918 query.
Would this be
a bad policy?

You could use netmasks with your server statements, like this:

server 10.0.0.0/8 {
bogus yes;
};

server 172.16.0.0/12 {
bogus yes;
};

server 192.168.0.0/16 {
bogus yes;
};

You could even then override this for specific servers in those
ranges, by using statements without netmasks (or more specific
netmasks).

Chris Buxton
Professional Services
Men & Mice

[David Sparks]

Post by Chris Buxton

Post by David Sparks
I'm looking for a way to set a policy that named wont
query
rfc1918 nameserver addresses returned from a non-rfc1918 query.
Would this be
a bad policy?

server 10.0.0.0/8 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
You could even then override this for specific servers in those
ranges, by using statements without netmasks (or more specific
netmasks).

Thanks, that is a workaround that solves most of the problem, but
unfortunately it is not usable. It requires that a list of the local
organizations dns servers are maintained which is unfeasible (large, global,
disparate organization). Also, IP collision between local dns servers and
rogue rfc1918 responses will still send queries to the local dns servers.


A good border router will do a few things for network hygiene. It will filter
incoming packets that have a source address from the internal network, and it
will filter outgoing packets that don't have a source IP in the internal network.

A DNS server should do a similar thing: it will not send rfc1918 queries to
the internet, and it will discard rfc1918 responses from the internet.

It appears Bind can't do this and I'm fine with that. This email is simply to
clear up any confusion about what the issue is.

ds

[Chris Buxton]

The queries from the resolver to internal name servers caused by
incorrect referrals for outside domains *should* cause no harm.

However, if you're concerned, it's pretty easy to set up a more secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.

This way, there is complete separation between inside and outside
resolution. A referral from an outside domain with a glue record
pointing inside is ignored.

Chris Buxton
Professional Services
Men & Mice

Post by David Sparks

Post by Chris Buxton

Post by David Sparks
I'm looking for a way to set a policy that named wont
query
rfc1918 nameserver addresses returned from a non-rfc1918 query.
Would this be
a bad policy?

server 10.0.0.0/8 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
You could even then override this for specific servers in those
ranges, by using statements without netmasks (or more specific
netmasks).

Thanks, that is a workaround that solves most of the problem, but
unfortunately it is not usable. It requires that a list of the local
organizations dns servers are maintained which is unfeasible (large, global,
disparate organization). Also, IP collision between local dns
servers and
rogue rfc1918 responses will still send queries to the local dns servers.
A good border router will do a few things for network hygiene. It will filter
incoming packets that have a source address from the internal
network, and it
will filter outgoing packets that don't have a source IP in the internal network.
A DNS server should do a similar thing: it will not send rfc1918 queries to
the internet, and it will discard rfc1918 responses from the internet.
It appears Bind can't do this and I'm fine with that. This email is simply to
clear up any confusion about what the issue is.
ds
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[David Sparks]

Post by Chris Buxton
However, if you're concerned, it's pretty easy to set up a more secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.

That will work but I was hoping for something like:

view "internet" {
filter-rfc1918-responses yes;
...

However I'm not concerned. :)

ds

[Chris Buxton]

Post by David Sparks

Post by Chris Buxton
However, if you're concerned, it's pretty easy to set up a more secure
infrastructure. Put a resolver (resolving name server) at the edge of
your network (in a DMZ, presumably) that knows nothing of internal
domains (nor IP address space). It refuses to send queries to private
addresses, but will answer queries coming from them. Then set up an
internal resolver that knows about your private namespace; for any
outside domains, it forwards to the server on the edge of your
network. Have client machines send queries to the internal resolver,
not to the edge resolver.

view "internet" {
filter-rfc1918-responses yes;
...
However I'm not concerned. :)

You can in fact set up the environment I described using views. Just
have the private view forward to the internet view. The following
resolving name server will ignore referrals to private name servers
for outside names; note that it's missing the masters list definition
named "private-auth-servers", plus the options statement, but is
otherwise complete.

acl "private" {
10/8;
172.16/12;
192.168/16;
# does not include 127/8
};
view "private" {
match-clients { private; };
# forward unknown names to the internet view:
forward only;
forwarders { 127.0.0.1; };
# stub, slave, or forward zones for the private namespace:
zone "private.zone" {
type stub;
masters { private-auth-servers; };
file "stub.private.zone";
forwarders { }; # disable forwarding for stub zones
};
};
view "internet" {
server 10/8 { bogus yes; };
server 172.16/12 { bogus yes; };
server 192.168/16 { bogus yes; };
allow-query { 127.0.0.1; };
};

Chris Buxton
Professional Services
Men & Mice

[David Sparks]

Thanks, the suggestion below looks like it might be what I'm looking for.

ds

Post by Chris Buxton
You can in fact set up the environment I described using views. Just
have the private view forward to the internet view. The following
resolving name server will ignore referrals to private name servers
for outside names; note that it's missing the masters list definition
named "private-auth-servers", plus the options statement, but is
otherwise complete.
acl "private" {
10/8;
172.16/12;
192.168/16;
# does not include 127/8
};
view "private" {
match-clients { private; };
forward only;
forwarders { 127.0.0.1; };
zone "private.zone" {
type stub;
masters { private-auth-servers; };
file "stub.private.zone";
forwarders { }; # disable forwarding for stub zones
};
};
view "internet" {
server 10/8 { bogus yes; };
server 172.16/12 { bogus yes; };
server 192.168/16 { bogus yes; };
allow-query { 127.0.0.1; };
};

[s***@nethelp.no]

Post by David Sparks
A good border router will do a few things for network hygiene. It will filter
incoming packets that have a source address from the internal network, and it
will filter outgoing packets that don't have a source IP in the internal network.
A DNS server should do a similar thing: it will not send rfc1918 queries to
the internet, and it will discard rfc1918 responses from the internet.

A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

Steinar Haug, Nethelp consulting, ***@nethelp.no

[David Sparks]

Post by s***@nethelp.no

Post by David Sparks
A good border router will do a few things for network hygiene. It will filter
incoming packets that have a source address from the internal network, and it
will filter outgoing packets that don't have a source IP in the internal network.
A DNS server should do a similar thing: it will not send rfc1918 queries to
the internet, and it will discard rfc1918 responses from the internet.

A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks, it
is about rfc1918 responses from internet queries.

ds

[s***@nethelp.no]

Post by David Sparks

Post by s***@nethelp.no
A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks, it
is about rfc1918 responses from internet queries.

I'm afraid I have seen too many organizations using a mix of public and
RFC1918 IP addresses on the "inside". Thus I don't believe that you can
differentiate based on RFC1918 addresses or not on a general basis.

Steinar Haug, Nethelp consulting, ***@nethelp.no

[David Sparks]

Post by s***@nethelp.no

Post by David Sparks

Post by s***@nethelp.no
A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks, it
is about rfc1918 responses from internet queries.

I'm afraid I have seen too many organizations using a mix of public and
RFC1918 IP addresses on the "inside". Thus I don't believe that you can
differentiate based on RFC1918 addresses or not on a general basis.

This is incorrect, you can always differentiate based on rfc1918 addresses.
When a 3rd party gives you a rfc1918 address it is invalid.

ds

[Sam Wilson]

Post by David Sparks

Post by s***@nethelp.no

Post by David Sparks

Post by s***@nethelp.no
A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks, it
is about rfc1918 responses from internet queries.

I'm afraid I have seen too many organizations using a mix of public and
RFC1918 IP addresses on the "inside". Thus I don't believe that you can
differentiate based on RFC1918 addresses or not on a general basis.

I work for one such organisation (and am responsible for the address
architecture).

Post by David Sparks
This is incorrect, you can always differentiate based on rfc1918 addresses.
When a 3rd party gives you a rfc1918 address it is invalid.

But you've already said that you can't practically enumerate your
internal servers. Can you actually tell which are third parties which
ought not to be giving you rfc1918 addresses and which are internal
servers which should?

Sam

[Mark Andrews]

Post by David Sparks

Post by Mark Andrews

Post by David Sparks
Problem: when querying asdf.ad.rice.edu, bind sends queries into my local
network (specifically to 10.129.92.100, which is not a ns) which I find
undesirable.

Mark the servers as bogus.

Doesn't that only work on a server by server basis?

No. server 10.0.0.0/8 { bogus yes; };

Post by David Sparks
rice.edu is just an
example ... I'm looking for a way to set a policy that named wont query
rfc1918 nameserver addresses returned from a non-rfc1918 query. Would this b
e
a bad policy?
ds

In reality RFC 1918 addresses are no different to any other
addresses. Replace the 10/8 addresses with 213.31/16
addresses and you have the same problem.

The best long term solution is to stop using RFC 1918
addresses. They were not allocated for this sort of use.

Post by David Sparks

Post by Mark Andrews

Post by David Sparks
Is there any way to disable this behavior? Is it expected that bind queri

es

Post by Mark Andrews

Post by David Sparks
rfc1918 nameserver addresses from non-rfc1918 queries? I would've expecte

d

Post by Mark Andrews

Post by David Sparks
something along the lines of "error: ... RFC 1918 response from Internet f

or

Post by Mark Andrews

Post by David Sparks
...".
; (1 server found)
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52793
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;asdf.ad.rice.edu. IN A
ad.rice.edu. 3600 IN NS support-dc7.rice.edu.
ad.rice.edu. 3600 IN NS support-dc6.rice.edu.
ad.rice.edu. 3600 IN NS support-dc5.rice.edu.
ad.rice.edu. 3600 IN NS support-dc4.rice.edu.
support-dc7.rice.edu. 3600 IN A 10.136.93.4
support-dc6.rice.edu. 3600 IN A 128.42.18.16
support-dc5.rice.edu. 3600 IN A 10.129.92.100
support-dc4.rice.edu. 3600 IN A 128.42.18.223
;; Query time: 82 msec
;; SERVER: 128.42.209.32#53(128.42.209.32)
;; WHEN: Tue Nov 25 15:29:48 2008
;; MSG SIZE rcvd: 202

_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[ivan jr sy]

Subject: Re: rfc1918 ns records coming from internet are queried?
Date: Thursday, November 27, 2008, 7:43 AM

Post by Chris Buxton

Post by David Sparks
I'm looking for a way to set a policy that

named wont

Post by Chris Buxton

Post by David Sparks
query
rfc1918 nameserver addresses returned from a

non-rfc1918 query.

Post by Chris Buxton

Post by David Sparks
Would this be
a bad policy?

You could use netmasks with your server statements,
server 10.0.0.0/8 {
bogus yes;
};
server 172.16.0.0/12 {
bogus yes;
};
server 192.168.0.0/16 {
bogus yes;
};
You could even then override this for specific servers

in those

Post by Chris Buxton
ranges, by using statements without netmasks (or more

specific

Post by Chris Buxton
netmasks).

Thanks, that is a workaround that solves most of the
problem, but
unfortunately it is not usable. It requires that a list of
the local
organizations dns servers are maintained which is
unfeasible (large, global,
disparate organization). Also, IP collision between local
dns servers and
rogue rfc1918 responses will still send queries to the
local dns servers.
A good border router will do a few things for network
hygiene. It will filter
incoming packets that have a source address from the
internal network, and it
will filter outgoing packets that don't have a source
IP in the internal network.
A DNS server should do a similar thing: it will not send
rfc1918 queries to
the internet, and it will discard rfc1918 responses from
the internet.
It appears Bind can't do this and I'm fine with
that. This email is simply to
clear up any confusion about what the issue is.

This is an operational issue. The owner of 'ad.rice.edu' be responsible not to publish RRs pointing to RFC 1918 addresses, especially the glue.

split DNS or split views should have been done from their end.

ds
_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Mark Andrews]

Post by David Sparks

Post by s***@nethelp.no

Post by David Sparks

Post by s***@nethelp.no
A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks,

it

Post by s***@nethelp.no

Post by David Sparks
is about rfc1918 responses from internet queries.

I'm afraid I have seen too many organizations using a mix of public and
RFC1918 IP addresses on the "inside". Thus I don't believe that you can
differentiate based on RFC1918 addresses or not on a general basis.

This is incorrect, you can always differentiate based on rfc1918 addresses.
When a 3rd party gives you a rfc1918 address it is invalid.

Except it may not be. Networks are way too complicated to
make such general assumptions.

Mark

[ivan jr sy]

this might also help..

http://code.google.com/p/google-dnswall

in a nutshell, its like a DNS proxy server, you can use this to forward to BIND. between your clients and your internal BIND servers.

it filters:
- Invalid IP address: an IP address that starts with 0; i.e. 0.x.x.x
- Node-Local IP address: 127.x.x.x
- Link-Local IP address: 169.254.x.x
- Site-Local IP address: 10.x.x.x, 172.x.x.x, 192.168.x.x
- Multicast IP address: 224.x.x.x


""DNSWall is a proof-of-concept (PoC) tool developed by some security researchers from Stanford University as a protection mechanism against DNS rebinding attacks.""

http://securebits.org/blog/blog.php/2008/10/15/dnswall-a-protection-mechanism-against-d

Subject: Re: rfc1918 ns records coming from internet are queried?
Date: Friday, November 28, 2008, 8:29 AM
Thanks, the suggestion below looks like it might be what
I'm looking for.
ds

Post by Chris Buxton
You can in fact set up the environment I described

using views. Just

Post by Chris Buxton
have the private view forward to the internet view.

The following

Post by Chris Buxton
resolving name server will ignore referrals to private

name servers

Post by Chris Buxton
for outside names; note that it's missing the

masters list definition

Post by Chris Buxton
named "private-auth-servers", plus the

options statement, but is

Post by Chris Buxton
otherwise complete.
acl "private" {
10/8;
172.16/12;
192.168/16;
# does not include 127/8
};
view "private" {
match-clients { private; };
forward only;
forwarders { 127.0.0.1; };
# stub, slave, or forward zones for the
zone "private.zone" {
type stub;
masters { private-auth-servers; };
file "stub.private.zone";
forwarders { }; # disable forwarding

for stub zones

Post by Chris Buxton
};
};
view "internet" {
server 10/8 { bogus yes; };
server 172.16/12 { bogus yes; };
server 192.168/16 { bogus yes; };
allow-query { 127.0.0.1; };
};

_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

[Gregory Hicks]

Date: Wed, 26 Nov 2008 21:09:53 +0100 (CET)
Subject: Re: rfc1918 ns records coming from internet are queried?

Post by David Sparks

Post by s***@nethelp.no
A border router knows what is "inside" and "outside" your network, while
a DNS server does not. Important difference.

You're missing the point. This is not about inside and outside networks, it
is about rfc1918 responses from internet queries.

I'm afraid I have seen too many organizations using a mix of public and
RFC1918 IP addresses on the "inside". Thus I don't believe that you can
differentiate based on RFC1918 addresses or not on a general basis.

Actually, I got the impression that the OP wanted to know if BIND would
ignore and NS records provided by some server on the internet that
pointed to RFC-1918 type IP addresses. (It could be that everyone is
talking to the same thing...)

If BIND sends out a request, as it should, to some set of NS record IP
addresses, it keeps a record of WHEN the request was sent out and marks
how long it takes to get a response back from those requests. The
RFC-1918 type addresses SHOULD never respond - unless you happen to
have a server at the same address that someone else is advertizing.
(The "SHOULD never respond" is driven by the BCP-38 filtering at edge
routers.) Thus those addresses will have ungodly high round trip times
and should be removed from further queries...

(My read of how it works. I could be wrong though.)

Regards,
Gregory Hicks

_______________________________________________
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users

---------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
| Direct: 408.569.7928

People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell

The price of freedom is eternal vigilance. -- Thomas Jefferson

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton