[dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
marka at isc.org
Thu Sep 11 23:28:04 UTC 2014
In message <CAAF6GDeJb5Nw40M4Ew58vxWsSMLZrOEAXvB0VtpTf_kFwD+Qfg at mail.gmail.com>
, =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes:
> On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan <ajs at anvilwalrusden.com> wro
> > 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
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
DNS is a query / response protocol. Responses are expected to
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.
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations