Ok, so we had a registrant with the following: luckyconnect.co.za
NS ns3.rsa-tel.co.za NS ns4.rsa-tel.co.za and rsa-tel.co.za NS ns1.luckyconnect.co.za NS ns2.luckyconnect.co.za Classic glueless recursive mess-up. I was seeing notable traffic on co.za Auth's from 172.253.* 74.125.* and 2a00:1450:400a:* 2800:3f0:4003:* trying to resolve the above two zones. I'm assuming they're related to 8.8.8.8? once the registrant updated the NS's for one zone, breaking the glueless recursion, it went away. (and yeah - maybe I'm throwing away another bug bounty). regards --Calvin Browne On 15/04/2020 16:33, Dave Lawrence wrote: > Calvin Browne writes: >> does anyone here know how 8.8.8.8 handles recursive glueless situations? > The Google folks are on the list and undoubtedly will answer, but I'm > still curious about what even prompts the question. > > If it's actually missing glue -- NS records that are under the > delegation point -- and the delegating NS RRset does not include any > independent NSs, then the protocol itself doesn't have an intrinsic > mechanism for forward progress. A resolver should SERVFAIL its > client, perhaps with the "Code 22 - No Reachable Authority" extended > error code. > > Are you seeing something that suggests Google DNS is making some > additional effort to continue? > > >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
