Uploaded image for project: 'Network Edge'
  1. Network Edge
  2. NE-626

[Testing & CI] CI coverage to ensure DNS resolution works with major client libraries


    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None
    • CI coverage to ensure DNS resolution works with major client libraries
    • 8
    • False
    • False
    • Green
    • To Do
    • OCPPLAN-7878 - NetEdge - Maintainability and Debugability & Tech Backlog
    • OCPPLAN-7878NetEdge - Maintainability and Debugability & Tech Backlog
    • 100% To Do, 0% In Progress, 0% Done
    • Undefined
    • L
    • Sprint 223, Sprint 224, Sprint 225, Sprint 226, Sprint 227, Sprint 228, Sprint 229, Sprint 230, Sprint 231, Sprint 232, Sprint 233, Sprint 234, Sprint 235, Sprint 236, Sprint 237, Sprint 238
    • 0
    • 0.0

      Per the 4.6.30 Monitoring DNS Post Mortem, we should add E2E tests to openshift/cluster-dns-operator to reduce the risk that changes to our CoreDNS configuration break DNS resolution for clients.  

      To begin with, we add E2E DNS testing for 2 or 3 client libraries to establish a framework for testing DNS resolvers; the work of adding additional client libraries to this framework can be left for follow-up stories.  Two common libraries are Go's resolver and glibc's resolver.  A somewhat common library that is known to have quirks is musl libc's resolver, which uses a shorter timeout value than glibc's resolver and reportedly has issues with the EDNS0 protocol extension.  It would also make sense to test Java or other popular languages or runtimes that have their own resolvers. 

      Additionally, as talked about in our DNS Issue Retro & Testing Coverage meeting on Feb 28th 2024, we also decided to add a test for testing a non-EDNS0 query for a larger than 512 byte record, as once was an issue in bug OCPBUGS-27397.   

      The ultimate goal is that the test will inform us when a change to OpenShift's DNS or networking has an effect that may impact end-user applications. 

            gspence@redhat.com Grant Spence
            mmasters1@redhat.com Miciah Masters
            0 Vote for this issue
            5 Start watching this issue