Fasten your seatbelts, it's going to be a bumpy ride!

DNS flaw discoverer says more permanent fixes will be needed
Current patch options merely stopgaps; worst attacks likely on the way
http://www.computerworld.com/action/...4&pageNumber=1

Eagerly awaiting ZA's reaction

"Kayman" <kaymanDeleteThis@operamail.com> wrote in message
news:#slCVKg6IHA.3816@TK2MSFTNGP03.phx.gbl...
> DNS flaw discoverer says more permanent fixes will be needed
> Current patch options merely stopgaps; worst attacks likely on the way
> http://www.computerworld.com/action/...4&pageNumber=1
>
> Eagerly awaiting ZA's reaction

Well, good, because I'd hate to think the current state of patches are the
best we can do.

On Windows, we have an over-full netstat display, because DNS reserves 2500
ports; some services that haven't set the ReservedPorts registry key find
that their ports are sometimes (randomly) blocked by DNS reserving those
ports first.

On Linux, or other platforms using BIND, we have UDP-based daemons receiving
DNS responses on a random basis, because the DNS server accidentally picks
their port to send from.

"needs a little work" is a good description.

Alun.
~~~~
--
Texas Imperial Software | Web: http://www.wftpd.com/
23921 57th Ave SE | Blog: http://msmvps.com/alunj/
Woodinville WA 98072-8661 | WFTPD, WFTPD Pro are Windows FTP servers.
Fax/Voice +1(425)807-1787 | Try our NEW client software, WFTPD Explorer.

On Sat, 19 Jul 2008 23:37:07 -0700, Alun Jones wrote:

> "Kayman" <kaymanDeleteThis@operamail.com> wrote in message
> news:#slCVKg6IHA.3816@TK2MSFTNGP03.phx.gbl...
>> DNS flaw discoverer says more permanent fixes will be needed
>> Current patch options merely stopgaps; worst attacks likely on the way
>> http://www.computerworld.com/action/...4&pageNumber=1
>>
>> Eagerly awaiting ZA's reaction
>
> Well, good, because I'd hate to think the current state of patches are the
> best we can do.
>
> On Windows, we have an over-full netstat display, because DNS reserves 2500
> ports; some services that haven't set the ReservedPorts registry key find
> that their ports are sometimes (randomly) blocked by DNS reserving those
> ports first.
>
> On Linux, or other platforms using BIND, we have UDP-based daemons receiving
> DNS responses on a random basis, because the DNS server accidentally picks
> their port to send from.
>
> "needs a little work" is a good description.
>

Just a quick note...
http://www.doxpara.com/

Stay tuned

By the sound of things it's probably better NOT to apply these patches to
internal, non-internet-facing DNS servers, as if I read correctly they could
randomly interfere with other unrelated functions of the server.

Would you agree?

"Alun Jones" wrote:

> On Windows, we have an over-full netstat display, because DNS reserves 2500
> ports; some services that haven't set the ReservedPorts registry key find
> that their ports are sometimes (randomly) blocked by DNS reserving those
> ports first.
>
> On Linux, or other platforms using BIND, we have UDP-based daemons
> receiving DNS responses on a random basis, because the DNS server
> accidentally picks their port to send from.
>
> "needs a little work" is a good description.
>

"Anteaus" <Anteaus@discussions.microsoft.com> wrote in message
news:03F8E5CE-CA89-490D-9814-A8730407BF4E@microsoft.com...
> By the sound of things it's probably better NOT to apply these patches to
> internal, non-internet-facing DNS servers, as if I read correctly they
> could
> randomly interfere with other unrelated functions of the server.

I wouldn't say "yes" or "no" to any patch this soon after it's released,
without knowing your environment and the systems that will be patched.

As with all significant behaviour changes, you should test it in your
environment, and follow appropriate workarounds.

It's a good idea, in general, to indicate to the operating system that
certain applications have reserved ports using the ReservedPorts registry
key - whether you apply or don't apply this patch. That way other
applications besides DNS won't try to poach a port that's already in use -
as is shown by the example of BIND DNS servers, an application can quite
easily cause traffic to be directed to a service, if it isn't kept away from
reusing that socket, and ReservedPorts is the Windows way to do that across
multiple applications.

Test the patch in your environment, if you have multiple DNS servers, make
sure it doesn't adversely affect your operations, and then deploy the patch.

Expect another patch to DNS - but it might not be this month, or for a
couple of months. Don't hold off patching because "there might be another
patch", use this as an opportunity to solidify your DNS testing methodology,
so that you can test more quickly with the next patch, whenever that might
occur.

DNS is starting to really show its age.

Alun.
~~~~