On Tue, May 02, 2023 at 7:43 PM, Havard Eidnes <h...@uninett.no> wrote:
> My parent says that the NS for exmple.com are ns1.example.com, ns2. > example.com , but I (example.com) say that my NS are ns1.example.com, ns2. > example.com *and* ns3.example.com. I don't (personally) think that this > is a lame delegation. Do others? > > Nope. Given this information, this is simply "inconsistent". > > If both ns1.example.com, ns2.example.com and ns3.example.com are > configured to serve the example.com zone, and return answers with aa=1 > when queried for names in that zone, all is well and there is no instance > of a "lame" delegation. > > However, if ns3.example.com isn't set up to serve the zone, and answers > queries about names in the zone with aa=0, the delegation to that name > server would be "lame". > > Flipped around: My parent says that the NS for exmple.com are ns1.example. > com, ns2.example.com *and* ns3.example.com. I (example.com) say that my > NS are only ns1.example.com and ns2.example.com. > > At this point I'd again say "inconsistent". > > If you query ns3.example.com, you get REFUSED. In that case I'd > (personally) say that ns3.example.com is lame for example.com. > > You had to put that in there? :) > > Thinking a bit about it: the REFUSED error code could be the result of > configuring a name server with recursion turned off, and if you then query > that name server about a name in a zone it is not set up to serve, a > REFUSED answer would be "natural" and is these days fairly common for such > a situation. > > Now, as to whether that's an instance of a lame delegation? I would tend > to say "yes". > > I don't think that I'd call example.com "lame", as both ns1 and ns2 work > OK. > > Correct. It's the particular delegation to ns3 which is "lame". > > Another example: if both the parent / delegating zone and the child zone > lists ns1.example.com, ns2.example.com and ns3.example.com, you have a > perfectly consistent delegation. However, if one of these are not set up to > serve the zone, the delegation of this zone to that particular name server > would be > "lame". > > I personally think that lameness is when a domain is delegated to a name > server, but that server does not have the zone configured. A corner case is > when the server is configured to not answer queries for that zone from that > source address, and so returns REFUSED or possibly SERVFAIL. > > If we're talking about the global DNS, restricting responses on a > publishing name server does not make much sense to me. > Well, perhaps - but it *is* a common deployment scenario. Many companies use ACLs and views (or similar) to expose something like corp.example.com, but only to "internal" IP addresses[0]. It's obviously easier to just have one set of nameservers, so if you query e.g www. example.com from the global Internet you get an address, but if you query e.g accounting.corp.example.com you get REFUSED. I slight variation on this is if the servers for example.com *do* answer the public Internet, but have a delegation to other servers which handle the corp.example.com zone, and these only answer queries from "inside" the organization. W [0]: Obviously you can't let just anyone on the Internets know that you have a server called e.g accounting.corp.example.com with the IP address of 192.168.13.24, because, um… well… erm.. no-one has ever really been able to explain the threat model to me, but they are all *sure* that the sky will fall if attackers know this… Often there is some allusion to "well, it may leak that we working on a magic hovercraft product, because they'd see a device called magic-hovercraft.new-products.corp.example.com <http://magic-hovercraft-v2.new-products.corp.example.com/>… ¯\_(ツ)_/¯ > Best, > > - Håvard >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
