Caching only name server

[Rahul Tidke]

Hello All,
Please see below /var/log/messages when I started named service; I
have installed bind-chroot package on fedora core 6, configured the
caching only name server and started the service.

[root@espl etc]# service named start
Starting named: [ OK ]

Now named is running but I am still unable to resolve hostnames from
client computers.

[root@espl etc]# rndc status
rndc: connect failed: 127.0.0.1#953: timed out

[root@espl ~]# service named status
rndc: connect failed: 127.0.0.1#953: operation canceled

[root@espl etc]# service named restart
Stopping named: ..................................................no
response, killing with -TERM
[ OK ]
Starting named: [ OK ]

/var/log/messages output:

Jul 10 10:23:25 espl named[27224]: shutting down
Jul 10 10:23:25 espl named[27224]: stopping command channel on 127.0.0.1#953
Jul 10 10:23:25 espl named[27224]: stopping command channel on ::1#953
Jul 10 10:23:25 espl named[27224]: no longer listening on ::1#53
Jul 10 10:23:25 espl named[27224]: no longer listening on 127.0.0.1#53
Jul 10 10:23:25 espl named[27224]: no longer listening on 192.168.10.254#53
Jul 10 10:23:25 espl named[27224]: exiting
Jul 10 10:23:27 espl named[27592]: starting BIND 9.3.4-P1 -u named -t
/var/named/chroot
Jul 10 10:23:27 espl named[27592]: found 2 CPUs, using 2 worker threads
Jul 10 10:23:27 espl named[27592]: loading configuration from
'/etc/named.conf'
Jul 10 10:23:27 espl named[27592]: listening on IPv6 interface lo, ::1#53
Jul 10 10:23:27 espl named[27592]: listening on IPv4 interface lo,
127.0.0.1#53
Jul 10 10:23:27 espl named[27592]: listening on IPv4 interface eth0,
192.168.10.254#53
Jul 10 10:23:27 espl named[27592]: command channel listening on
127.0.0.1#953
Jul 10 10:23:27 espl named[27592]: command channel listening on ::1#953
Jul 10 10:23:27 espl named[27592]: zone
0.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Jul 10 10:23:27 espl named[27592]: zone
0.0.127.in-addr.arpa/IN/localhost_resolver: loaded serial 1997022700
Jul 10 10:23:27 espl named[27592]: zone
255.in-addr.arpa/IN/localhost_resolver: loaded serial 42
Jul 10 10:23:27 espl named[27592]: zone
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN/localhost_resolver:
loaded serial 1997022700
Jul 10 10:23:27 espl named[27592]: zone
localdomain/IN/localhost_resolver: loaded serial 42
Jul 10 10:23:27 espl named[27592]: zone localhost/IN/localhost_resolver:
loaded serial 42
Jul 10 10:23:27 espl named[27592]: running

What needs to be updated?

Thanks.

Regards,
Rahul.

[Kevin Darcy]

The fact that you're listening on a private address (192.168.10.254)
implies that you're running behind some sort of NAT and/or firewall. The
fact that you don't have any kind of "hints" file defined means you're
going to be using the compiled-in defaults and thus trying to query the
Internet root nameservers. Is the NAT/Firewall set up to allow direct
access to the Internet root nameservers? Try querying one of the root
nameservers directly from your box, e.g.

dig com ns +norec @192.58.128.30

I don't know why you'd be timing out trying to use "rndc", since the log
messages indicate that named is listening on the appropriate command
channel. If the "bind-chroot" setup script hadn't set up your RNDC
key/config properly, I'd expect a different errror message than that.
Are you absolutely sure the named process was running when you issued
the rndc command? Do you see named listening on 127.0.0.1#53 in a
netstat display?

- Kevin

[Rahul Tidke]

I executed this command successfully.

>
> I don't know why you'd be timing out trying to use "rndc", since the log
> messages indicate that named is listening on the appropriate command
> channel. If the "bind-chroot" setup script hadn't set up your RNDC
> key/config properly, I'd expect a different errror message than that.
> Are you absolutely sure the named process was running when you issued
> the rndc command? Do you see named listening on 127.0.0.1#53 in a
> netstat display?
>
>
> - Kevin

I don't see any 127.0.0.1#53 statement in netstat output.
See below output when I executed host command on 192.168.10.254

[root@espl ~]# host 192.168.10.254
Host 254.10.168.192.in-addr.arpa not found: 3(NXDOMAIN)

My named.conf is located at /var/named/chroot/etc/ ; as follows

options {
listen-on port 53 { 127.0.0.1; 192.168.10.254; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
query-source port 53;
query-source-v6 port 53;
allow-query { localhost; 192.168.10.0/24; };
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
view localhost_resolver {
match-clients { localhost; };
match-destinations { localhost; };
recursion yes;
include "/etc/named.rfc1912.zones";
};

include "/etc/rndc.key";

This file is same as named.caching-nameserver.com located at
/var/named/chroot/etc.

What I need to check now?

Thanks.

Rahul.

[Alan Clegg]

Twice in the last two days, I've seen people post their named.conf files
(or snippets there-of) and they have contained lines similar to the
following:

> query-source port 53;
> query-source-v6 port 53;

These lines specifically "undo" the port randomization that is included
in the current -P1 and beta code required for securing your servers from
cache poisoning.

It is not enough to install the patched code! You also MUST remove the
restrictions on the ports that your queries use when leaving your system.

Be aware that this may entail getting some cooperation from your
firewall administrators, but this is VITAL to the resilience of your
servers against the new attack vector.

Please, if you have QUERY-SOURCE PORT XX statements in your
configuration files, work quickly to remove them.

Thanks,
AlanC

[Jeff Lightner]

Can you elaborate on this?

I had thought turning off cache queries to external lookups was
sufficient. Are you saying this is needed in addition or that cache
query disabling had nothing to do with the cache poisoning?

Also as to the randomization - is this only for outbound responses? The
initial query would have to come on port 53 where named listens or are
you saying that it somehow listens on random ports as well?

Thanks,
AlanC
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

[Alan Clegg]

Jeff Lightner wrote:
> I had thought turning off cache queries to external lookups was
> sufficient. Are you saying this is needed in addition or that cache
> query disabling had nothing to do with the cache poisoning?

If your server is authoritative only, it is not at risk. If it is
recursive, it is at risk.

It's not allowing queries from outside your network that puts you at
risk, it's doing recursion on behalf of others (internal or external)
that opens you to the vulnerability.

If you recurse, install new code and don't limit your queries to a
single port.

> Also as to the randomization - is this only for outbound responses? The
> initial query would have to come on port 53 where named listens or are
> you saying that it somehow listens on random ports as well?

This randomization is of queries being sent out from recursive servers
on behalf of the system that sent the query with the recursion desired
"RD" bit set.

All DNS queries will have a destination of port 53. You just don't want
all of the queries to have the same SOURCE port.

AlanC

[Jeff Lightner]

Thanks.

Forgive me for being dense but I'm trying to understand.

Is the "cache poisoning" poisoning of our name servers' cache or of name
servers that our recursive queries are using for resolution of external
sites (e.g. google.com, yahoo.com, billybob.com)?

When you say allowing recursion is the issue are you saying that in the
sense that there is a risk from internal sabotage as there is from
internet hackers or are you saying simply having it on for internal
users somehow also would allow internet hackers to exploit it?

Reading your final paragraph makes it seem like you mean it is the
latter.

Just to make sure I understand recursion: My assumption is that this is
necessary to do lookups for zones for which we are not authoritative
like the examples above. Is that correct?

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Alan Clegg
Sent: Friday, July 11, 2008 12:44 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

AlanC

[Evan Hunt]

> Is the "cache poisoning" poisoning of our name servers' cache or of name
> servers that our recursive queries are using for resolution of external
> sites (e.g. google.com, yahoo.com, billybob.com)?
>
> When you say allowing recursion is the issue are you saying that in the
> sense that there is a risk from internal sabotage as there is from
> internet hackers or are you saying simply having it on for internal
> users somehow also would allow internet hackers to exploit it?
>
> Reading your final paragraph makes it seem like you mean it is the
> latter.
>
> Just to make sure I understand recursion: My assumption is that this is
> necessary to do lookups for zones for which we are not authoritative
> like the examples above. Is that correct?

Essentially, yes. The problem is that your resolver, in going out to
get answers from authoritative servers elsewhere, is at risk of getting
a *forged* answer from a bad guy, containing bad information, and accepting
it as valid. It would then cache the bad information, and continue passing
it out to your clients for as long as the cache persists.

If any client, inside *or* outside your network, uses your server for
recursion, then your server is a potential target for this kind of attack.
And if it hasn't been updated with the patch, the attack may well succeed.

--
Evan Hunt -- evan...@isc.org
Internet Systems Consortium, Inc.

[Chris Buxton]

Jeff,

You haven't yet figured out the attack vector, or the goal of the
attack.

If your name server is used by client machines to look up outside
names, then your server is at risk. The risk is that someone will
manage to convincingly forge a response to your name server's outbound
query, thus causing your name server to believe something untrue and
cache it. This cached data is then used to attack you and your users,
e.g. directing you to the attacker's clone of PayPal instead of to the
real thing. (They still won't have a valid PayPal SSL certificate, but
if you don't put the "https://" into the URL in your browser, you may
never notice that.)

It doesn't matter if you have recursion restricted - as long as
recursion is enabled for some user, then your server is subject to
these attacks. If you turn it off, then it is not at risk. The attack
does not threaten the actual operation of the name server, it
threatens the pool of users who send recursive queries to the name
server.

However, that said, this attack is not new. The weakness addressed by
this latest patch is not some new revelation - it's something we in
the community have known about for years. It's just that Dan Kaminsky
is presenting a paper next month at Black Hat telling the world how to
exploit it.

To convince your name server that a bogus response is real and
correct, the attacker must get the following values right:

- The source address and port of the query.
- The destination address and port of the query.
- The query ID.
- The query name, class, and type.

If the attacker has a packet sniffer somewhere upstream of you, you're
dead in the water. He can sniff these values and forge a response on
the spot. Otherwise, however, he has to guess or determine all of that.

The source address of the query is, of course, your server's address.
If the attacker is trying to spoof paypal.com, then there is a small
number of destination addresses, the name servers for paypal.com, and
also the query name/class/type triplet is known. The destination port
is 53. These should be the only known quantities, ideally.

There have been several recent security updates to BIND relating to
the query ID not being sufficiently random. In fact, in some cases, a
low-traffic server's next query ID could be predicted accurately, over
and over.

Now we have publication of the fact (long-known by those of us who
teach this subject) that the source port used for queries is knowable
- all the attacker needs to do is set up a name server to be
authoritative for some zone, and then wait (or cause) your name server
to look up that data. His server will then log the source port used
for queries. Until this latest patch, BIND chooses a single source
port at startup and sticks with it. The latest patch makes this port
random for each query, although the side effects of this may be
intolerable for some installations. (If I may suggest to the folks at
ISC, perhaps an option to put a rate limit on the frequency of changes
- N times per second, for example - would solve this. And for
goodness' sake, be a little more aggressive about closing ports after
some time has passed.)

Combine a weak or predictable query ID with a known source port and
the attacker has an easy time spoofing a response - he just has to
keep sending responses to your server and wait for some valid user to
try to look up the targeted RRSet. (There is some effort required to
keep updating his knowledge of your query ID random number pool's
state, but in some cases that's not much of a barrier.)

Because these two variables are the only ones we can really
strengthen, it becomes very important for the DNS server vendors out
there to do so. Both values are constrained to 16-bit values, so we
max out the difficulty to a 32-bit random number - not very secure by
modern standards. As it was before this latest patch, however, it
became effectively a 16-bit random number once a small amount of
effort was completed.

Now consider the value of DNSSEC, in which we augment this with, say,
a 1024-bit cypher. Your (at best) 32-bit key has now become (at least)
a 1024-bit key. And it's all validated by multiple cross-checks.

Chris Buxton
Professional Services
Men & Mice

On Jul 11, 2008, at 10:21 AM, Jeff Lightner wrote:

> Thanks.
>
> Forgive me for being dense but I'm trying to understand.
>

> Is the "cache poisoning" poisoning of our name servers' cache or of
> name
> servers that our recursive queries are using for resolution of
> external
> sites (e.g. google.com, yahoo.com, billybob.com)?
>
> When you say allowing recursion is the issue are you saying that in
> the
> sense that there is a risk from internal sabotage as there is from
> internet hackers or are you saying simply having it on for internal
> users somehow also would allow internet hackers to exploit it?
>
> Reading your final paragraph makes it seem like you mean it is the
> latter.
>
> Just to make sure I understand recursion: My assumption is that
> this is
> necessary to do lookups for zones for which we are not authoritative
> like the examples above. Is that correct?
>

[Jeff Lightner]

Thanks.

-----Original Message-----
From: Evan Hunt [mailto:Evan...@isc.org]
Sent: Friday, July 11, 2008 2:30 PM
To: Jeff Lightner
Cc: Alan Clegg; bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

> Is the "cache poisoning" poisoning of our name servers' cache or of
name
> servers that our recursive queries are using for resolution of
external
> sites (e.g. google.com, yahoo.com, billybob.com)?
>
> When you say allowing recursion is the issue are you saying that in
the
> sense that there is a risk from internal sabotage as there is from
> internet hackers or are you saying simply having it on for internal
> users somehow also would allow internet hackers to exploit it?
>
> Reading your final paragraph makes it seem like you mean it is the
> latter.
>
> Just to make sure I understand recursion: My assumption is that this
is
> necessary to do lookups for zones for which we are not authoritative
> like the examples above. Is that correct?

Essentially, yes. The problem is that your resolver, in going out to

get answers from authoritative servers elsewhere, is at risk of getting
a *forged* answer from a bad guy, containing bad information, and
accepting
it as valid. It would then cache the bad information, and continue
passing
it out to your clients for as long as the cache persists.

If any client, inside *or* outside your network, uses your server for
recursion, then your server is a potential target for this kind of
attack.
And if it hasn't been updated with the patch, the attack may well
succeed.

--
Evan Hunt -- evan...@isc.org
Internet Systems Consortium, Inc.

[Jeff Lightner]

Thanks.

RHEL has released a patched version of the BIND 9.x they distribute.
I've already contacted management about the need to do this.

Since we're in the middle of a PCI compliance push it will likely be
easier for me to get this implemented than it might have been in the
past.

I saved the DNSSEC in 6 minutes PDF posted earlier and will look to
implement that long term beyond doing the patch.

Just so I have it straight:
The firewall change required is only to allow OUTBOUND random ports?
That is, the connection once established would stay on the port
initiated by my server and wouldn't require an INBOUND connect back on a
separate random port?

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On

Behalf Of Chris Buxton
Sent: Friday, July 11, 2008 2:38 PM
To: bind-...@isc.org Mailing List
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Jeff,

> Is the "cache poisoning" poisoning of our name servers' cache or of
> name
> servers that our recursive queries are using for resolution of
> external
> sites (e.g. google.com, yahoo.com, billybob.com)?
>
> When you say allowing recursion is the issue are you saying that in
> the
> sense that there is a risk from internal sabotage as there is from
> internet hackers or are you saying simply having it on for internal
> users somehow also would allow internet hackers to exploit it?
>
> Reading your final paragraph makes it seem like you mean it is the
> latter.
>
> Just to make sure I understand recursion: My assumption is that
> this is
> necessary to do lookups for zones for which we are not authoritative
> like the examples above. Is that correct?
>

> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of Alan Clegg

> Sent: Friday, July 11, 2008 12:44 PM
> To: bind-...@isc.org
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
> solution
>

> Jeff Lightner wrote:
>> I had thought turning off cache queries to external lookups was
>> sufficient. Are you saying this is needed in addition or that cache
>> query disabling had nothing to do with the cache poisoning?
>
> If your server is authoritative only, it is not at risk. If it is
> recursive, it is at risk.
>
> It's not allowing queries from outside your network that puts you at
> risk, it's doing recursion on behalf of others (internal or external)
> that opens you to the vulnerability.
>
> If you recurse, install new code and don't limit your queries to a
> single port.
>
>> Also as to the randomization - is this only for outbound responses?
> The
>> initial query would have to come on port 53 where named listens or
>> are
>> you saying that it somehow listens on random ports as well?
>
> This randomization is of queries being sent out from recursive servers
> on behalf of the system that sent the query with the recursion desired
> "RD" bit set.
>
> All DNS queries will have a destination of port 53. You just don't
> want
> all of the queries to have the same SOURCE port.
>
> AlanC

[Chris Buxton]

Correct. The new, random port is set by the outbound query as its
source port. The return response goes to the same port that the query
came from.

Chris Buxton
Professional Services
Men & Mice

[Kevin Darcy]

Evan Hunt wrote:
>> Is the "cache poisoning" poisoning of our name servers' cache or of name
>> servers that our recursive queries are using for resolution of external
>> sites (e.g. google.com, yahoo.com, billybob.com)?
>>
>> When you say allowing recursion is the issue are you saying that in the
>> sense that there is a risk from internal sabotage as there is from
>> internet hackers or are you saying simply having it on for internal
>> users somehow also would allow internet hackers to exploit it?
>>
>> Reading your final paragraph makes it seem like you mean it is the
>> latter.
>>
>> Just to make sure I understand recursion: My assumption is that this is
>> necessary to do lookups for zones for which we are not authoritative
>> like the examples above. Is that correct?
>>
>

> Essentially, yes. The problem is that your resolver, in going out to
> get answers from authoritative servers elsewhere, is at risk of getting
> a *forged* answer from a bad guy, containing bad information, and accepting
> it as valid. It would then cache the bad information, and continue passing
> it out to your clients for as long as the cache persists.
>
> If any client, inside *or* outside your network, uses your server for
> recursion, then your server is a potential target for this kind of attack.
> And if it hasn't been updated with the patch, the attack may well succeed.
>
>

Let's be clear here. The problem is *response*forgery*.

The fact that the forged responses may get into the cache and affect
future lookups only *amplifies* the problem. But even devices that don't
cache *at*all* (e.g. so-called "DNS proxies") can be affected by this issue.

There have been genuine "cache poisoning" issues in the past (e.g.
unrelated, malicious data in the Authority or Additional sections of a
response getting into caches), but this isn't one of them.

Frankly, the media, and even some of the technical experts quoted in the
media, have been doing a disservice, in my opinion, by constantly
describing this issue only as "cache poisoning".

Terminology matters.

- Kevin

[Kevin Darcy]

> query-source port 53;
> query-source-v6 port 53;

> allow-query { localhost; 192.168.10.0/24; };
> };
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> };
> };
> view localhost_resolver {
> match-clients { localhost; };
> match-destinations { localhost; };
> recursion yes;
> include "/etc/named.rfc1912.zones";
> };
>
> include "/etc/rndc.key";
>
> This file is same as named.caching-nameserver.com located at
> /var/named/chroot/etc.
>
> What I need to check now?
>

You have only one view and it's limited to "localhost".

So, your client boxes don't match any view.

- Kevin

[James Pratt]

> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of
> Kevin Darcy
> Sent: Friday, July 11, 2008 4:35 PM
> To: bind-...@isc.org
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution
>

> > If any client, inside *or* outside your network, uses your server
for
> > recursion, then your server is a potential target for this kind of
attack.
> > And if it hasn't been updated with the patch, the attack may well
succeed.
> >
> >
> Let's be clear here. The problem is *response*forgery*.
>
> The fact that the forged responses may get into the cache and affect
> future lookups only *amplifies* the problem. But even devices that
don't
> cache *at*all* (e.g. so-called "DNS proxies") can be affected by this
issue.
>
> There have been genuine "cache poisoning" issues in the past (e.g.
> unrelated, malicious data in the Authority or Additional sections of a
> response getting into caches), but this isn't one of them.
>
> Frankly, the media, and even some of the technical experts quoted in
the
> media, have been doing a disservice, in my opinion, by constantly
> describing this issue only as "cache poisoning".
>
> Terminology matters.
>
> - Kevin
>

I would agree about the media. Thank you very much for clarifying those
important bits.

So the big question really is - Is the security of the internet in
*real* big trouble after blackhat, unless dnssec is implemented
basically everywhere?

I understand it's great to have your own rr's secured, but it probably
doesn't help much at all internally if you *have to* give your lan/wan
clients recursion, correct?

Regards,
jamie

[Alan Clegg]

James Pratt wrote:
> So the big question really is - Is the security of the internet in
> *real* big trouble after blackhat, unless dnssec is implemented
> basically everywhere?

Security of the internet is not in trouble (depending on what you mean
by "security")...

The ability to know for sure that you are (or are not) talking to the
thing that you want to talk to is what is at (grave) risk.

DNSSEC is the "final" answer, but we can't deploy it globally in the
next 30 days (or less).

For now, randomize your query source ports. Please.

> I understand it's great to have your own rr's secured, but it probably
> doesn't help much at all internally if you *have to* give your lan/wan
> clients recursion, correct?

DNSSEC only helps if both the authoritative server and either the
upstream recursor or your applications have to be DNSSEC aware/validating.

AlanC

[Peter Laws]

Alan Clegg wrote:
> For now, randomize your query source ports. Please.

Is that something you have to positively do (i.e., not a default), or does
it happen automagically with the updated BIND(s)?

--
Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
-----------------------------------------------------------------------
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!

[Alan Clegg]

Peter Laws wrote:
>> For now, randomize your query source ports. Please.
>
> Is that something you have to positively do (i.e., not a default), or does
> it happen automagically with the updated BIND(s)?

It's automatic in 9.3.5-P1, 9.4.2-P1, and 9.5.0-P1 (and the current
betas) unless you tell it otherwise by using BAD things like:

udp-source port XX;

in your configuration.

Notice that if you have a line like the above in your current
configuration and are behind a firewall, there may be rules in place
that made that line necessary. Check with your firewall admin to make
sure that "random outbound UDP ports" are open from your nameserver to
the outside world.

AlanC

[James Pratt]

> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of
> Peter Laws
> Sent: Friday, July 11, 2008 6:00 PM
> To: bind-...@isc.org
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution
>

> Alan Clegg wrote:
> > For now, randomize your query source ports. Please.
>
> Is that something you have to positively do (i.e., not a default), or
does
> it happen automagically with the updated BIND(s)?
>
>

> --
> Peter Laws / N5UWY
> National Weather Center / Network Operations Center
> University of Oklahoma Information Technology
> pl...@ou.edu
>
-----------------------------------------------------------------------
> Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank
you!
>
>

Actually, no - you have to ensure that a "query-source port 53;" line
does not exist in your named.conf (I found this out via a posting
earlier. No one else mentioned it before, or I have been missing emails!
:(

Regards,
jamie

[Peter Laws]

James Pratt wrote:
> Actually, no - you have to ensure that a "query-source port 53;" line
> does not exist in your named.conf (I found this out via a posting
> earlier. No one else mentioned it before, or I have been missing emails!

Yeah, I actually read the docs (gasp!) and it does note that if it's not
specifically set, or if the port is set to '*', then it's random (for some
value of 'random'). I checked all mine, too, and it was never set.

Of course, I am working under the assumption that RedHat's version of BIND
is also random by default ... :-)

Thanks, all.

[Chris Buxton]

On Jul 11, 2008, at 11:37 AM, Chris Buxton wrote:
> However, that said, this attack is not new. The weakness addressed by
> this latest patch is not some new revelation - it's something we in
> the community have known about for years. It's just that Dan Kaminsky
> is presenting a paper next month at Black Hat telling the world how to
> exploit it.

After some private cage-rattling by Alan Clegg and others, I am
prepared to retract the statement above.

This is not a minor publication of a previously-known vulnerability,
the ability to brute-force the query id and thus forge a response.
This is a new, non-obvious but apparently intuitive method of
poisoning a cache.

I don't know enough about the exploit to be able to say definitively
whether it's truly a case of response forgery or not. I find it
interesting that Microsoft was compelled to release patches for both
the DNS service and the DNS client service (the stub resolver). I've
been told that glibc is also vulnerable, presumably insomuch as it
provides nscd.

Apparently upon being given the gist of the attack vector, without the
full details, other researchers were able to reproduce it in fairly
short order, so it's likely that the bad operators will be able to
exploit this in advance of the full disclosure next month.

Read this:
http://www.securityfocus.com/brief/772

Then go and patch your boxes, and start thinking about how you will
deploy DNSSEC.

[Jeff Lightner]

Peter,

RedHat has issued patched versions of BIND (including the bind-chroot)
RPMs.

Information from RedHat for the update to bind is at:
http://rhn.redhat.com/errata/RHSA-2008-0533.html

As noted by others you still have to take out the query port line from
named.conf and should still look at implementing DNSSEC long term.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Peter Laws
Sent: Friday, July 11, 2008 6:22 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Thanks, all.

[Michael Coumerilh]

Can I stick my nose in here and wonder if Apple will be sending
updates for their 10.3, 10.4, and 10.5 versions of OS X Server before
D-Day?
Mike

On Jul 11, 2008, at 5:12 PM, Alan Clegg wrote:

> Peter Laws wrote:
>>> For now, randomize your query source ports. Please.
>>
>> Is that something you have to positively do (i.e., not a default),
>> or does
>> it happen automagically with the updated BIND(s)?
>

[Baird, Josh]

Will BIND randomize query TCP source ports as well (when TCP is
required) with these new patches?

Thanks,

Josh

[Baird, Josh]

Ignore this.. I found my answer in the ARM:

" The address specified in the query-source option is used for both UDP
and TCP queries, but the port applies only to UDP queries. TCP queries
always use a random unprivileged port."

Thanks,

Josh

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Baird, Josh
Sent: Monday, July 14, 2008 8:28 AM
To: Michael Coumerilh; Alan Clegg
Cc: bind-...@isc.org
Subject: RE: Vulnerability to cache poisoning -- the rest of the
solution

[Jeff Lightner]

If that's the case why wouldn't we have needed to open firewall to allow
this behavior for tcp?

Thanks,

Josh

Thanks,

Josh

[Alan Clegg]

Jeff Lightner wrote:
> If that's the case why wouldn't we have needed to open firewall to allow
> this behavior for tcp?

You would have. Unless you never had (functional) DNS queries/transfers
over TCP.

AlanC

[Jeff Lightner]

OK maybe I missed something.

We were only allowing port 53 outside the firewall (confirmed by the
Network folks). We've been doing lookups for external sites fine
despite that. Was the discussion in current thread about that or
something else?

You mention transfer. The only transfers I'm aware of are on a
separate interface (internal DMZ) for zone transfers between master and
slave DNS servers.

Also my Network admin is asking for clarification of what needs to be
opened for the port randomization. He thinks it should only be ports
above 1024.
1) Is that correct? If not is there a range that is correct?
2) Is this udp AND tcp?
Earlier posts had led me to believe it was only udp but the current
thread makes it sound like it should be both.

He's ready to open whatever I tell him but I don't see any point in
opening up ports that won't be used.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Alan Clegg
Sent: Monday, July 14, 2008 10:44 AM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

AlanC

[Peter Laws]

Jeff Lightner wrote:
> OK maybe I missed something.
>
> We were only allowing port 53 outside the firewall (confirmed by the
> Network folks). We've been doing lookups for external sites fine
> despite that. Was the discussion in current thread about that or
> something else?

Are your *outbound* connections restricted by the firewall to udp/53? Or
was your security admin talking about *inbound* connections?

All the hullabaloo is about random source ports for DNS servers doing
recursive lookups on behalf of clients. The randomness of port choice has
been improved (hasn't it?) with the recent patches.

You also need to make sure your BIND config doesn't pin it to a particular
port (53 or otherwise).

[Jeff Lightner]

You ignored the rest of what I wrote apparently.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Peter Laws
Sent: Monday, July 14, 2008 12:15 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

[Peter Laws]

Jeff Lightner wrote:
> We were only allowing port 53 outside the firewall (confirmed by the
> Network folks). We've been doing lookups for external sites fine
> despite that. Was the discussion in current thread about that or
> something else?
>

53, 42, 10999, 63215, doesn't make any difference. But if it's always 53
or anything else you make the attackers job easier (and they thank you ...
or will on August 6).

> Also my Network admin is asking for clarification of what needs to be
> opened for the port randomization. He thinks it should only be ports
> above 1024.

If it's running as named, obviously you'd be restricted to ports named
could open, which are above 1024 generally. Otherwise, it's OS-dependent,
AFAIK. Seems to me Solaris will (or would in pre-10 days) only pick 32768
or above though it could be changed.

[Jeff Lightner]

I understand the theory so was seeking positive confirmation on the
specific questions I asked which still haven't been answered.

Someone stated positively that I couldn't have had queries or transfers
working with port firewall restricted to port 53 so I was looking for
more information about that statement as obviously my BIND is working.

Separately I was then also asking for details about what should be
opened for recursive queries. Is it udp only? Tcp & udp? Finally I
was asking for specific range information. That is if I tell it random
does that mean it automatically goes to ports above 1024. Further I
wanted to verify there wasn't anything in BIND that was restricting it
to a range as some applications do. That is to say is it complete
random or random within a range?

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Peter Laws
Sent: Monday, July 14, 2008 12:42 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

[Alan Clegg]

Jeff Lightner wrote:
> Someone stated positively that I couldn't have had queries or transfers
> working with port firewall restricted to port 53 so I was looking for
> more information about that statement as obviously my BIND is working.

Ok, prior to 9.5.0, BIND chose a high, random UDP port on startup and
used that for the life of the process for outbound queries.

9.5.0 improved that by choosing a small pool and changing port every 15
minutes.

-P1 introduced a per-query randomization across all available high ports.

The betas (9.5.1b2) and (9.4.3b1) allow fine-grained control for the UDP
ports used.

All of the above can be over-ridden using the (evil) "udp-source port
XX" statement in your configuration.

All BIND versions use high, random ports for TCP connections.

> Separately I was then also asking for details about what should be
> opened for recursive queries. Is it udp only? Tcp & udp? Finally I
> was asking for specific range information. That is if I tell it random
> does that mean it automatically goes to ports above 1024. Further I
> wanted to verify there wasn't anything in BIND that was restricting it
> to a range as some applications do. That is to say is it complete
> random or random within a range?

See above. Answer depends on "what version are you running?"

AlanC

[Jeff Lightner]

My intent is to use the patched version from RedHat. Their advisory on
the issue and update is at:
http://rhn.redhat.com/errata/RHSA-2008-0533.html

Specifically I'd be using what they call 9.3.4-6.0.2.P1. I think this
is basically 9.3.4-P1 but is customized by RedHat to include fixes from
later BIND versions. (See discussion with Adam Tkac of RedHat on list a
couple of weeks back about why he doesn't want to roll out later BIND
versions in updates.)

However, now I'm wondering if that will be sufficient. Their notes in
that link and the two bug links referred to within it seem to suggest
the change was only to take the offending query port restriction out of
their sample named.conf (and of course I'd have to take it out of my
live one). What you wrote makes me wonder if there wasn't a code
update needed to make it behave more like one of the later BIND versions
to do real port randomization.

It isn't clear to me whether or not they made any customization of the
code to address this or not.

I guess I'll try to update they have then run the dig test to see if it
really is giving me random ports at that point.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Alan Clegg
Sent: Monday, July 14, 2008 1:21 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

AlanC

[Lakes, Dale]

Latter day "stateful" firewalls will keep track of UDP connections in
their state tables.

No firewall reconfig was needed after I applied the -P1 patch.

Dale Lakes
Network Engineer
Antares Management Solutions

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Jeff Lightner
Sent: Monday, July 14, 2008 1:10 PM
To: Peter Laws; bind-...@isc.org
Subject: RE: Vulnerability to cache poisoning -- the rest of the
solution

I understand the theory so was seeking positive confirmation on the
specific questions I asked which still haven't been answered.

Someone stated positively that I couldn't have had queries or transfers

working with port firewall restricted to port 53 so I was looking for
more information about that statement as obviously my BIND is working.

Separately I was then also asking for details about what should be

opened for recursive queries. Is it udp only? Tcp & udp? Finally I
was asking for specific range information. That is if I tell it random
does that mean it automatically goes to ports above 1024. Further I
wanted to verify there wasn't anything in BIND that was restricting it
to a range as some applications do. That is to say is it complete
random or random within a range?

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Peter Laws
Sent: Monday, July 14, 2008 12:42 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
confidential information and is for the sole use of the intended
recipient(s). If you are not the intended recipient, any disclosure,
copying, distribution, or use of the contents of this information is
prohibited and may be unlawful. If you have received this electronic
transmission in error, please reply immediately to the sender that you
have received the message in error, and delete it. Thank you.
----------------------------------

http://www.antaressolutions.com/
Industry Expertise. Intelligent Solutions.
Visit http://www.antaressolutions.com/
CONFIDENTIALITY NOTICE:
This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message.
Thank you, Antares Management Solutions.

[Jeff Lightner]

or will on August 6).

> Also my Network admin is asking for clarification of what needs to be
> opened for the port randomization. He thinks it should only be ports
> above 1024.

If it's running as named, obviously you'd be restricted to ports named
could open, which are above 1024 generally. Otherwise, it's
OS-dependent,
AFAIK. Seems to me Solaris will (or would in pre-10 days) only pick
32768
or above though it could be changed.

--
Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
-----------------------------------------------------------------------
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

The information contained in this message and any attachment may be
proprietary, confidential, and privileged or subject to the work
product doctrine and thus protected from disclosure. If the reader
of this message is not the intended recipient, or an employee or
agent responsible for delivering this message to the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please notify me
immediately by replying to this message and deleting it and all
copies and backups thereof. Thank you.

[Jeff Lightner]

OK maybe I missed something.

We were only allowing port 53 outside the firewall (confirmed by the

Network folks). We've been doing lookups for external sites fine
despite that. Was the discussion in current thread about that or
something else?

You mention transfer. The only transfers I'm aware of are on a

separate interface (internal DMZ) for zone transfers between master and
slave DNS servers.

Also my Network admin is asking for clarification of what needs to be

opened for the port randomization. He thinks it should only be ports
above 1024.

1) Is that correct? If not is there a range that is correct?
2) Is this udp AND tcp?
Earlier posts had led me to believe it was only udp but the current
thread makes it sound like it should be both.

He's ready to open whatever I tell him but I don't see any point in
opening up ports that won't be used.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Alan Clegg
Sent: Monday, July 14, 2008 10:44 AM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Jeff Lightner wrote:
> If that's the case why wouldn't we have needed to open firewall to
allow
> this behavior for tcp?
You would have. Unless you never had (functional) DNS queries/transfers
over TCP.

AlanC

[Peter Laws]

Jeff Lightner wrote:
> OK maybe I missed something.
>
> We were only allowing port 53 outside the firewall (confirmed by the
> Network folks). We've been doing lookups for external sites fine
> despite that. Was the discussion in current thread about that or
> something else?

Are your *outbound* connections restricted by the firewall to udp/53? Or
was your security admin talking about *inbound* connections?

All the hullabaloo is about random source ports for DNS servers doing
recursive lookups on behalf of clients. The randomness of port choice has
been improved (hasn't it?) with the recent patches.

You also need to make sure your BIND config doesn't pin it to a particular
port (53 or otherwise).

--

Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
-----------------------------------------------------------------------
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!

The information contained in this message and any attachment may be

[Peter Laws]

Jeff Lightner wrote:
> We were only allowing port 53 outside the firewall (confirmed by the
> Network folks). We've been doing lookups for external sites fine
> despite that. Was the discussion in current thread about that or
> something else?
>

53, 42, 10999, 63215, doesn't make any difference. But if it's always 53
or anything else you make the attackers job easier (and they thank you ...

or will on August 6).

> Also my Network admin is asking for clarification of what needs to be
> opened for the port randomization. He thinks it should only be ports
> above 1024.

If it's running as named, obviously you'd be restricted to ports named

could open, which are above 1024 generally. Otherwise, it's OS-dependent,
AFAIK. Seems to me Solaris will (or would in pre-10 days) only pick 32768
or above though it could be changed.

--

[Jeff Lightner]

You ignored the rest of what I wrote apparently.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Peter Laws
Sent: Monday, July 14, 2008 12:15 PM
To: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Jeff Lightner wrote:
> OK maybe I missed something.
>

> We were only allowing port 53 outside the firewall (confirmed by the
> Network folks). We've been doing lookups for external sites fine
> despite that. Was the discussion in current thread about that or
> something else?

Are your *outbound* connections restricted by the firewall to udp/53?
Or
was your security admin talking about *inbound* connections?

All the hullabaloo is about random source ports for DNS servers doing
recursive lookups on behalf of clients. The randomness of port choice
has
been improved (hasn't it?) with the recent patches.

You also need to make sure your BIND config doesn't pin it to a
particular
port (53 or otherwise).

--

Peter Laws / N5UWY
National Weather Center / Network Operations Center
University of Oklahoma Information Technology
pl...@ou.edu
-----------------------------------------------------------------------
Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

The information contained in this message and any attachment may be

[Baird, Josh]

Is anyone else getting all kinds of duplicate messages that were sent
hours ago?

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On

Behalf Of Jeff Lightner
Sent: Monday, July 14, 2008 11:36 AM
To: Peter Laws; bind-...@isc.org

[Kyle McDonald]

Baird, Josh wrote:
> Is anyone else getting all kinds of duplicate messages that were sent
> hours ago?
>
>

And I thought it was only me.

-Kyle

[Alan Clegg]

Jeff Lightner wrote:
> If that's the case why wouldn't we have needed to open firewall to allow
> this behavior for tcp?
You would have. Unless you never had (functional) DNS queries/transfers
over TCP.

AlanC

The information contained in this message and any attachment may be

[Jeff Lightner]

I'm getting them too.

-Kyle

----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

[Vyto Grigaliunas]

Yep...

> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of Baird, Josh
> Sent: Monday, July 14, 2008 2:29 PM
> To: Jeff Lightner; Peter Laws; bind-...@isc.org
> Subject: RE: Vulnerability to cache poisoning -- the rest of the solution
>

> Is anyone else getting all kinds of duplicate messages that were sent
> hours ago?
>
>
>
>
>

> --
> Peter Laws / N5UWY
> National Weather Center / Network Operations Center
> University of Oklahoma Information Technology
> pl...@ou.edu
> -----------------------------------------------------------------------
> Feedback? Contact my director, Craig Cochell, cra...@ou.edu. Thank you!

> ----------------------------------
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> confidential information and is for the sole use of the intended
> recipient(s). If you are not the intended recipient, any disclosure,
> copying, distribution, or use of the contents of this information is
> prohibited and may be unlawful. If you have received this electronic
> transmission in error, please reply immediately to the sender that you
> have received the message in error, and delete it. Thank you.
> ----------------------------------
>
>
>

[Jeff Lightner]

If that's the case why wouldn't we have needed to open firewall to allow
this behavior for tcp?

-----Original Message-----

From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Baird, Josh

Sent: Monday, July 14, 2008 9:48 AM
To: Baird, Josh; Michael Coumerilh; Alan Clegg

Cc: bind-...@isc.org
Subject: RE: Vulnerability to cache poisoning -- the rest of the
solution

Ignore this.. I found my answer in the ARM:

" The address specified in the query-source option is used for both UDP
and TCP queries, but the port applies only to UDP queries. TCP queries
always use a random unprivileged port."

Thanks,

Josh

-----Original Message-----

From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Baird, Josh

Sent: Monday, July 14, 2008 8:28 AM
To: Michael Coumerilh; Alan Clegg

Cc: bind-...@isc.org
Subject: RE: Vulnerability to cache poisoning -- the rest of the
solution

Thanks,

Josh

[Baird, Josh]

Thanks,

Josh

Thanks,

Josh

[Baird, Josh]

[Jeff Lightner]

OK - did the RedHat yum update and modified my named.conf to remove the
port restriction.

The dig test indicated I used 26 different ports and said it was "GOOD".

Also ran tcpdump as suggested and confirmed it was showing multiple
ports on my queries whereas before everything indicated port 53.

Not seeing the CPU load issue others mentioned. I'll check it again in
the morning to see if it creeps up for any reason.

Thanks for all the help guys.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
Behalf Of Jeff Lightner
Sent: Monday, July 14, 2008 1:47 PM
To: Alan Clegg; bind-...@isc.org
Subject: RE: Vulnerability to cache poisoning -- the rest of the
solution

-----Original Message-----

From: bind-use...@isc.org [mailto:bind-use...@isc.org] On

Behalf Of Alan Clegg
Sent: Monday, July 14, 2008 1:21 PM
To: bind-...@isc.org

Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Jeff Lightner wrote:
> Someone stated positively that I couldn't have had queries or
transfers
> working with port firewall restricted to port 53 so I was looking for
> more information about that statement as obviously my BIND is working.

Ok, prior to 9.5.0, BIND chose a high, random UDP port on startup and
used that for the life of the process for outbound queries.

9.5.0 improved that by choosing a small pool and changing port every 15
minutes.

-P1 introduced a per-query randomization across all available high
ports.

The betas (9.5.1b2) and (9.4.3b1) allow fine-grained control for the UDP
ports used.

All of the above can be over-ridden using the (evil) "udp-source port
XX" statement in your configuration.

All BIND versions use high, random ports for TCP connections.

> Separately I was then also asking for details about what should be

> opened for recursive queries. Is it udp only? Tcp & udp? Finally I
> was asking for specific range information. That is if I tell it
random
> does that mean it automatically goes to ports above 1024. Further I
> wanted to verify there wasn't anything in BIND that was restricting it
> to a range as some applications do. That is to say is it complete
> random or random within a range?

See above. Answer depends on "what version are you running?"

AlanC

[Doug Barton]

Jeff Lightner wrote:
> If that's the case why wouldn't we have needed to open firewall to allow
> this behavior for tcp?

Most even relatively modern firewalls do "tcp keep state" by default,
so when named picked a random ephemeral port to do its query the
firewall handled it as designed.

Most modern firewalls have an option to do "udp keep state," which may
or may not be on by default. In an ideal world, you will want to use
this option with the new *-P1 versions of BIND, without specifying a
UDP port to bind to.

In the alternative, you can open all UDP ports >1024 to your name
server's IP address. In practice this should not be a problem since
you don't have anything but named and sshd on that box, right? Just in
case you do have something else running that needs to bind a UDP port
you can use the combination of avoid-*-udp-ports in named.conf and
firewall rules to block those specific ports, and allow all the others.

In the various beta versions of BIND there is an option to specify a
range of ports for named to use for outgoing UDP queries, which should
make it easier to configure the firewall.

hope this helps,

Doug

[Mark Andrews]

> I'm getting them too.
>
> -----Original Message-----
> From: Kyle McDonald [mailto:KMcD...@Egenera.COM]
> Sent: Monday, July 14, 2008 3:37 PM
> To: Baird, Josh

> Cc: Jeff Lightner; Peter Laws; bind-...@isc.org
> Subject: Re: Vulnerability to cache poisoning -- the rest of the
> solution
>

> Baird, Josh wrote:
> > Is anyone else getting all kinds of duplicate messages that were sent
> > hours ago?
> >
> >

> And I thought it was only me.
>
> -Kyle

It's a misconfigured Microsoft SMTPSVC pickup service that
sends to everyone in the To/Cc headers. We see this
periodically and kick the offending subscriber.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

[Mark Andrews]

> If that's the case why wouldn't we have needed to open firewall to allow
> this behavior for tcp?

No, because your firewall is most probably open for all
outgoing TCP connections or else FTP, HTTP to non standard
ports, etc. will not work. A stateless firewall can still
look at the flag bits in a TCP header and only allow a
connection to establish itself if it comes from inside.

UDP, being a connectionless protocol, needs the firewall
to keep state. To avoid having to keep state (or if you
only have a stateless firewall) one could configure named
to use a fixed port to make queries. The fixed port was
often choosen was 53 because named was usually also serving
zones and that meant only one hole in the firewall needed
to be open.

[Mark Andrews]

> Will BIND randomize query TCP source ports as well (when TCP is
> required) with these new patches?
>
> Thanks,
>
> Josh

TCP doesn't need to randomise the port. Your TCP stack
should be randomising the 32 bit TCP sequence number it
uses when establishing a connection. If it doesn't, get a
new OS as the one you have is ancient and full of security
holes.

This makes TCP much harder, but not impossible, to spoof
than UDP.

[G.W. Haywood]

Hi there,

On Tue, 15 Jul 2008, Mark Andrews wrote:

> > Will BIND randomize query TCP source ports as well (when TCP is
> > required) with these new patches?
>

> TCP doesn't need to randomise the port. Your TCP stack
> should be randomising the 32 bit TCP sequence number it
> uses when establishing a connection. If it doesn't, get a
> new OS as the one you have is ancient and full of security
> holes.
>
> This makes TCP much harder, but not impossible, to spoof
> than UDP.

As an interim measure, I take it that using TCP only isn't an option?

--

73,
Ged.

[Mark Andrews]

No. You have people that believe they can block TCP
connections to DNS servers despite the RFC's saying they
SHOULD be open.

[Kevin Darcy]

Mark Andrews wrote:
>> Hi there,
>>
>> On Tue, 15 Jul 2008, Mark Andrews wrote:
>>
>>
>>>> Will BIND randomize query TCP source ports as well (when TCP is
>>>> required) with these new patches?
>>>>
>>> TCP doesn't need to randomise the port. Your TCP stack
>>> should be randomising the 32 bit TCP sequence number it
>>> uses when establishing a connection. If it doesn't, get a
>>> new OS as the one you have is ancient and full of security
>>> holes.
>>>
>>> This makes TCP much harder, but not impossible, to spoof
>>> than UDP.
>>>
>> As an interim measure, I take it that using TCP only isn't an option?
>>
>
> No. You have people that believe they can block TCP
> connections to DNS servers despite the RFC's saying they
> SHOULD be open.
>

Well, more fundamentally than that, it would be a violation of RFC 1123
(Section 6.1.3.2 Transport Protocols: "DNS resolvers and recursive
servers MUST support UDP"), and TCP is a much bigger resource hog.

- Kevin

[Mark Andrews]

RFCs can be updated. If it was felt that the only way to
address this problem was to go to TCP then I'm sure that a
RFC could have made it through the review process in enough
time to stop complaints.

DNSSEC is the solution the IETF choose years ago to deal
with spoofed DNS traffic. It also deals with several other
problems including man in the middle attacks.

[G.W. Haywood]

Hi there,

On Tue, 15 Jul 2008, Mark Andrews wrote:

> > Will BIND randomize query TCP source ports as well (when TCP is
> > required) with these new patches?
>
> TCP doesn't need to randomise the port. Your TCP stack
> should be randomising the 32 bit TCP sequence number it
> uses when establishing a connection. If it doesn't, get a
> new OS as the one you have is ancient and full of security
> holes.
>
> This makes TCP much harder, but not impossible, to spoof
> than UDP.

As an interim measure, I take it that using TCP only isn't an option?

--

73,
Ged.

[Matthew Pounsett]

No, it isn't. The protocol isn't designed with TCP-only in mind --
TCP is meant to be a fallback. Removing UDP would spike the ~100ms
average lookup time up sharply (altering the user experience for
things like web browsing), and would significantly increase the load
on authoritative servers everywhere. My capital costs for managing an
authoritative zone would go up by more than double. It's safe to say
that any recursive server operator that switched to TCP-only, if they
were sending enough traffic my way to be noticed, would quickly find
themselves blackholed from my servers. I'm sure there are other
operators out there who would have a similar reaction.

Matt

[G.W. Haywood]

Hi there,

On Wed, 16 Jul 2008, Mark Andrews wrote:

> > >>> This makes TCP much harder, but not impossible, to spoof than UDP.
> > >>
> > >> As an interim measure, I take it that using TCP only isn't an option?
> > >

> > > No. You have people that believe they can block TCP
> > > connections to DNS servers despite the RFC's saying they
> > > SHOULD be open.
> > >
> > Well, more fundamentally than that, it would be a violation of RFC 1123
>

> RFCs can be updated. If it was felt that the only way to
> address this problem was to go to TCP then I'm sure that a
> RFC could have made it through the review process in enough
> time to stop complaints.

My point was of course that it might be easier to get something done
in a reasonable timeframe if it didn't involve getting people (well,
committees:) to agree on issues like who is to hold the keys.

I can't see how anyone can view the situation which we have at present
as anything other than a monumental cock-up.

--

73,
Ged.

[Jeff Lightner]

No committees.

So who would you appoint to be the Internet Tsar that issues edicts?

Like it or not sometimes you do have to work towards a consensus -
especially if you expect the majority of folks to decide to do it the
way its published.

-----Original Message-----
From: bind-use...@isc.org [mailto:bind-use...@isc.org] On

Behalf Of G.W. Haywood
Sent: Wednesday, July 16, 2008 4:24 AM
To: Mark Andrews
Cc: bind-...@isc.org
Subject: Re: Vulnerability to cache poisoning -- the rest of the
solution

Hi there,

--

73,
Ged.