On Mon, Mar 4, 2019 at 11:00 PM Paul Wouters <p...@nohats.ca> wrote: > On Tue, 5 Mar 2019, Mark Andrews wrote: > > >> On Tuesday, 5 March 2019 02:21:42 UTC Christopher Morrow wrote: > >>> can I ask, what happens when a domain is intentionally down though? For > >>> instance, take .eg... ~4yrs back? (maybe 5?) Someone requested that the > >>> master/shadow NS go down, hard. All public auth servers eventually (in > a > >>> day or so) went dark too. > > "If the recursive server is unable to contact the > authoritative servers for a query " > > So make the DNS server reachable, but return ServFail or NXDOMAIN. If > the owner doesn't cooperate and there is legal standing, talk to the > parent to do this for the delegation. > > this wasn't, near as I could tell, an option for the ccTLD in question. They lost their IP access, and were 'required' to disable their dns zone, their master was down hard from the internet's perspective, keeping anything else up wasn't really an option.
I don't know how long it takes to get ICANN to 'do something creative' for the root zone, but I'm guessing this isn't always feasible in normal timelines (hours to a day or so). > I don't think this draft stops a domain from being brought down > intentionally. > > i think it prolongs the data being available in a bunch of the cases I can imagine/have-seen. I think there's at least one case where it's likely grave harm could have come to the dns operator. :( I think what the draft does is attempt to guess at WHY a thing is changed, without an real data to back up the reasoning. this will mean the decision is wrong more than a small percent of the time. > >> i already raised that question, very far up-thread. got no answer. > >> > >>> If someone is 'ordered' to make a zone dark, there may be reasons for > that > >>> action, and real penalties if the request is not honored. > >>> Is this draft suggesting that the DNS operations folk go against the > wishes > >>> of the domain owner by keeping a domain alive after the auth servers > have > >>> become unreachable? How would a recursive resolver know that the auth > is > >>> down: "By mistake" vs: "By design" ? > > The DNS resolvers who want to accomodate their governments need to > manually override their resolvers anyway with new (forged) data. This > draft does not change that. > > If the owner itself wants to bring the domain down, they just need to > make its auth servers reachable. > > sometimes that's not possible :( and the expectation is that 'when the right ttl sets expire all of our records disappear as you requested" > If the DNS hoster wants to bring it down, they just need to modify the > data it serves resulting in NXDOMAIN, ServFail or 127.0.0.1 A records. > this is also not always possible :( > > I don't think the "4 years" is a realistic problem case. > > is the '4 years' here in reference to the .eg problem? in my example the '4 yrs' was: "when the incident happened" not "please keep my dns alive for 4 yrs without talking to me" > I can see how people want to get a few hours or a few days of usage > beyond the TTL to accomodate for errors. Although, it is likely that > moving up the error this way will also delay the error from being > detected before the extra time has expired, and we are just moving > the goal post with no effective gain. But in the case of a DDOS > attack, the draft's feature is surely useful. > > seems unlikely to be useful... even in the case of dos...really. (to me anyway) -chris
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
