Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-20395

[enterprise-4.12] Issue in file networking/dns-operator.adoc

XMLWordPrintable

    • Quality / Stability / Reliability
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • No
    • None
    • None
    • None
    • None
    • None
    • Release Note Not Required
    • N/A
    • None
    • None
    • None
    • None

       

      Description of problem:

       DNS Operator example for forwarder lists examples using real external DNS upstream servers (1.1.1.1 and 2.2.2.2 exist, and are managed by cloudflare). This implies that the service can and should be used to include external upstream dns for lookups on the platform, (errantly), instead of pointing to internal dns platform servers managed by customers. 

      Version-Release number of selected component (if applicable):

       all versions of doc

      How reproducible:

       every time - docs bug

      Additional info:

       The reason this is problematic is because it implies to customers that they can and should be setting up DNS on openshift to have 1 internal DNS server and 1 external upstream forwarder, implying that resolution will choose between both servers, or that there is fallthrough to allow lookups to check one source and if it fails, check the next. This is not how coreDNS works on openshift - we use the `forward` plugin which does not ignore an NXDOMAIN response (domain not found). 
      
      This means that if a customer has included an upstream external DNS server as one of their nameservers, and an internal as their secondary, a huge percentage of calls will fail, as the first nameserver in the ordered list will be queried first. The first nameserver to send back a reply (in this case, NXDOMAIN, not found) is considered a valid response, and the call is dropped resulting in a lookup failure. We do not support the `alternate` plugin at this time which would enable/allow fall-through on an NXDOMAIN response to continue checking the next server. Instead, the request is simply considered failed and must be retried.
      
      Please see this KCS for more information on why this fails: [[https://access.redhat.com/solutions/7038263]] 
      
      Recommended change --> modify the entry for the coreDNS example to `x.x.x.x` and `y.y.y.y` to avoid confusion (instead of including actual cloudflare DNS server addresses), and/or include a block entry regarding some of the details outlined in the KCS above, which indicates that this issue can occur if nameservers are not capable of succeeding a lookup for internal custom domains and this is a requisite for the platform. 
      
      Happy to discuss further as needed. Thank you!

      https://access.redhat.com/solutions/7038263

              rhn-support-wgabor Bill Gabor
              rhn-support-wrussell Will Russell
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: