dns-groot / ferret Goto Github PK

thanks for sharing this code, interesting!

I think DifferentialTesting/Implementations/main.py line 112-113 wants to pass the value False and not the string "False" to the run function... seems despite your annotations mypy flag find this issue because of the indirect call through globals dict...

Hi, thanks for your quick response to our question the other day. We continued along the line with our own testing framework, and found a further subtlety, concerning how Ferret currently handles type N records.

public static Zen<bool> NRecordCheck(Zen<IList<ResourceRecord>> nRecords, Zen<IList<ResourceRecord>> zoneRecords)
{
         return nRecords.All(nr => And(
                zoneRecords.Where(r => r.GetRName() == nr.GetRName()).Length() == 1,
                zoneRecords.Any(r => And(
                    Utils.IsPrefix(nr.GetRName(), r.GetRName()),
                    r.GetRType() != RecordType.N))));
}

As far as we are concerned, the above constraints enforce type N records at empty non-terminals. The logic is: an N record has a unique name, and is a proper prefix of a non-empty record.
However, consider the following zone (omitting root SOA/NS):

and query c.*.a. A. Problem is: as *.a. already exists as a wildcard record, it will not be added as a type N record even when b.*.a. exists. Yet, in record b.*.a. and query c.*.a., the asterisk is only an ordinary label, and thus the RFC response should be NXDOMAIN. In Ferret, as *.a. is a wildcard record, it would match and respond NOERROR.
This subtle behavior of wildcard DNS record is specified on wikipedia (the last section of "Example usages"). RFC 4592 Section 2.3 also hinted it.

What do you think?

Hi, we would like you to look at an issue in the ServerModel.cs implementation.

Consider the following zone file:

And query: c.%.a.example.com A
Now, Bind 9.18 would generate a NXDOMAIN response (as we've tested).

However, according to the logic in TestGenerator/Authoritative/ServerModel.cs, especially in the GetRelevantRRs() function:

public static Zen<IList<ResourceRecord>> GetRelevantRRs(Zen<Query> q, Zen<Zone> z)
        {
            Zen<IList<ResourceRecord>> relevantRecords = z.GetRecords().Where(r => Or(Utils.IsPrefix(r.GetRName(), q.GetQName()), Utils.IsDomainWildcardMatch(q.GetQName(), r.GetRName())));
            Zen<DomainName> zoneDomain = z.GetRecords().Where(r => r.GetRType() == RecordType.SOA).At(0).Value().GetRName();
            Zen<IList<ResourceRecord>> nsRelevantRecords = relevantRecords.Where(r => And(r.GetRType() == RecordType.NS, r.GetRName() != zoneDomain));
            Zen<IList<ushort>> maximalMatches = relevantRecords.Select(r => Utils.MaximalPrefixMatch(r.GetRName(), q.GetQName()));
            Zen<IList<ResourceRecord>> maxMaximalMatches = relevantRecords.Where(r => Utils.MaximalPrefixMatch(r.GetRName(), q.GetQName()) == MaxofList(maximalMatches));
            Zen<IList<ResourceRecord>> wildcardRecords = maxMaximalMatches.Where(r => Utils.IsDomainWildcardMatch(q.GetQName(), r.GetRName()));

            return If(
                relevantRecords.IsEmpty(),
                new List<ResourceRecord> { },
                If(
                    nsRelevantRecords.IsEmpty(),
                    If(
                        wildcardRecords.IsEmpty(),
                        maxMaximalMatches,
                        wildcardRecords),
                    nsRelevantRecords));
        }

relevantRecords would be either matching wildcard records, or existent records that are prefixes of the query. In the above case, relevantRecords should only contain the first three records, and because nsRelevantRecords doesn't accept NS records with the same name as the zone name, the returned records should contain only the wildcard record. And the final response from the model would be a NOERROR, the answer section of which is the wildcard AAAA record.

Having referred to RFC 1034 Section 4.3.2, we think that the intended behavior should be this: by matching down, label by label, the server should get to node a.example.com, an empty non-terminal. Then, because label % doesn't match and no wildcard is present, the matching should abort, and NXDOMAIN should be returned. Namely, the ServerModel.cs implementation looks incorrect to us.

We discovered this issue when testing with our reference DNS model that was based on the implementation in ServerModel.cs. What do you think?

I would like to introduce you to Technitium DNS Server project. Its an open source, cross platform, authoritative as well as recursive DNS server with support for encrypted DNS protocols and DNSSEC.

It would be great if you can you can spare some time and run tests on your setup for this project. I would really appreciate any feedback that you have.