In message <caaf6gdejb5nw40m4ew58vxwssmlzroeaxvb0vtptf_kfwd+...@mail.gmail.com> , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes: > On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan <a...@anvilwalrusden.com> wro > te: > > Also, it's not like it's terrifically onerous, although I know some > > registrars' web interfaces for this are messy and confusing. > > I do think that the policies of the .is GLTD are a net harm for DNS. > They require that DNS servers respond to queries they aren't > authoritative for (e.g. a SERVFAIL, or a REFUSED). Besides the > reflection attack risk, this also means the behavior-of-last-resort > should be respond "with an error": but I'd prefer to leave the > question unanswered in case another name server for the domain does > know how to serve the query. > > For example if a provider booted a box with an empty configuration, it > would be much better to timeout queries than respond with SERVFAIL or > REFUSED.
Actually timeout is much, much, much worse. Authoritatively say I am here, your query did not get lost, I don't have the answer you want lets recursive server move on to the next server without having to timeout the query. Delegation should never succeed unless you can get a SOA response for the zone being delegated from the nameservers being delegated to. How hard is it to make a SOA query to confirm that the zone is configured? That query should be followed using EDNS with a unknown option, and a unknown flag set. This query should also be responded to. If a OPT record is returned the rcode needs to be NOERROR and the unknown option and the unknown flag both need to not exist. If you got a OPT record with this second query you should send a third query with the EDNS version set to a unknown value. This should elicit a BADVERS response. It any of the EDNS queries timeout the nameserver is BROKEN and the delegation should not be permitted to proceed until the server is fixed. DNS is a query / response protocol. Responses are expected to queries. DNS COOKIES and other extension are going to be hard to deploy unless we start checking for and removing broken nameservers and firewalls from the ecosystem. Checking at delegation time is a good way to stop things getting worse. > -- > Colm > _______________________________________________ > dns-operations mailing list > dns-operations@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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@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
