Re: rfc1918 ns records coming from internet are queried?
In message <[EMAIL PROTECTED]>, David Sparks writes: > 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. > 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.3600IN NS support-dc7.rice.edu. > ad.rice.edu.3600IN NS support-dc6.rice.edu. > ad.rice.edu.3600IN NS support-dc5.rice.edu. > ad.rice.edu.3600IN NS support-dc4.rice.edu. > > ;; ADDITIONAL SECTION: > support-dc7.rice.edu. 3600IN A 10.136.93.4 > support-dc6.rice.edu. 3600IN A 128.42.18.16 > support-dc5.rice.edu. 3600IN A 10.129.92.100 > support-dc4.rice.edu. 3600IN 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 > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
Mark Andrews wrote: > In message <[EMAIL PROTECTED]>, David Sparks writes: >> 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 > >> 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.3600IN NS support-dc7.rice.edu. >> ad.rice.edu.3600IN NS support-dc6.rice.edu. >> ad.rice.edu.3600IN NS support-dc5.rice.edu. >> ad.rice.edu.3600IN NS support-dc4.rice.edu. >> >> ;; ADDITIONAL SECTION: >> support-dc7.rice.edu. 3600IN A 10.136.93.4 >> support-dc6.rice.edu. 3600IN A 128.42.18.16 >> support-dc5.rice.edu. 3600IN A 10.129.92.100 >> support-dc4.rice.edu. 3600IN 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
On Nov 25, 2008, at 4:23 PM, David Sparks wrote:
Mark Andrews wrote:
In message <[EMAIL PROTECTED]>, David Sparks writes:
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
In message <[EMAIL PROTECTED]>, David Sparks writes:
> Mark Andrews wrote:
> > In message <[EMAIL PROTECTED]>, David Sparks writes:
> >> 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; };
> 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.
> >> Is there any way to disable this behavior? Is it expected that bind queri
> es
> >> rfc1918 nameserver addresses from non-rfc1918 queries? I would've expecte
> d
> >> something along the lines of "error: ... RFC 1918 response from Internet f
> or
> >> ...".
> >>
> >>
> >> $ 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.3600IN NS support-dc7.rice.edu.
> >> ad.rice.edu.3600IN NS support-dc6.rice.edu.
> >> ad.rice.edu.3600IN NS support-dc5.rice.edu.
> >> ad.rice.edu.3600IN NS support-dc4.rice.edu.
> >>
> >> ;; ADDITIONAL SECTION:
> >> support-dc7.rice.edu. 3600IN A 10.136.93.4
> >> support-dc6.rice.edu. 3600IN A 128.42.18.16
> >> support-dc5.rice.edu. 3600IN A 10.129.92.100
> >> support-dc4.rice.edu. 3600IN 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
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
>> 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).
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
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
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
On Nov 26, 2008, at 10:43 AM, David Sparks wrote:
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).
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
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
Re: rfc1918 ns records coming from internet are queried?
> 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, [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
--- On Thu, 11/27/08, David Sparks <[EMAIL PROTECTED]> wrote:
> From: David Sparks <[EMAIL PROTECTED]>
> Subject: Re: rfc1918 ns records coming from internet are queried?
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Thursday, November 27, 2008, 7:43 AM
> >> 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).
>
> 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
> 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
Re: rfc1918 ns records coming from internet are queried?
[EMAIL PROTECTED] wrote: >> 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
> 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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
On Nov 26, 2008, at 11:49 AM, David Sparks wrote:
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. :)
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
> > 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, [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
[EMAIL PROTECTED] wrote: >>> 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
In message <[EMAIL PROTECTED]>, David Sparks writes: > [EMAIL PROTECTED] wrote: > >>> 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. Except it may not be. Networks are way too complicated to make such general assumptions. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
Thanks, the suggestion below looks like it might be what I'm looking for.
ds
> 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; };
> };
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
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
--- On Fri, 11/28/08, David Sparks <[EMAIL PROTECTED]> wrote:
> From: David Sparks <[EMAIL PROTECTED]>
> Subject: Re: rfc1918 ns records coming from internet are queried?
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Friday, November 28, 2008, 8:29 AM
> Thanks, the suggestion below looks like it might be what
> I'm looking for.
>
> ds
>
> > 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; };
> > };
> ___
> 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
Re: rfc1918 ns records coming from internet are queried?
In article <[EMAIL PROTECTED]>, David Sparks <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > >>> 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). > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rfc1918 ns records coming from internet are queried?
> Date: Wed, 26 Nov 2008 21:09:53 +0100 (CET) > To: [EMAIL PROTECTED] > Subject: Re: rfc1918 ns records coming from internet are queried? > From: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > > > > 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 > > Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] > ___ > bind-users mailing list > bind-users@lists.isc.org > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
