Re: DNSSEC and ISPs faking DNS responses

[Mark Andrews <marka () isc org>]

In message <56455885.8090409 () vaxination ca>, Jean-Francois Mezei writes:
> The Québec government is wanting to pass a law that will force ISPs to
> block and/or redirect certain sites it doesn't like.  (namely sites that
> offer on-line gambling that compete against its own Loto Québec).
>
> In order to make a good submission to government, once has to boil it
> donw to simple enough arguments that clueless politicians can
> understand. And for me to do that, I want to make sure I understand this
> correctly.
>
>
> I have tried to research DNSSEC and while I understand how a proper DNS
> server can validate the chain from the
>  - root server
>  - TLD server
>  - authoritative DNS server for that domain
>
> I remain in dark with regartds to clients, namely clients who cannot
> trust the DNS server supplied as part of DHCP/IPCP/PPPoE responses.
>
>
> Say a consumer wants to connect to lottery.com,  which, from the world
> outside the ISP, would result in a signed, verifiable response.
>
> Can't the ISP's DNS server just pretend it is authoritative for
> lottery.com and return to client a non-DNSSEC response that points to a
> fake IP address ?

No.  If the client is validating the response it will fail validation.
 
> If the client gets an unsigned response for lottery.com from its ISP's
> DNS server,  how can it know it is a fake response, how can it know that
> lottery.com should have generated a signed DNSSEC response ?

Because it asks the ISP for DS lottery.com and that response tells
the client if it should be getting a signed response or not and
which DNSKEYs to trust.

> It seems to me that unless each client goes to the tld servers (they
> already have root signatures), get signature of the tld server and
> signed response of where "lotery.com" can be found, they have no way to
> know whether lottery.com should be signed or not, and whether the answer
> they got from their ISP is good or not.
>
> Is that a proper understanding ?

DNSSEC was designed to allow a client to get answers from a recursive
server it does not trust and verify that the answer has not been
tampered with.  There are not many clients that do this yet but that
was the design goal and yes it was achieved.

> So far, I have seen good explanations of what happens between DNS
> servers and the servers that are authoritative for domain, TLD and root.
> But I have seen nothing about clients who only have a resolver that
> talks to a DNS server.

They make the same queries and verify the answers the same way.

For lottery.com they would ask for the DNSKEY records for lottery.com,
the DS records for lottery.com, the DNSKEY records for com, the DS
records for com and the DNSKEY records for the root.  It doesn't
matter if these come from a cache or directly from the authoritative
servers.  The crypto to verify the answers is the same.

> And while I am at it: when a client gets a legit response from ISP's DNS
> server with RRSIG records, how does the client obtain the public key
> against which to run the record to ensure its calculated signature
> matches that provided in RRSIG ?

It asks for the DNSKEY records and RRSIGs.  Verifies them against the DS
records whick it asks for.  Repeat all the way to the root.
 
> or do DNS servers return the full chain of records so that a request for
> lottery.com returns not only record for lottery.com but also .com,s
> reply on where lottery.com is and root's reply of where .com is ?
>
>
> Hopefully, I am only missing a small bit that would explain everything
> that happens at the client side.  But as long as I am told that the
> client only talks to the ISP's DNS server, I am at a loss.
>
> Any help appreciated. (I just watched an hour long youtube on subject
> which didn't deal with client much).
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org