Re: DNS requests for 1918 space

[Duane Wessels]

> Is there something special about RFC1918 in this respect? Wouldn't
> these resolvers not work for all of the IN-ADDR.ARPA space? Wouldn't
> they be hitting the roots with all kinds of PTR queries?

Good question.  Certainly I do see plenty of non-1918 PTR queries as well,
but I don't have good stats on that.

> If he has broken resolvers, but the ISP servers are sane, he'll
> obviously end up pounding the ISP servers and perhaps the IANA blackhole
> servers if the queries are unique, but not the root servers.

Agreed.

Duane W.

Re: DNS requests for 1918 space

[Crist Clark]

Duane Wessels wrote:

The IN-ADDR.ARPA delegations for RFC1918 space are just like any
other block. You'll just end up hitting IANA's blackhole servers,
and not all that much, the cache times are one week.


In theory, yes.

In reality there are quite a few resolvers that, apparently, do not
receive the delegation response and continue to hit the roots with
PTR queries for RFC1918 space.
Is there something special about RFC1918 in this respect? Wouldn't
these resolvers not work for all of the IN-ADDR.ARPA space? Wouldn't
they be hitting the roots with all kinds of PTR queries?
Recent measurements at a single instance of an anycasted root server
show that at least 250 such resolvers generate between 60-120 RFC1918
PTR queries/sec.
I assume (and no idea really if it is a good assumption or not) that
the bulk of these broken resolvers do not belong to ISPs. The original
recipient said specficially that he was using his ISP's nameservers.
If he has broken resolvers, but the ISP servers are sane, he'll
obviously end up pounding the ISP servers and perhaps the IANA blackhole
servers if the queries are unique, but not the root servers.
But yes there are plenty of broken resolvers out there. One of my
current favorites is something in Novell print services that likes to
do A queries on a single printer name several dozen times per second, 
wait a few seconds or minutes, then do a query storm on another printer
name. These account for over 90% of the queries on some internal
DNS servers.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387

Re: DNS requests for 1918 space

[Valdis . Kletnieks]

On Tue, 16 Mar 2004 10:08:28 PST, bill said:

>   http://www.nanog.org/mtg-0210/wessels.html
>   has some very good information about some of the
>   problems w/ leaked queries.
> 
>   http://as112.net/  has some mitigation stratagies.

That mitigates the issue, but fails to deal with the root cause.

One has to wonder - if a network is spewing enough broken DNS packets that it's
noticable, and it's not getting fixed, what *else* is wrong with the network.
Remember - every packet you see is a timeout happening back at the
misconfigured site.

It's like a car with one headlight out - yes, it still works, but whenever I see
one on the road, I wonder what ELSE is marginal (like brake pads)


pgp0.pgp
Description: PGP signature

Re: DNS requests for 1918 space

[Duane Wessels]

> The IN-ADDR.ARPA delegations for RFC1918 space are just like any
> other block. You'll just end up hitting IANA's blackhole servers,
> and not all that much, the cache times are one week.

In theory, yes.

In reality there are quite a few resolvers that, apparently, do not
receive the delegation response and continue to hit the roots with
PTR queries for RFC1918 space.

Recent measurements at a single instance of an anycasted root server
show that at least 250 such resolvers generate between 60-120 RFC1918
PTR queries/sec.

Duane W.

Re: DNS requests for 1918 space

[Daniel Karrenberg]

On 16.03 11:22, Geo. wrote:
> 
> Can anyone point me at any papers that talk about security issues raised by
> private networks passing dns requests for RFC 1918 private address space out
> to their ISP's dns servers?

RFC1918

Re: DNS requests for 1918 space

[Joe Abley]

On 16 Mar 2004, at 13:07, Crist Clark wrote:

The IN-ADDR.ARPA delegations for RFC1918 space are just like any
other block. You'll just end up hitting IANA's blackhole servers,
and not all that much, the cache times are one week.
Also, those blackhole servers are anycast, so they might even be 
answered relatively locally. See .

Of course, the obvious "fix" is to run your own internal DNS which
is authorative for your RFC1918 addresses.


Joe

Re: DNS requests for 1918 space

[bill]

> 
> Can anyone point me at any papers that talk about security issues raised by
> private networks passing dns requests for RFC 1918 private address space out
> to their ISP's dns servers?
> 
> I'm aware of the issues involved with an ISP passing the requests on to the
> root servers but was looking specifically for security type issues relating
> to a private network passing the requests out to their ISP's dns servers.
> 
> Geo.
> 
http://www.nanog.org/mtg-0210/wessels.html
has some very good information about some of the
problems w/ leaked queries.

http://as112.net/  has some mitigation stratagies.


--bill

Re: DNS requests for 1918 space

[Crist Clark]

Geo. wrote:

Can anyone point me at any papers that talk about security issues raised by
private networks passing dns requests for RFC 1918 private address space out
to their ISP's dns servers?
I've never seen the whole paper on the topic. Leaking the fact that
you use 10.10.10.0/24 or whatever internally is not a big deal. It's
security by obscurity of the very weak kind. Anyone with half of a clue
will drop traffic with a source or destination address of their internal
RFC1918 networks at the border, (and even if one uses registered
addresses internally, you would be dropping traffic with a souce address
of the internal network from entering at the border). That's the "real"
security.
I'm aware of the issues involved with an ISP passing the requests on to the
root servers but was looking specifically for security type issues relating
to a private network passing the requests out to their ISP's dns servers.
These requests will not go to the root servers any more than any other
reverse lookups ISP's DNS,
  $ dig -x 10 ns
  ; <<>> DiG 8.3 <<>> -x ns
  ;; res options: init recurs defnam dnsrch
  ;; got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
  ;; QUERY SECTION:
  ;;  10.in-addr.arpa, type = NS, class = IN
  ;; ANSWER SECTION:
  10.in-addr.arpa.1W IN NSblackhole-1.iana.org.
  10.in-addr.arpa.1W IN NSblackhole-2.iana.org.
  ;; ADDITIONAL SECTION:
  blackhole-1.iana.org.   16m43s IN A 192.175.48.6
  blackhole-2.iana.org.   16m43s IN A 192.175.48.42
  ;; Total query time: 53 msec
  ;; FROM: sec-tools.corp.globalstar.com to SERVER: default -- 
207.88.152.10
  ;; WHEN: Tue Mar 16 09:53:44 2004

The IN-ADDR.ARPA delegations for RFC1918 space are just like any
other block. You'll just end up hitting IANA's blackhole servers,
and not all that much, the cache times are one week.
Of course, the obvious "fix" is to run your own internal DNS which
is authorative for your RFC1918 addresses.
--
Crist J. Clark   [EMAIL PROTECTED]
Globalstar Communications(408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited.  If you have
received this e-mail in error, please contact [EMAIL PROTECTED]

Re: DNS requests for 1918 space

[Valdis . Kletnieks]

On Tue, 16 Mar 2004 11:22:55 EST, "Geo." <[EMAIL PROTECTED]>  said:

> I'm aware of the issues involved with an ISP passing the requests on to the
> root servers but was looking specifically for security type issues relating
> to a private network passing the requests out to their ISP's dns servers.

Hint:  Every such DNS request that escapes will either time out or get an
error.  The admin is unwilling or unable to fix the resulting breakage.
The fact that it isn't being fixed should tell you a lot about the site


pgp0.pgp
Description: PGP signature

DNS requests for 1918 space

[Geo.]

Can anyone point me at any papers that talk about security issues raised by
private networks passing dns requests for RFC 1918 private address space out
to their ISP's dns servers?

I'm aware of the issues involved with an ISP passing the requests on to the
root servers but was looking specifically for security type issues relating
to a private network passing the requests out to their ISP's dns servers.

Geo.