Onderwerp: Has anyone implemented "double forward DNS"?

Double reverse DNS, which checks the name found using reverse DNS matches the
IP adrdess enquired about is now common. I was wondering wether about has
applied the same technique to forward DNS queries too.

The idea here is that a client that finds www.example.com is 192.168.3.42 does
not trist this infiormation. Instead it looks up 42.3.168.192.in-addr.arpa and
checks for a PTR record saying www.example.com. If one is not found then the
result is disinformation and should not be used. Of course if the bad guy also
controls the client's information about the reverse zone it still loses.

The major problem I can see is that there might that hosts in ISP's
dynamically allocated address pools might all fail double forward DNS checks.
OTOH if you were expecting your bank or a CA's server that might count as a
feature :-)

Browsers could implement this *now* and hopefully sreject at least some DNS
disinformation.

It would also help if web browser's displayed the information about who a
valid certifciate correspnonds to somewhere prominently instead of just a
padlock. My evil ID and banking detials theft site could have a valid
cetificate and therefore fool users who just check for a valid SSL certificate.

--
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."

On Sat, Aug 30, 2008 at 01:05:51AM +0100, Duncan Simpson wrote:
[...]
> Of course if the bad guy also controls the client's information
> about the reverse zone it still loses.

Under what circumstances do you expect the attacker to be able to
spoof/poison responses for one query but not the other?

> The major problem I can see is that there might that hosts in
> ISP's dynamically allocated address pools might all fail double
> forward DNS checks.
[...]

How about a the very common situation of name-based virtual hosting?
Do you propose a round-robin of multiple pointer resource records
for a single IP address, one for each domain hosted at that same
address? That could easily exceed a resolver's maximum response
length...
--
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fungi@yuggoth.org); IRC(fungi@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fungi@yuggoth.org);
MUD(fungi@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }

Duncan Simpson wrote:

[...]
> The idea here is that a client that finds www.example.com is 192.168.3.42 does
> not trist this infiormation. Instead it looks up 42.3.168.192.in-addr.arpa and
> checks for a PTR record saying www.example.com. If one is not found then the
> result is disinformation and should not be used. Of course if the bad guy also
> controls the client's information about the reverse zone it still loses.
[...]

Your proposal would cause a lot of trouble for sites using shared-ip
virtual webhosting (read many, perhaps most, sites) since it could
require potentially thousands (or more) of PTR records for each
shared-ip webserver IP (which would do nasty things to DNS in general).

--
Benjamin Franz

Duncan Simpson wrote:

> Double reverse DNS, which checks the name found using reverse DNS matches the
> IP adrdess enquired about is now common. I was wondering wether about has
> applied the same technique to forward DNS queries too.
>
> The idea here is that a client that finds www.example.com is 192.168.3.42 does
> not trist this infiormation. Instead it looks up 42.3.168.192.in-addr.arpa and
> checks for a PTR record saying www.example.com. If one is not found then the
> result is disinformation and should not be used. Of course if the bad guy also
> controls the client's information about the reverse zone it still loses.
>
> The major problem I can see is that there might that hosts in ISP's
> dynamically allocated address pools might all fail double forward DNS checks.
> OTOH if you were expecting your bank or a CA's server that might count as a
> feature :-)

The major problem I can see is that it's not at all uncommon to have
dozens or even hundreds of hostnames all resolve to a single IP
address belonging to a shared server. Requesting a PTR record for that
IP address typically isn't going to give you the hostname you started
with.

--
Glynn Clements <glynn@gclements.plus.com>

On 2008-08-30 Duncan Simpson wrote:
> Double reverse DNS, which checks the name found using reverse DNS
> matches the IP adrdess enquired about is now common. I was wondering
> wether about has applied the same technique to forward DNS queries
> too.
>
> The idea here is that a client that finds www.example.com is
> 192.168.3.42 does not trist this infiormation. Instead it looks up
> 42.3.168.192.in-addr.arpa and checks for a PTR record saying
> www.example.com. If one is not found then the result is disinformation
> and should not be used.

Wrong.

cobalt@chrome:~ $ host www.planetcobalt.net
www.planetcobalt.net CNAME chrome.planetcobalt.net
chrome.planetcobalt.net CNAME planetcobalt.net
planetcobalt.net A 217.10.9.49
cobalt@chrome:~ $ host 49.9.10.217.in-addr.arpa
49.9.10.217.in-addr.arpa PTR mail.planetcobalt.net
cobalt@chrome:~ $ host mail.planetcobalt.net
mail.planetcobalt.net A 217.10.9.49
cobalt@chrome:~ $ _

You can have multiple names resolving to the same IP address, but just
one PTR record mapping that address back to a name.

Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

.... ciao:

: on "8-30-2008" "Duncan Simpson" writ:
: The major problem ... in ISP's dynamically allocated address pools

ISPs that offer static address blocks, which do not reverse map would
present a more significant problem ...

--
.... i'm a man, but i can change,
if i have to , i guess ...

On 2008-09-03 Ansgar Wiechers wrote:
> On 2008-08-30 Duncan Simpson wrote:
>> Double reverse DNS, which checks the name found using reverse DNS
>> matches the IP adrdess enquired about is now common. I was wondering
>> wether about has applied the same technique to forward DNS queries
>> too.
>>
>> The idea here is that a client that finds www.example.com is
>> 192.168.3.42 does not trist this infiormation. Instead it looks up
>> 42.3.168.192.in-addr.arpa and checks for a PTR record saying
>> www.example.com. If one is not found then the result is disinformation
>> and should not be used.
>
> Wrong.
>
> cobalt@chrome:~ $ host www.planetcobalt.net
> www.planetcobalt.net CNAME chrome.planetcobalt.net
> chrome.planetcobalt.net CNAME planetcobalt.net
> planetcobalt.net A 217.10.9.49
> cobalt@chrome:~ $ host 49.9.10.217.in-addr.arpa
> 49.9.10.217.in-addr.arpa PTR mail.planetcobalt.net
> cobalt@chrome:~ $ host mail.planetcobalt.net
> mail.planetcobalt.net A 217.10.9.49
> cobalt@chrome:~ $ _
>
> You can have multiple names resolving to the same IP address, but just
> one PTR record mapping that address back to a name.

It was pointed out to me in private that, of course, you can have
multiple PTR records mapping one address to different names. My bad.

However, since oftentimes (colocation scenarios for instance) forward
and reverse zone have different maintainers, it's some hassle to keep
the reverse zone in sync with the forward zone. Thus I have my doubts
that proper reverse mappings for every name will become common practice
anytime soon.

Anyway, I apologize again for the misinformation in my previous mail.

Regards
Ansgar Wiechers
--
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq

On Thu, 2008-09-04 at 15:34 +0200, Ansgar -59cobalt- Wiechers wrote:

> It was pointed out to me in private that, of course, you can have
> multiple PTR records mapping one address to different names. My bad.
>
> However, since oftentimes (colocation scenarios for instance) forward
> and reverse zone have different maintainers, it's some hassle to keep
> the reverse zone in sync with the forward zone. Thus I have my doubts
> that proper reverse mappings for every name will become common practice
> anytime soon.

True, but there are other reasons why this is not such hot idea, as
outlined in the IETF draft "Considerations for the use of DNS Reverse
Mapping"[1]:

3.2 Utility and effectiveness of some reverse mapping uses

Especially in the absence of strong anti-spoofing
mechanisms, like the DNS Security Extensions, a check
for matching reverse DNS mapping should be regarded as
an extremely weak form of authentication. Even
moderately skilled attackers have available to them
tools to spoof DNS responses.
[...]


3.3 The difficulty with blanket policies
[...]
It is possible for there to be multiple PTRs at a single
reverse tree node. In extreme cases, these multiple
PTRs could cause a DNS response to exceed the UDP limit,
and fall back to TCP or otherwise exceed the DNS
protocol limits. Such a case could be one where the
advantages of reverse mapping are exceeded by the
disadvantages of the additional burden. This may be of
particular significance for "mass virtual hosting"
systems, where many hostnames are associated with a
single IP.

Oh, and just as you (and I) until recently thought that there should be
only one PTR for any given address, there is undoubtedly still software
out there that expects <= 1 PTR, so no telling will break (though that
should not be an overriding concern if the security benefits of proper
reverse checking were large enough).

[1] http://tools.ietf.org/html/draft-iet...siderations-06

Cheers,
Steven