Re: [dnsoverhttp] New draft: draft-hoffman-dns-over-http-00.txt

[Ted Hardie <[e-mail]>]

On Tue, Sep 20, 2016 at 3:37 PM, Paul Hoffman <[e-mail]>
wrote:

>
> https://blogplatform.example.com/, and it wants me to know the dns info
> for securedimages.example.com, what does it do in this mode?
>
>
> We're quite open to suggestions here. I would hope that the pushing would
> be done in the same way that it is done for other resources in H2.
>
>
>
In the server push case where the initial page is HTML containing
references to a bunch of resources, the server pushes the resources it
believes the client will need to render the HTML.  In your ID, you have a
different server provisioned by DHCP, RA, or config for resolving DNS
queries (the DNS API server is distinct from the content server, at least
as I read it now).  I'm not sure that use case and the server push use case
meld easily.

If you allow the content server to provision itself as a DNS API server,
then it could push resources, but you have a scoping problem, because it is
now a general-purpose recursive resolver.  That opens you up to some bad
attacks.  Imagine, for example,  that https://blogplatform.example.com/
references a resource at a quasi-competitor, https://likeengine.example/.
The first server can push a DNS answer that applies to all of
likeengine.example's resources.  The naive attack here blackholes
likeengine.example, but there are more subtle attacks, like giving you a
correct address for likeengine.example that happens to be pessimal (like
one at their datacenter on a different continent).  That can't be corrected
by DNSSEC, since it is correctly signed.

For the server push case, I pretty much assume that the only trusted DNS
resources from https://blogplatform.example.com/ will be those related to
example.com (hello, public suffix list and dbound!)  To fit that use case,
you'd need to have the DNS API server scoped in this case and unscoped in
other cases.

regards,

Ted