> On 7 Apr 2023, at 07:13, Havard Eidnes <he=40uninett...@dmarc.ietf.org> wrote: > >> What I'm trying to suggest (resolver perspective), is that >> questions of responsibility, ... are not something a resolver >> can or should attempt to determine. All one can attempt to do >> is classify query responses. > > Yes, I agree, as far as a recursive resolver is concerned. > > However, talking about a "delegation being lame" also revolves > around the domain owner responsibilities, but have the "resolver- > detected" behaviour as background. > >>> Hmm, in the response to >>> >>> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. aaaa >>> >>> I think the only real problem is the absence of the "aa" flag in the >>> response, especially since you get it in the response to >>> >>> dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a >> >> Well, one would, in fact, expect a delegation to be a non-authoritative >> answer: > > Yes, but one would presume that before any of the two above > queries were sent, the recursive resolver already have cached the > delegation for jshsos.ksyunv5.com. > > Therefore, posting a question about a name in that zone to one of > the name servers supposedly serving that zone would be expected > to elicit an authoritative response, and not a non-authoritative > delegation response. Therefore, in this instance, the "lameness" > would apparently depend on the queried-for RR type -- the "A" > query response looks ~fine (save for the EDNS0 mis-handling), > while the "AAAA", "NS" or "SOA" ones do not.
This sort of behaviour happens when you have a front end (load balancer) that intercepts some queries and answers them but leaves the rest of the queries to a complete nameserver that is not configured to serve the zones that where delegated to it. This is almost certainly a misconfigured F5 box. The backend is serving ksyunv5.com <http://ksyunv5.com/>. There is a good chance that the backend is running BIND but it could be any full implementation. It needed to have been configured to serve jshsos.ksyunv5.com <http://jshsos.ksyunv5.com/> as that is the delegation that was followed to reach it. In this case the parent and child are operated by the same entity. Yes, we (ISC) have complained many times to F5 about this broken behaviour. >>> This smells of a "roll your own" DNS name server implementation which >>> doesn't even correctly implement the required minimum of the DNS >>> standards. >>> >>> Clearly, the name lzd.jshsos.ksyunv5.com exists in the DNS name space >>> (ref. the "a" response), and the name server being queried here should >>> obviously be authoritative for the jshsos.ksyunv5.com zone, so the >>> "aa" flag should be set in the reply to the "aaaa" query. >> >> Definitely, but that's extrinsic knowledge that the resolver can't infer >> from just the current query response. > > Well, yes and no, ref. above -- the resolver should already have > the knowledge about the supposed name servers for the zone via > the actual delegation from the parent zone, and getting a non-AA > response from one of the delegated-to name servers would indicate > a problem, and would in my book earn the "lame" label. > >>> If I'm not terribly mistaken, this sort of mis-behaviour is all too >>> common among the CDN crowd, and I dearly wish we could stomp it out. >> >> Shall we? Please lead the way! > > A couple of questions: Do we have a spec of what a minimally > conformant publishing name server needs to implement? Yes. STD 13 (RFC 1034 and RFC 1035). RFC 1033 should also be read. Those 3 RFCs where designed to be read together. Part of the problem is that F5 isn’t trying to produce minimal nameserver. They are producing a box that intercepts queries and punts the rest to a box that does implement a full nameserver and when there is a configuration error you get answers like that. Now RFC 1033 has "COMPLAINTS These are the suggested steps you should take if you are having problems that you believe are caused by someone else's name server: 1. Complain privately to the responsible person for the domain. You can find their mailing address in the SOA record for the domain. 2. Complain publicly to the responsible person for the domain. 3. Ask the NIC for the administrative person responsible for the domain. Complain. You can also find domain contacts on the NIC in the file NETINFO:DOMAIN-CONTACTS.TXT 4. Complain to the parent domain authorities. 5. Ask the parent authorities to excommunicate the domain.” As an industry we have ignored the need for there to be checks and balances. RFC 1033 says that they should be there. > And > secondly, do we have any inkling whether all or most of these > CDNs use a common codebase, or is it all truly "roll your own"? > And if there is a dominant codebase, do we have an inkling what > it is? > > Best regards, > > - Håvard > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
