search

k8gb-io / coredns-crd-plugin

CoreDNS plugin to use DNSEndpoint custom resource.
Apache License 2.0
21 stars 7 forks source link

Current implementation of AAAA queries handling (#8) violates RFCs #11

Closed somaritane closed 3 years ago

somaritane commented 3 years ago

According to RFCs (https://tools.ietf.org/rfcmarkup?doc=2308#section-2.2, https://tools.ietf.org/html/rfc6147#section-5.1.2, https://tools.ietf.org/html/rfc4074#section-3), coredns-crd-plugin should respond with NODATA (=RCODE 0 (NoError)+empty answer section), in case if AAAA requests are not supported, especially if there's A type of record available:

https://tools.ietf.org/html/rfc4074#section-3:

3.  Expected Behavior

    Suppose that an authoritative server has an A RR but has no AAAA RR
    for a host name.  Then, the server should return a response to a
    query for an AAAA RR of the name with the response code (RCODE) being
    0 (indicating no error) and with an empty answer section (see
    Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
    there is at least one RR of a different type than AAAA for the
    queried name, and the stub resolver can then look for A RRs.

    This way, the caching server can cache the fact that the queried name
    has no AAAA RR (but may have other types of RRs), and thus improve
    the response time to further queries for an AAAA RR of the name.

After recent change brought by #8, coredns-crd-plugin now returns RCODE 3 (NxDomain) for AAAA DNS queries.

This behavior is marked as problematic in RFCs:

https://tools.ietf.org/html/rfc4074#section-4.2:

4.2.  Return "Name Error"

    This type of server returns a response with RCODE 3 ("Name Error") to
    a query for an AAAA RR, indicating that it does not have any RRs of
    any type for the queried name.

    With this response, the stub resolver may immediately give up and
    never fall back.  Even if the resolver retries with a query for an A
    RR, the negative response for the name has been cached in the caching
    server, and the caching server will simply return the negative
    response.  As a result, the stub resolver considers this to be a
    fatal error in name resolution.

https://tools.ietf.org/html/rfc6147#section-5.1.2:

   It is important to note that, as of this writing, some servers
   respond with RCODE=3 to a AAAA query even if there is an A record
   available for that owner name.  Those servers are in clear violation
   of the meaning of RCODE 3, and it is expected that they will decline
   in use as IPv6 deployment increases.

If #8 addresses a corner case of particular DNS infra not behaving according to standards, then this behavior should be at least made optional, and disabled by default.