On Mon, Apr 10, 2023 at 5:13 PM, Mats Dufberg < mats.dufberg=40internetstiftelsen...@dmarc.ietf.org> wrote:
> > > > mats> For the *delegation* to be lame it is not enough for one name > mats> server to be ``broken''. The entire set must be such that the path > mats> to the child zone content is not available. > > mats> For individual name servers it could be meaningful that say that > mats> it is a *lame name server* in relation to a certain zone. > > Paul> I like this distinction. Agree that calling just one server not > working > Paul> is a lame name server. > > Paul> Still want better clarity for lame delegation on if we really care > why > Paul> we aren't getting auth/AA responses from at least one nameserver. > If no > Paul> listed nameserver gives auth/AA, I'd call that a clear criteria for > lame > Paul> delegation, regardless of the underlying reason, at least as far as > a > Paul> recursive server should care. > > Paul> Humans debugging may care but I don't see a "better" definition of > lame > Paul> server really informs that debugging process. > > > > I agree with you. The first step is to see that > > the delegation is lame or the server is lame. That is > > enough to conclude that the service is not provide at > > all (lame delegation) or from that server (lame server, > > repectively. > > > > The second step is to analyze why – no IP address avaiable, > > the IP address not reachable, server not responding with > > a DNS response, unexpect RCODE value or not authoritative. > <no hats> I'm not the sharpest knife in the drawer / brightest bunny in the bunch / <insert your favorite option here>, so I'm trying to make sure that I actually understand these. I suspect that we only need a definition that is "good enough", and that trying to cover all corner cases is a losing proposition, but I'd appreciate it if y'all can let me know if I've gotten the below correct / where you disagree…. Let's start with this from the parent side: $ dig ns example.com ;; ANSWER SECTION: example.com. 21600 IN NS a.example.net example.com. 21600 IN NS b.example.com Ok, fair. Now, let's make up some failures: Scenario 1 - Unreachable servers: —------------- a.example.net 1800 IN A 10.0.0.1 ;; an unreachable address b.example.com 1800 IN A 10.0.0.2 ;; another unreachable address Q: I'm assuming that this is a lame delegation, yes? But is a.example.net a "lame server"? I have no way of reaching it, so I cannot tell if it would answer correctly if e.g: I queried from 10.0.0.3. Scenario 2 - Classically lame: —------------- a.example.net 1800 IN A 192.0.2.1 ;; a reachable address. b.example.com 1800 IN A 10.0.0.2 ;; another unreachable address $ dig example.net @a.example.net ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14273 Q: I'm assuming that this is a lame delegation, yes? I'm also assuming that a.example.net is a lame server, yes? Phew. Scenario 3 - Split views are fun!: —------------- Same as scenario 1 or 2, but let's pretend that the name is something like foo.corp.example.com, and Example Corp uses split-views. If I query from inside the enterprise I get an answer of 192.0.2.53, but from the Internet I get REFUSED, because views… Q: Is the server "lame"? Can / should we say "it's a lame server from the Internet, but not lame from specific addresses"? Scenario 4 - I know a guy who knows a guy...: —------------ $ dig NS example.net @a.example.net ;; ANSWER SECTION: . 518400 IN NS a.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. … Doh! Upwards referral. Q: I'm assuming that the delegation is lame, and the server is lame, yes? Scenario 5 - ¯\_(ツ)_/¯: —----------------------------------------------------------- $ dig www.example.net @a.example.net ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58056 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 $ dig www.example.net @b.example.com www.example.net 600 IN A192.0.2.1 Q: I'm assuming that the delegation is not lame, yes? I'm assuming that b.example.com is not a lame server, yes? I'm assuming that a.example.net is, erm, well, busticated in some other way, yes? Or can we call this lame? What if instead of www.example.net, the name I was querying was www.foo.example.net, and there was an "internal" delegation from example.net to foo.example.net (with NS of a.example.net and b.example.com), and b.example.com was correctly configured, but someone forgot to do that on a.example.net — that makes a.example.net a lame delegation, doesn't it? (foo.example.com is delegated to it, but it doesn't "know" that). I suspect that the proposals are more than good enough, but I was wondering if we'd all apply them in the same way in all of these cases… W </no hats> > > > And the second step is for how to resolve the lameness. > > > > > > Yours, > > > > Mats > > > > --- > > Mats Dufberg > > mats.dufb...@internetstiftelsen.se > > Technical Expert > > Internetstiftelsen (The Swedish Internet Foundation) > > Mobile: +46 73 065 3899 > > https://internetstiftelsen.se/ > > > > > > > > _______________________________________________ > 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
