At 5:00 + 2/20/07, Paul Vixie wrote:
because the default is for ambiguous addresses to leak into places where
they make no sense. similarly, rfc 1918 source addressed ip packets should
not be able to escape their routing domain by default.
The addresses are "private" not "ambiguous." Cal
> >if someone wants to use
> >private address space for DNS work, they should have to run an extra knob.
>
> Why?
>
> Why make it hard to do something right?
because the default is for ambiguous addresses to leak into places where
they make no sense. similarly, rfc 1918 source addressed ip pack
At 20:16 + 2/19/07, Paul Vixie wrote:
if someone wants to use
private address space for DNS work, they should have to run an extra knob.
Why?
Why make it hard to do something right?
Why is this a DNS issue? Why use the DNS to make a statement on the
use of RFC 1918 space?
--
-=-=-=-=-
At 14:27 + 2/19/07, Tony Finch wrote:
If you point NS records at private networks then you can get DNS servers
to send queries to their private networks. The timing of any responses you
get might give you some information about their network topology, e.g.
which hosts are up, etc.
So, put
At 12:47 + 2/19/07, Jim Reid wrote:
On Feb 19, 2007, at 11:56, Edward Lewis wrote:
At 11:34 + 2/19/07, Jim Reid wrote:
I fail to see how changing -- I'd say defining -- the default behaviour of
a name server in this way could possibly be a protocol issue.
Being that the name server
> > you mean, a name server looking at its own fully qualified host name and
> > making policy decisions based on that? (sounds Incredibly Dangerous.)
>
> I'm possibly confused. The scenario I was thinking of seems to involve two
> nameservers on the same 10.x.x.x network that want to point to ea
--On 19. februar 2007 14:50 + Paul Vixie <[EMAIL PROTECTED]> wrote:
>server 10.0.0.0/8 { bogus yes; };
>server 172.16.0.0/12 { bogus yes; };
>server 192.168.0.0/16 { bogus yes; };
is there a way to say "if source is in same domain, allow, else deny"?
> > server 10.0.0.0/8 { bogus yes; };
> > server 172.16.0.0/12 { bogus yes; };
> > server 192.168.0.0/16 { bogus yes; };
> is there a way to say "if source is in same domain, allow, else deny"?
> I'd like to allow 10.0.0.53 as a nameserver on *my* (home) network
On Mon, 19 Feb 2007, Edward Lewis wrote:
> At 10:55 + 2/19/07, Tony Finch wrote:
> >
> > It allows you to use a DNS server to tunnel past a firewall. It allows you
> > to use a DNS server to probe a private network.
>
> How?
If you point NS records at private networks then you can get DNS serv
On Mon, Feb 19, 2007 at 07:56:36PM +0800,
Edward Lewis <[EMAIL PROTECTED]> wrote
a message of 69 lines which said:
> >Another desirable default resolver configuration would be to refuse
> >recursive queries from non-local addresses.
>
> How? What's local? What's not local? Do you want to se
On Feb 19, 2007, at 11:56, Edward Lewis wrote:
At 11:34 + 2/19/07, Jim Reid wrote:
Right. But it depends on what's meant by "extra measures". IMO
it's more than
reasonable to have a default that says "don't do reverse lookups
of 1918
addresses on the Internet". This would be a Very Good
At 11:34 + 2/19/07, Jim Reid wrote:
Right. But it depends on what's meant by "extra measures". IMO it's more than
reasonable to have a default that says "don't do reverse lookups of 1918
addresses on the Internet". This would be a Very Good Thing. If this was in
place, the extra measures wou
Just a comment, it is common for people to make entries in private DNS for
IP addresses outside their control, not sure about vice versa but it is no
big deal.
I remember this client requirement way back in 2000
It was more like 2 projects in a customer environment with something being
dev
At 11:22 + 2/19/07, Ben Laurie wrote:
I get a referral effectively saying to go to 10.1.1.1.
Not if you told the server to recurse.
I don't understand your reply.
I could send a "RD" bit in my query and still get a referral.
If I do send a "RD" bit in the query and the remote server a
On Feb 19, 2007, at 10:47, Edward Lewis wrote:
At 22:23 + 2/16/07, Paul Vixie wrote:
what i'd like is permission from the IETF community to change our
default.
I prefer having the nameserver be told to take extra measures in a
case like this.
Right. But it depends on what's meant by
Edward Lewis wrote:
> At 10:55 + 2/19/07, Tony Finch wrote:
>> On Mon, 19 Feb 2007, Edward Lewis wrote:
>>>
>>> 3) I don't buy this as a security risk. I don't think there is a
>>> problem
>>> here.
>>
>> It allows you to use a DNS server to tunnel past a firewall. It allows
>> you
>> to use
At 10:55 + 2/19/07, Tony Finch wrote:
On Mon, 19 Feb 2007, Edward Lewis wrote:
3) I don't buy this as a security risk. I don't think there is a problem
here.
It allows you to use a DNS server to tunnel past a firewall. It allows you
to use a DNS server to probe a private network.
How
On Mon, 19 Feb 2007, Edward Lewis wrote:
>
> 3) I don't buy this as a security risk. I don't think there is a problem
> here.
It allows you to use a DNS server to tunnel past a firewall. It allows you
to use a DNS server to probe a private network.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> htt
At 22:23 + 2/16/07, Paul Vixie wrote:
what i'd like is permission from the IETF community to change our default.
My opinion...and just that...
Don't change. I prefer having the nameserver be told to take extra
measures in a case like this.
1) RFC 1918 is legitimate space, it's just no
Mark Andrews wrote:
Named already has this capability.
You can use the blackhole acl or you can use multiple
server "cidr" { bogus yes; };.
server 10.0.0.0/8 { bogus yes; };
server 172.16.0.0/12 { bogus yes; };
server 192.1
20 matches
Mail list logo
