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 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" ? -chris On Mon, Mar 4, 2019 at 6:25 PM Puneet Sood <puneets= 40google....@dmarc.ietf.org> wrote: > Tim, Paul, > > Thanks for the feedback. Working on clarifying the recommendations. > > -Puneet > > On Sun, Mar 3, 2019 at 8:34 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > >> "Proposal: Put all recommendations in Section 4, and talk about them >> (instead of introducing them) in the other sections. That way, a lazy >> developer who only reads Section 4 will know all the recommendations." >> >> I totally agree here. It also makes it easier if the document passed >> WGLC and moves along the standards process train. >> > >> Tim >> >> >> On Fri, Mar 1, 2019 at 2:51 PM Paul Hoffman <paul.hoff...@icann.org> >> wrote: >> >>> Following up on my previous message: >>> >>> The document is actively confusing about recommendations. >>> >>> - Section 4 has the actual update to the RFC 1035, and that update >>> contains MAY and SHOULD statements. >>> >>> - Section 5 is called "Example Method" but also contains recommendations. >>> >>> - Section 6, "Implementation Caveats" also has recommendations. A >>> subsection, "6.1. Implementation Considerations" has more recommendations. >>> >>> Proposal: Put all recommendations in Section 4, and talk about them >>> (instead of introducing them) in the other sections. That way, a lazy >>> developer who only reads Section 4 will know all the recommendations. >>> >>> --Paul Hoffman >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
