Glue records returned as authoritative records by the server

[Siva Kesava R Kakarla]

Hi,

I was checking out TrustDns as an authoritative DNS server and gave it a small test zone as input.

example.com.	60480	SOA	ns1.outside.com. root.example.com. 3 604800 86400 2419200 604800
example.com.	60480	NS	ns1.outside.com.
b.g.example.com.	60480	NS	n.b.g.example.com.
n.b.g.example.com.	60480	A	1.1.1.1

For the query <n.b.g.example.com. , A>, the TrustDns server returns the following response:

          "rcode NOERROR",
          "flags QR AA",
          ";QUESTION",
          "n.b.g.example.com. IN A",
          ";ANSWER",
          "n.b.g.example.com. 60480 IN A 1.1.1.1",
          ";AUTHORITY",
          "example.com. 604800 IN NS ns1.outside.edu.",
          ";ADDITIONAL"

Expected behavior
The AA bit is set in the response, which should not be as this is a glue record and the zone file is not authoritative of it. The server should return an empty answer but place <b.g.example.com, NS> in the authority section (not the <example.com, NS> ) and the glue record in the additional section as per RFC 6672, Section 3.2, Point 3B.

System:

• OS: Ubuntu
• Architecture: x86_64
• Version: 18
• rustc version: cargo 1.47.0

[Benjamin Fry]

Yes, agreed. This is a test case we don't have covered right now in the code. I think this will require some better marking on the zone given the SOA and additional configuration options in the zone config toml.

The current zone file support is intended to be authoritative only, I don't think it would take a lot to expand it to this use case.

[Siva Kesava R Kakarla]

Thanks.

So, a zone file can not have delegations (NS records for children domains) in the currently supported version?

[Benjamin Fry]

Well, the bug you've filed would show that we're not properly setting the authoritative bit, and there isn't a work-around available (that I can think of) for that use case. So yes, until we add support for it, I think it's a limitation of the current server implementation.

[Siva Kesava R Kakarla]

Okay, thanks; I asked it again as I found cases like the following are also not handled properly, which involves the child NS records.
For the same zone file, consider the queries like <something.b.g.example.com, A> and <something.n.b.g.example.com, A>, the server returns:

         "rcode NXDOMAIN",
         "flags QR AA",
         ";QUESTION",
         "something.b.g.example.com. IN A",
         ";ANSWER",
         ";AUTHORITY",
         "example.com. 2419200 IN SOA ns1.outside.edu. root.campus.edu. 3 604800 86400 2419200 604800",
         ";ADDITIONAL"

Expected behavior
The AA bit is set in the response, which should not be set, and the status should not be NXDOMAIN. The proper response would be something like:

         "rcode NOERROR",
         "flags QR ",
         ";QUESTION",
         "something.b.g.example.com. IN A",
         ";ANSWER",
        ";AUTHORITY",
         "b.g.example.com. 60480 IN NS n.b.g.example.com.",
         ";ADDITIONAL",
         "n.b.g.example.com. 60480 IN A 1.1.1.1"

I hope this would be helpful for your test cases and future server implementation changes.
Thanks again for the quick responses and clarifications.

[Benjamin Fry]

If this is an area you'd be interested in contributing to, I'd be happy to point you to where the logic and test coverage for these things exist.

[Jonas Bushart]

I just ran into this problem as well. I'm still confused how Authority and the implementations like InMemoryAuthority work together, given that InMemoryAuthority has four functions (search, lookup, inner_lookup, inner_lookup_wildcard) which all work together and some are quire large.

I think it makes sense to consider splitting the correct lookup algorithm (as in RFC 6672, Section 3.2) from the database store and the query interface. What I mean is that we can have one piece of independent code which talks to a "database" and collects the required record. This piece of code then needs to handle walking the DNS tree, CNAME and DNAME records, wildcards, and delegations.
The "database" would be stupid and only respond to "exact" matches. So only if the query name is an exact hit, drastically simplifying this implementation.

This might not be the most performant implementation, since now we might need to ask multiple queries towards the "database" to create the final result set, for example for handling wildcards.
There is president in such an interface. Powerdns has the option to plug in different backends. One such kind is the Remote Backend, where Powerdns handles the DNS and speaks a JSON protocol with the backend ("database" in the above paragraph).
The communication protocol is described on this website:
https://doc.powerdns.com/authoritative/backends/remote.html

Powerdns then performs the lookup steps from RFC 6672. It checks for wildcards, it walks the DNS tree to see if and where delegations occur and so on.

Splitting the concern of record lookup into two pieces also makes it easier to update the RFC search code in case it needs updates, since only a single place needs to be touched instead of every "database" implementation.