0

Let's say I have a zone example.com in route53 which contains this record:

foo.sub.example.com A 1.2.3.4

in that same example.com zone, I also have a delegation and thus NS records for the sub.example.com subzone. The sub.example.com zone does NOT contain a foo.sub.example.com A record; the parent does.

Now, I've noticed that, with this setup, requests for foo.sub.example.com A fail because (seen with dig +trace) the resolution process ends up searching the subzone, instead of stopping at the parent zone where the record does exist.

From my research, I couldn't find a reference, RFC or standard that mandates this behavior, yet that's how it seems to be working.

So the question is: is the above behavior expected/standard or just a route53 thing, and if the former, where is it documented?

Improve this question

2 Answers 2

Reset to default
2
+50

It is behaviour not specified by the standards.

foo.sub.example.com falls under the wider definition of glue data (see RFC 8499 and RFC 2181) but specific behaviour is defined only for the narrow definition which includes only NS related records. With regard to other records, the servers are neither required nor prohibited from sending such records in an answer. Many popular servers don't send but some do. I checked Bind, PowerDNS and Route53 - they don't send. I also checked one regional hosting provider DNS solution (probably based on TinyDNS) and they do send such records. There is also an example in this question.

If a server sends a glue record then a resolver happily accepts it and doesn't reach for authoritative servers (as specified in RFC 2181), where such a record doesn't exist and it can lead to some surprises. I tested with the standard systemd-resolved.

Conclusion - avoid such records and don't rely on the existing behaviour.

Improve this answer
3

Yes, it is standard behaviour. With the delegation of the sub.example.com zone to specified nameservers you moved whole authority for all the names at and below the sub.example.com name to the above-mentioned nameservers.

The only exception to the rule are the so called glue records which provide address hints for the nameservers which are located in the delegated zone. Please note these are hints only and once the resolves reaches the authoritative nameserver it should replace them with the data from the zone (and it is STRONGLY recommended to keep the hints in sync with the authoritative in-zone data).

Improve this answer
3
  • foo.sub.example.com is glue data and glue data are proper DNS RRs, just without the AA flag. They are the same as RRs returned by a caching DNS server. A resolver is allowed to use non-authoritative glue data if it doesn't have authoritative data (RFC 2181 5.4.1). There are no requirements to always reach authoritative servers, otherwise, caching wouldn't work.
    – AlexD
    Commented Feb 15 at 6:43
  • foo.sub.example.com is glue data only if it is also listed as LHS of NS record type. The author has not made any claim about this so I cannot assume this to be true.
    – Tomek
    Commented Feb 15 at 10:52
  • No. Glue data isn't only NS record type. See the definition in RFC 8499.
    – AlexD
    Commented Feb 15 at 10:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .