[dns-operations] Everyone having their own resolver

Wed Feb 3 23:31:28 UTC 2016

In message <CAHw9_iLMmU2reVKT0TGotH15g3tt5NkXswTEC04MW8tMX_5bNg at mail.gmail.com>, Warren Kumari writes:
> 
> There are also some privacy implications for everyone running their own
> resolvers -- If / when DPRIVE becomes more deployed, you are likely to leak
> a bunch more information if you run your own resolver and do not talk to a
> caching recursive.
> 
> If you are doing DPRIVE, your answer may come (encrypted) from the cache,
> and if not, hopefully a: the attacker is not in a place to observe both
> incoming (encrypted) query and subsequent (currently not encrypted) cache
> fill query, and b: if they can, may not be able to perform side-channel
> attacks.
> If you have your own, local recursive, a: currently your query would not be
> encrypted (DPRIVE is not doing recursive to auth yet), and b: many
> name-servers only serve a small number of zones - the fact that you are
> contact ns1.example.com may leak what you are looking up (if ns1.example.co=
> m
> only serves a small number of zones)
> 
> W

But if you don't then you have no control over whether the recursive
server is validating or not.

DNSSEC *requires* that the recursive server validate or it does not
work in error/attack senarios.  For DNSSEC to work better the set
of trust anchors being used by the validating stub should be passed
to the recursive server so all validators are using the same trust
anchors to determine whether to reject/pass a answer.  Failure to
properly reject in the recursive server can result in a denial of
service occuring.

Adding DS records for the trust anchors (or equivalent e.g. type
code change to differentiate use) to the additional section of the
query would be one ways of doing this.  These would need to be
passed on upstream recursive queries as well.

Caching of answers in the recursive server still depends on the
trust anchors configured into the recursive server, not those learnt
via the query.  Obviously they are likely to be the same most of
the time so multiple validations should only occur during trust
anchor transitions.

Yes, this leaks the trust anchors in use.

> On Wed, Feb 3, 2016 at 1:31 PM Rick Wesson <rick at support-intelligence.com>
> wrote:
> 
> > openDNS provides an API into their data that you could leverage to answer
> > these and many other research questions. You should ask their CTO Dan
> > Hubbard.
> >
> > -rick
> >
> >
> > On Wed, Feb 3, 2016 at 9:20 AM, Paul Hoffman <phoffman at proper.com> wrote:
> >
> >> On 3 Feb 2016, at 7:41, Matthew Pounsett wrote:
> >>
> >> The existing infrastructure can probably handle it initially, sure .. bu=
> t
> >>> expect your domain registrations and DNS hosting to be an order of
> >>> magnitude more expensive.   Much of the authoritative infrastructure ha=
> s an
> >>> overhead multiplier built into its capacity, where the multiplier is
> >>> locally chosen based on the likelihood and impact of DDoS.  Some
> >>> infrastructures are built to handle over 100x the =E2=80=9Cnormal=E2=80=
> =9D traffic load.
> >>>
> >>> When the normal query rate sees an order (or two) magnitude jump, it
> >>> eats away that extra capacity built into the system, and everyone has t=
> o
> >>> scale up to get back their DDoS-eating overhead.
> >>>
> >>
> >> These are interesting bold statements, and I've heard similar over the
> >> past few years.
> >>
> >> Has anyone ever measured this? That is, there are a bunch of people on
> >> this very mailing list who have access to the caches and possibly even t=
> he
> >> query logs for Very Large Resolvers. It would be grand to see current
> >> research (or at least a list of good recent research) on what percentage=
>  of
> >> queries are for things in the long tail.
> >>
> >> --Paul Hoffman
> >> _______________________________________________
> >> dns-operations mailing list
> >> dns-operations at lists.dns-oarc.net
> >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> >> dns-jobs mailing list
> >> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> >
> >
> > _______________________________________________
> > dns-operations mailing list
> > dns-operations at lists.dns-oarc.net
> > https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> > dns-jobs mailing list
> > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> 
> --94eb2c0a91e8fb4bcd052ae213e8
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><div><br></div><div>There are also some privacy implicatio=
> ns for everyone running their own resolvers -- If / when DPRIVE becomes mor=
> e deployed, you are likely to leak a bunch more information if you run your=
>  own resolver and do not talk to a caching recursive.</div><div><br></div><=
> div>If you are doing DPRIVE, your answer may come (encrypted) from the cach=
> e, and if not, hopefully a: the attacker is not in a place to observe both =
> incoming (encrypted) query and subsequent (currently not encrypted) cache f=
> ill query, and b: if they can, may not be able to perform side-channel atta=
> cks.</div><div>If you have your own, local recursive, a: currently your que=
> ry would not be encrypted (DPRIVE is not doing recursive to auth yet), and =
> b: many name-servers only serve a small number of zones - the fact that you=
>  are contact <a href=3D"http://ns1.example.com">ns1.example.com</a> may lea=
> k what you are looking up (if <a href=3D"http://ns1.example.com">ns1.exampl=
> e.com</a> only serves a small number of zones)</div><div><br></div><div>W</=
> div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On=
>  Wed, Feb 3, 2016 at 1:31 PM Rick Wesson <<a href=3D"mailto:rick at support=
> -intelligence.com">rick at support-intelligence.com</a>> wrote:<br></div><b=
> lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
> #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" =
> style=3D"font-family:courier new,monospace">openDNS provides an API into th=
> eir data that you could leverage to answer these and many other research qu=
> estions. You should ask their CTO Dan Hubbard.</div></div><div dir=3D"ltr">=
> <div class=3D"gmail_default" style=3D"font-family:courier new,monospace"><b=
> r></div><div class=3D"gmail_default" style=3D"font-family:courier new,monos=
> pace">-rick</div><div class=3D"gmail_default" style=3D"font-family:courier =
> new,monospace"><br></div></div><div class=3D"gmail_extra"><br><div class=3D=
> "gmail_quote">On Wed, Feb 3, 2016 at 9:20 AM, Paul Hoffman <span dir=3D"ltr=
> "><<a href=3D"mailto:phoffman at proper.com" target=3D"_blank">phoffman at pro=
> per.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
> "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 3 Feb 20=
> 16, at 7:41, Matthew Pounsett wrote:<br>
> <br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">
> The existing infrastructure can probably handle it initially, sure .. but e=
> xpect your domain registrations and DNS hosting to be an order of magnitude=
>  more expensive.=C2=A0 =C2=A0Much of the authoritative infrastructure has a=
> n overhead multiplier built into its capacity, where the multiplier is loca=
> lly chosen based on the likelihood and impact of DDoS.=C2=A0 Some infrastru=
> ctures are built to handle over 100x the =E2=80=9Cnormal=E2=80=9D traffic l=
> oad.<br>
> <br>
> When the normal query rate sees an order (or two) magnitude jump, it eats a=
> way that extra capacity built into the system, and everyone has to scale up=
>  to get back their DDoS-eating overhead.<br>
> </blockquote>
> <br>
> These are interesting bold statements, and I've heard similar over the =
> past few years.<br>
> <br>
> Has anyone ever measured this? That is, there are a bunch of people on this=
>  very mailing list who have access to the caches and possibly even the quer=
> y logs for Very Large Resolvers. It would be grand to see current research =
> (or at least a list of good recent research) on what percentage of queries =
> are for things in the long tail.<span><font color=3D"#888888"><br>
> <br>
> --Paul Hoffman<br>
> _______________________________________________<br>
> dns-operations mailing list<br>
> <a href=3D"mailto:dns-operations at lists.dns-oarc.net" target=3D"_blank">dns-=
> operations at lists.dns-oarc.net</a><br>
> <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel=
> =3D"noreferrer" target=3D"_blank">https://lists.dns-oarc.net/mailman/listin=
> fo/dns-operations</a><br>
> dns-jobs mailing list<br>
> <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel=3D"nor=
> eferrer" target=3D"_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-=
> jobs</a></font></span></blockquote></div><br></div>
> _______________________________________________<br>
> dns-operations mailing list<br>
> <a href=3D"mailto:dns-operations at lists.dns-oarc.net" target=3D"_blank">dns-=
> operations at lists.dns-oarc.net</a><br>
> <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-operations" rel=
> =3D"noreferrer" target=3D"_blank">https://lists.dns-oarc.net/mailman/listin=
> fo/dns-operations</a><br>
> dns-jobs mailing list<br>
> <a href=3D"https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" rel=3D"nor=
> eferrer" target=3D"_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-=
> jobs</a></blockquote></div>
> 
> --94eb2c0a91e8fb4bcd052ae213e8--
> 
> --===============1376230152363728081==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
> --===============1376230152363728081==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org