Hugo Connery <[email protected]>于2018年12月1日周六 下午8:41写道：
> Hi Karl and list, > > No and Yes. > > The introduction section says "out of scope" not "there are > different attack vectors and operational concerns". > > ... and then I got to thinking. (sorry about that) > > But, I do agree that there are differences between the types > of attackers for recursers and authoritatives based on the > different outcomes of complete loss of service. > > Recursive resolvers serve a wide variety of stub resolvers > over varying operating systems from some network(s), which the > operator gets to choose, but the resolvers need to be within those > network(s). Some companies choose to offer recursive resolvers > that serve the entire internet (8.8.8.8, 1.1.1.1 etc.), but these > are currently the tiniest minority of recursive resolvers (*), > though this is likely to change with "recurser as a service". > The consequence of total failure of these resolver services for > the community within those network(s) is "the internet does > not work" (for them). > > So, a recursive operator chooses which community (via networks) > they serve, must be amongst those networks, and the consequence > of loss of service is "the internet does not work" for clients > within those networks. > > An authoritative server is different. It does not get to choose > its community. Ostensibly it is serving recursive resolvers (**), > but they could be anywhere, so this amounts to serving the > global internet. But, the authoritative servers can be in any > reachable network. The consequence of loss of all authoritative > resolvers for a collection of zones is that the services described > in its zones become increasingly globally unavailable as caches > of its records expire. > > So, an authoritative operator must serve the entire internet, > can be anywhere, and the loss of service is "these sites dont > work" progressively for everybody. > > >From this we can see who is motivated to attack what. By attack > I mean limit or completely prevent service delivery by > non-military actors. > > Notably, recursive resolvers that serve networks that are > limited geographically to a nation state have no defence > against the government of that nation state, but authoritatives > can skip around to avoid government attacks (aka laws). > recursive should send less sensitive data to authoritative servers. > > Many governments and corporations attack recursors for censorship > purposes with political and/or cultural motives (see "Pirate Bay"). > Authoritative regimes may wish to remove all (public) recursors > to create an internet blackout, but this is countered by (*) > above so they have to prevent access to the globally reachable > resolvers too (see "Great Firewall"). > > Authoritative resolvers may be attacked by extortionists for > money or miscreants for fame (see DDOS), or by competitors of > services described in the zone(s) for competitive advantage (see > "this is never published/I've got a furtive imagination"). > > So, yes the threat landscape is different because the consequences > of loss of service are different. > > Note that adding encryption or session based query services > for authoritatives changes none of this and is countered by > money (more CPU/RAM etc.). Obviously, authoritative operators > are legitimately motivated to minimize this burden (and should > carefully review proposed changes so that no new attacks methods > are admitted by new standards). > > One of the defences for authoritatives is to prioritise serving > recursive resolvers, as they are their legitimate clientele (**). > yes, authoritative can caculate a trust level to the query clients, to prior serve the "truely" recursive resolvers, which is learned from the query log. > > One can identify recursive resolvers because they will honour > your TTL values and will be a sparse collection of addresses > within network(s). This is not a perfect protection because > recursers can "go rogue" (cracked) or deliberately behave nicely > for a while (planned attack), but it should help with DDOS type > attacks that are not well planned. Similarly, you can grade > your deliberate refusal of service to network(s) when under attack > from them. Refuse service to all not already known recursers > for a while before refusing service to the entire network(s) > if the initial service restriction doesn't help. But, if that's > the case, you have a good idea who is attacking you from those > network(s). > > Regards, > > Hugo Connery > > On Fri, 2018-11-30 at 19:13 +0000, Henderson, Karl wrote: > > Hi Paul, > > > > The attack vectors and operational concerns are different for > communication between the recursive-to-authoritative than for communication > between the stub-to-recursive. For instance, a stub will > > typically communicate with one or two recursive resolvers while > recursive resolvers may communicate with many authoritative resolvers - > thus changing the nature of persistent TLS connections for > > this communication path. > > > > The authors of [RFC8310] recognized this difference and highlight it in > the Introduction section with this statement: > > > > "The proposals here might be adapted or extended in future to be used > for recursive clients and authoritative servers, but this application was > out of scope for the DNS PRIVate Exchange (dprive) > > Working Group charter at the time this document was published." > > > > Regards, > > Karl > > > > On 11/30/18, 12:34 PM, "Paul Wouters" <[email protected]> wrote: > > > > On Fri, 30 Nov 2018, Hollenbeck, Scott wrote: > > > > >> times have changed, and it deserves another look, but some note > that says > > >> "If running out of resources, drop the encryption and serve DNS > data in > > >> the clear might be needed". Ideally in a way that querying > clients that > > >> want to insist on privacy can bail out instead of receiving > cleartext. > > > > > > Possibly, but it may also be worth discussing how to avoid getting > into resource exhaustion situations in the first place. Do you have any > thoughts on Karl's "need for a profile of encryption > > standards" comment? > > > > I am not sure I see a need for a different TLS/DTLS profile compared > to > > regular (web) based (D)TLS connections. What do you or Karl think > would > > be different? > > > > Paul > > > > > > _______________________________________________ > > dns-privacy mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > -- > > > > Hugo Connery, Head of IT, DTU Environment > > "There is no cloud, only other people's computers". FSF > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > -- 致礼 Best Regards 潘蓝兰 Pan Lanlan
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
