secure (g)libc gethostbyname

i wonder what the state of secure dns resolution at the client side is
within the (g)libc libraries.

i know that dnssec allows secure (authenticated) zone transfers.

i also know that dnssec allows a chain of trust to be established using
PKI ... but i'mnot sure if this chain ends at your ISP/nearest dns server.

does the client side (libc) allow this chain of trust ot extend to it so
that the communication between the dns requestor and the nearest dns
server is authenticated, validated and possibly encrypted.

that is - at install time, the administraor adds the secret which
identifies the nearest dns server (when writing /etc/resolv.conf). this
way, no dns answers are accepted from other hosts and also spoofing is
prevented too. encyrption of teh actual payload is optional.

is there support for this or is it planned?

t

I see that you are still selling your paranoia !


"project2501" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) r...
> i wonder what the state of secure dns resolution at the client side is
> within the (g)libc libraries.
>
> i know that dnssec allows secure (authenticated) zone transfers.
>
> i also know that dnssec allows a chain of trust to be established using
> PKI ... but i'mnot sure if this chain ends at your ISP/nearest dns server.
>
> does the client side (libc) allow this chain of trust ot extend to it so
> that the communication between the dns requestor and the nearest dns
> server is authenticated, validated and possibly encrypted.
>
> that is - at install time, the administraor adds the secret which
> identifies the nearest dns server (when writing /etc/resolv.conf). this
> way, no dns answers are accepted from other hosts and also spoofing is
> prevented too. encyrption of teh actual payload is optional.
>
> is there support for this or is it planned?
>
> t
>

project2501 <(E-Mail Removed)> writes:


Just a comment-- gethostbyname is gone. It is now getaddrinfo which is all
of the old gethost stuff rolled into one and make IP6 useable.
But as to your main question, I do not know. it would seem to make it a bit
fragile, since dns servers go down, and one wants backup servers.


]i wonder what the state of secure dns resolution at the client side is
]within the (g)libc libraries.

]i know that dnssec allows secure (authenticated) zone transfers.

]i also know that dnssec allows a chain of trust to be established using
]PKI ... but i'mnot sure if this chain ends at your ISP/nearest dns server.

]does the client side (libc) allow this chain of trust ot extend to it so
]that the communication between the dns requestor and the nearest dns
]server is authenticated, validated and possibly encrypted.

]that is - at install time, the administraor adds the secret which
]identifies the nearest dns server (when writing /etc/resolv.conf). this
]way, no dns answers are accepted from other hosts and also spoofing is
]prevented too. encyrption of teh actual payload is optional.

]is there support for this or is it planned?

]t

On Mon, 02 Aug 2004 08:23:09 -0700, PC wrote:

> I see that you are still selling your paranoia !


here is a very recent artcile on why DNS security is an issue:

http://news.com.com/2102-1002_3-5291...=st.util.print

The article is more cultured paranoia.

My original argument stands, use a read only dns. In order for a dns to
send/recieve `covert' data, it needs to have some intelligence about the
`covert' data or it can't process.

In order for a machine to send/receive `covert' data, it requires a valid
return address.

Most firewalls, nat routers log all ip's and port numbers for incoming and
outgoing traffic, therefore a spoofed address is not going to return the
data.

Can these crackers or spammers be caught, you bet, but that isn't good for
business, when they can sell paranoia and abuse!


"project2501" <(E-Mail Removed)> wrote in message
news(E-Mail Removed) r...
> On Mon, 02 Aug 2004 08:23:09 -0700, PC wrote:
>
> > I see that you are still selling your paranoia !
>
>
> here is a very recent artcile on why DNS security is an issue:
>
> http://news.com.com/2102-1002_3-5291...=st.util.print