assured dns resolutions (secure)

i don't know if technology already exists to do this... but is it posisble
to add assurance for dns resolutions between a machine and an external
dns server.

the assurance may come from the fact that when that dns servers ip address
is added to /etc/resolv/conf the administrator also adds details of a
public/private key. as such, subsequent requests are then known to have
onlycome from THAT dns server and not spoofed, and also that the responce
has not been modified during transit.

t

I personally support the two tier concept of technology... all the paranoids
can run their systems, their way, and the remainder of us will ignore the
paranoids and their systems.

"project2501" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) r...
> i don't know if technology already exists to do this... but is it posisble
> to add assurance for dns resolutions between a machine and an external
> dns server.
>
> the assurance may come from the fact that when that dns servers ip address
> is added to /etc/resolv/conf the administrator also adds details of a
> public/private key. as such, subsequent requests are then known to have
> onlycome from THAT dns server and not spoofed, and also that the responce
> has not been modified during transit.
>
> t

until someone spoofs the dns responce and your online banking or
webmail session is redirected to another host which received your forms
and keystrokes.




On Mon, 19 Jul 2004 05:33:47 -0700, PC wrote:

> I personally support the two tier concept of technology... all the paranoids
> can run their systems, their way, and the remainder of us will ignore the
> paranoids and their systems.
>
> "project2501" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed) r...
>> i don't know if technology already exists to do this... but is it posisble
>> to add assurance for dns resolutions between a machine and an external
>> dns server.
>>
>> the assurance may come from the fact that when that dns servers ip address
>> is added to /etc/resolv/conf the administrator also adds details of a
>> public/private key. as such, subsequent requests are then known to have
>> onlycome from THAT dns server and not spoofed, and also that the responce
>> has not been modified during transit.
>>
>> t

Put forth in writing here, exactly how you think this will occur, and
exactly how you came to understand the depths of dns manipulation. Also
state if yourself, or your employer will cash in on your selling of paranoia
in this information group.

By documenting your paranoia in detail, then anyone who understands DNS, can
show you the error of your beliefs.

"project2501" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) r...
>
> until someone spoofs the dns responce and your online banking or
> webmail session is redirected to another host which received your forms
> and keystrokes.
>
>
>
>
> On Mon, 19 Jul 2004 05:33:47 -0700, PC wrote:
>
> > I personally support the two tier concept of technology... all the
paranoids
> > can run their systems, their way, and the remainder of us will ignore
the
> > paranoids and their systems.
> >
> > "project2501" <(E-Mail Removed)> wrote in message
> > news(E-Mail Removed) r...
> >> i don't know if technology already exists to do this... but is it
posisble
> >> to add assurance for dns resolutions between a machine and an external
> >> dns server.
> >>
> >> the assurance may come from the fact that when that dns servers ip
address
> >> is added to /etc/resolv/conf the administrator also adds details of a
> >> public/private key. as such, subsequent requests are then known to have
> >> onlycome from THAT dns server and not spoofed, and also that the
responce
> >> has not been modified during transit.
> >>
> >> t
>

simple - watch a network's traffic - watch the dns requests go by. watch
the responces. when you want to spoof, craft rely packets purporting to
come from the real dns server, but containing false ip resolution
information. inject these into the network and your successrate at
diverting network clients to use the false IP is not insiginificant.

many more details at:
http://members.ozemail.com.au/~98765...s_spoofing.pdf
http://www.cs.princeton.edu/sip/news/sun-02-22-96.html
http://www.menandmice.com/9000/9211_dns_spoofing.html
http://www.google.co.uk/search?q=dns...e+Search&meta=


i reapeeat my request for comments on current solutions and their relative
advantages and disadvantages...

p


On Mon, 19 Jul 2004 09:25:09 -0700, PC wrote:

> Put forth in writing here, exactly how you think this will occur, and
> exactly how you came to understand the depths of dns manipulation. Also
> state if yourself, or your employer will cash in on your selling of paranoia
> in this information group.
>
> By documenting your paranoia in detail, then anyone who understands DNS, can
> show you the error of your beliefs.
>
> "project2501" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed) r...
>>
>> until someone spoofs the dns responce and your online banking or
>> webmail session is redirected to another host which received your forms
>> and keystrokes.
>>
>>
>>
>>
>> On Mon, 19 Jul 2004 05:33:47 -0700, PC wrote:
>>
>> > I personally support the two tier concept of technology... all the
> paranoids
>> > can run their systems, their way, and the remainder of us will ignore
> the
>> > paranoids and their systems.
>> >
>> > "project2501" <(E-Mail Removed)> wrote in message
>> > news(E-Mail Removed) r...
>> >> i don't know if technology already exists to do this... but is it
> posisble
>> >> to add assurance for dns resolutions between a machine and an external
>> >> dns server.
>> >>
>> >> the assurance may come from the fact that when that dns servers ip
> address
>> >> is added to /etc/resolv/conf the administrator also adds details of a
>> >> public/private key. as such, subsequent requests are then known to have
>> >> onlycome from THAT dns server and not spoofed, and also that the
> responce
>> >> has not been modified during transit.
>> >>
>> >> t
>>

Most of the spoofing stories are a hoax based on paranoia, or conceived by
someone that doesn't run a system.

A good domain name server is read only, thus any incoming requests can only
read and can't write/change the existing data.

As example, a simple solution is to keep the primary domain name server
behind a wall, and use the secondary dns as public access and read only. The
secondary pulls data and updates from the primary.

People get their brain muddled with dumb phrases like `Authoritative' and
`Non Authoritative', rather than looking at `Read Only' and `Read/Write'
access.

Another example, if you connect to an ISP, the DHCP of the ISP tells your
machine what the DNS IP addresses are... thus read only works.

There is the other point of a dns, and that is forwarding a request that
can't be resolved by the first dns. In the above example of your ISP, if the
ISP's dns can't resolve a request, it will automaticly forward the request
to another dns which again can be read only.

The problem with the paranoids is, they choose to see a problem, then want
to patch it, then see another problem, then want to patch it, then see
another problem and then want to patch it... and it goes on and on, until
their endless solutions are the real problem and the original issue was
trivial with an easy solution.

"project2501" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) ...
>
> simple - watch a network's traffic - watch the dns requests go by. watch
> the responces. when you want to spoof, craft rely packets purporting to
> come from the real dns server, but containing false ip resolution
> information. inject these into the network and your successrate at
> diverting network clients to use the false IP is not insiginificant.
>
> many more details at:
> http://members.ozemail.com.au/~98765...s_spoofing.pdf
> http://www.cs.princeton.edu/sip/news/sun-02-22-96.html
> http://www.menandmice.com/9000/9211_dns_spoofing.html
>
http://www.google.co.uk/search?q=dns...tnG=Google+Sea
rch&meta=
>
>
> i reapeeat my request for comments on current solutions and their relative
> advantages and disadvantages...
>
> p
>
>
> On Mon, 19 Jul 2004 09:25:09 -0700, PC wrote:
>
> > Put forth in writing here, exactly how you think this will occur, and
> > exactly how you came to understand the depths of dns manipulation. Also
> > state if yourself, or your employer will cash in on your selling of
paranoia
> > in this information group.
> >
> > By documenting your paranoia in detail, then anyone who understands DNS,
can
> > show you the error of your beliefs.
> >
> > "project2501" <(E-Mail Removed)> wrote in message
> > news(E-Mail Removed) r...
> >>
> >> until someone spoofs the dns responce and your online banking or
> >> webmail session is redirected to another host which received your forms
> >> and keystrokes.
> >>
> >>
> >>
> >>
> >> On Mon, 19 Jul 2004 05:33:47 -0700, PC wrote:
> >>
> >> > I personally support the two tier concept of technology... all the
> > paranoids
> >> > can run their systems, their way, and the remainder of us will ignore
> > the
> >> > paranoids and their systems.
> >> >
> >> > "project2501" <(E-Mail Removed)> wrote in message
> >> > news(E-Mail Removed) r...
> >> >> i don't know if technology already exists to do this... but is it
> > posisble
> >> >> to add assurance for dns resolutions between a machine and an
external
> >> >> dns server.
> >> >>
> >> >> the assurance may come from the fact that when that dns servers ip
> > address
> >> >> is added to /etc/resolv/conf the administrator also adds details of
a
> >> >> public/private key. as such, subsequent requests are then known to
have
> >> >> onlycome from THAT dns server and not spoofed, and also that the
> > responce
> >> >> has not been modified during transit.
> >> >>
> >> >> t
> >>
>

thank you for taking the time... however this doesn't adress the issue of
forged/modified replies injected into a network.

i have seen in an a practical excercise to subvert the DNS resoltuion of
web browser lookups.




On Wed, 21 Jul 2004 20:45:01 -0700, PC wrote:

> Most of the spoofing stories are a hoax based on paranoia, or conceived by
> someone that doesn't run a system.
>
> A good domain name server is read only, thus any incoming requests can only
> read and can't write/change the existing data.
>
> As example, a simple solution is to keep the primary domain name server
> behind a wall, and use the secondary dns as public access and read only. The
> secondary pulls data and updates from the primary.
>
> People get their brain muddled with dumb phrases like `Authoritative' and
> `Non Authoritative', rather than looking at `Read Only' and `Read/Write'
> access.
>
> Another example, if you connect to an ISP, the DHCP of the ISP tells your
> machine what the DNS IP addresses are... thus read only works.
>
> There is the other point of a dns, and that is forwarding a request that
> can't be resolved by the first dns. In the above example of your ISP, if the
> ISP's dns can't resolve a request, it will automaticly forward the request
> to another dns which again can be read only.
>
> The problem with the paranoids is, they choose to see a problem, then want
> to patch it, then see another problem, then want to patch it, then see
> another problem and then want to patch it... and it goes on and on, until
> their endless solutions are the real problem and the original issue was
> trivial with an easy solution.
>
> "project2501" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed) ...
>>
>> simple - watch a network's traffic - watch the dns requests go by. watch
>> the responces. when you want to spoof, craft rely packets purporting to
>> come from the real dns server, but containing false ip resolution
>> information. inject these into the network and your successrate at
>> diverting network clients to use the false IP is not insiginificant.
>>
>> many more details at:
>> http://members.ozemail.com.au/~98765...s_spoofing.pdf
>> http://www.cs.princeton.edu/sip/news/sun-02-22-96.html
>> http://www.menandmice.com/9000/9211_dns_spoofing.html
>>
> http://www.google.co.uk/search?q=dns...tnG=Google+Sea
> rch&meta=
>>
>>
>> i reapeeat my request for comments on current solutions and their relative
>> advantages and disadvantages...
>>
>> p
>>
>>
>> On Mon, 19 Jul 2004 09:25:09 -0700, PC wrote:
>>
>> > Put forth in writing here, exactly how you think this will occur, and
>> > exactly how you came to understand the depths of dns manipulation. Also
>> > state if yourself, or your employer will cash in on your selling of
> paranoia
>> > in this information group.
>> >
>> > By documenting your paranoia in detail, then anyone who understands DNS,
> can
>> > show you the error of your beliefs.
>> >
>> > "project2501" <(E-Mail Removed)> wrote in message
>> > news(E-Mail Removed) r...
>> >>
>> >> until someone spoofs the dns responce and your online banking or
>> >> webmail session is redirected to another host which received your forms
>> >> and keystrokes.
>> >>
>> >>
>> >>
>> >>
>> >> On Mon, 19 Jul 2004 05:33:47 -0700, PC wrote:
>> >>
>> >> > I personally support the two tier concept of technology... all the
>> > paranoids
>> >> > can run their systems, their way, and the remainder of us will ignore
>> > the
>> >> > paranoids and their systems.
>> >> >
>> >> > "project2501" <(E-Mail Removed)> wrote in message
>> >> > news(E-Mail Removed) r...
>> >> >> i don't know if technology already exists to do this... but is it
>> > posisble
>> >> >> to add assurance for dns resolutions between a machine and an
> external
>> >> >> dns server.
>> >> >>
>> >> >> the assurance may come from the fact that when that dns servers ip
>> > address
>> >> >> is added to /etc/resolv/conf the administrator also adds details of
> a
>> >> >> public/private key. as such, subsequent requests are then known to
> have
>> >> >> onlycome from THAT dns server and not spoofed, and also that the
>> > responce
>> >> >> has not been modified during transit.
>> >> >>
>> >> >> t
>> >>
>>

In article <(E-Mail Removed)> , project2501 wrote:

I _wish_ you guys would figure out that top posting makes it
difficult to read your post, especially when the thread is a week old
[Post reformated]

> simple - watch a network's traffic - watch the dns requests go by. watch
> the responces. when you want to spoof, craft rely packets purporting to
> come from the real dns server, but containing false ip resolution
> information. inject these into the network and your successrate at
> diverting network clients to use the false IP is not insiginificant.
>
> many more details at:
> http://members.ozemail.com.au/~98765...s_spoofing.pdf
> http://www.cs.princeton.edu/sip/news/sun-02-22-96.html
> http://www.menandmice.com/9000/9211_dns_spoofing.html

OK, that assumes a 10Base2 or 10Base5 network, or 10BaseT using a hub.
If there is an Etherswitch, you won't see the requests or the replies,
because the switch won't send them to dis-interested parties. Sure, you
can get into the switch, and co-opt it, but that's a bit harder to do.

Now, in answer to your basic question, please have a look at RFC2535 and
the related RFCs.

2535 Domain Name System Security Extensions. D. Eastlake 3rd. March
1999. (Format: TXT=110958 bytes) (Obsoletes RFC2065) (Updates
RFC2181, RFC1035, RFC1034) (Updated by RFC2931, RFC3007, RFC3008,
RFC3090, RFC3226, RFC3445, RFC3597, RFC3655, RFC3658, RFC3755,
RFC3757) (Status: PROPOSED STANDARD)

Abstract

Extensions to the Domain Name System (DNS) are described that provide
data integrity and authentication to security aware resolvers and
applications through the use of cryptographic digital signatures.
These digital signatures are included in secured zones as resource
records. Security can also be provided through non-security aware
DNS servers in some cases.

>thank you for taking the time... however this doesn't adress the issue of
>forged/modified replies injected into a network.
>
>i have seen in an a practical excercise to subvert the DNS resoltuion of
>web browser lookups.

Depends on how serious the network administrators are. In the 1970s and
1980s, this didn't occur (as evidenced by the almost complete lack of
security features in older protocols and services), because networked
computers were generally at important companies (where they could fire
your butt), and universities where the punishment was loss of computer
privlidges (which meant you flunked the course). The previous company
I worked at had a fairly Draconian set of rules about that, and they
were enforced. For example, non-company computers were simply
confiscated, and the disks wiped. Under normal circumstances, you'd
get the empty computer back when you picked up your last pay check,
provided you were not arrested for other problems.

Old guy