[GH-ISSUE #735] Perform additional processing for NAPTR #285

New issue

Open

opened 2026-03-07 23:16:00 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 23:16:00 +03:00

Owner

Originally created by @bluejekyll on GitHub (Apr 7, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/735

Is your feature request related to a problem? Please describe.

NAPTR records include a reference to a “replacement” name, this should be included in the additional section. This can point to SRV or A/AAAA.

Describe the solution you'd like
In the resolver we may want to process NAPTR and perform additional lookups, but this is zone dependent, so the resolver doing this properly might be wasteful on the query.

The server can do this efficiently, as it has access to the zone, it can return known records on the chain.

Originally created by @bluejekyll on GitHub (Apr 7, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/735 **Is your feature request related to a problem? Please describe.** NAPTR records include a reference to a “replacement” name, this should be included in the additional section. This can point to SRV or A/AAAA. **Describe the solution you'd like** In the `resolver` we may want to process NAPTR and perform additional lookups, but this is zone dependent, so the resolver doing this properly might be wasteful on the query. The `server` can do this efficiently, as it has access to the zone, it can return known records on the chain.

kerem added the

enhance

crate:server

crate:resolver

labels

2026-03-07 23:16:00 +03:00

kerem commented

2026-03-07 23:16:11 +03:00

Author

Owner

@nhoyle commented on GitHub (Apr 7, 2019):

If I remember my RFCs correctly (I'm not looking at them right now), "Additional" record responses are only supposed to be returned when the server already has knowledge of the additional records (making the additional information effectively "zero cost" to provide). This means either the server is authoritative for the zone in question, or the server has recently queried the additional records in question, and still has them in an unexpired cache from that prior lookup.

In the situation where the queried server is authoritative for all records involved, the NAPTR query will likely result in SRV RRs as the response, which in turn could be resolved to A/AAAA records. (Alternately, the NAPTR results could be A/AAAA records, directly.) This would mean that the server could provide an "answer" section to the NAPTR query with the direct results, as well as "additional" SRV and A/AAAA records, at no additional query cost/latency.

If the server is acting (in whole, or in part) as a recursive resolver on behalf of the client, and is not authoritative for one or more of the queried zones in the NAPTR->SRV->A/AAAA chain, then it would be a violation of the RFCs for the server to launch additional queries on behalf of the client to return any information not already cached from prior lookups. (Although, potentially all of that information could be cached, and valid to return.)

That said, in the typical use case of a SIP client attempting to initiate a connection, all of the above components would need to be resolved before the client could achieve any real forward progress. (For example, you can't connect a VoIP phone call without knowing the IP of the next-hop server/user-agent.) It is obviously less efficient, both from a server resource and client latency perspective, to force the client to launch three queries when the server could potentially launch the second and third queries on behalf of the client (for the SRV and A/AAAA records) without the need to round-trip back to the client with the partial results.

Because doing so would violate RFCs however, such behavior should be an optional feature to be enabled, either via resolver/server config, or as part of the request protocol between the client and resolver/server, to indicate this behavior is desired.

In practice, a large number of NAPTR records (which may likely correspond to individual telephone numbers) may fan in to a comparatively small number of server farms and IPs (SRV and A/AAAA records). As such, it is likely that good caching performance may be observed without deviating from the RFC-specified query behavior, so long as the TTLs associated with the SRV and A resource records is not unreasonably short.

As such, I would consider it a priority to support providing "additional" RR information for the SRV and A/AAAA information when available either via virtue of being the zone authority, or via cache, and consider launching additional queries on behalf of the client a possible future extension if experience suggests it is necessary.

(Hopefully the above is not overkill, was trying to provide clarity. If it's still not clear, I can try to muddy the waters further.)

@nhoyle commented on GitHub (Apr 7, 2019): If I remember my RFCs correctly (I'm not looking at them right now), "Additional" record responses are only supposed to be returned when the server already has knowledge of the additional records (making the additional information effectively "zero cost" to provide). This means either the server is authoritative for the zone in question, or the server has recently queried the additional records in question, and still has them in an unexpired cache from that prior lookup. In the situation where the queried server is authoritative for all records involved, the NAPTR query will likely result in SRV RRs as the response, which in turn could be resolved to A/AAAA records. (Alternately, the NAPTR results could be A/AAAA records, directly.) This would mean that the server could provide an "answer" section to the NAPTR query with the direct results, as well as "additional" SRV and A/AAAA records, at no additional query cost/latency. If the server is acting (in whole, or in part) as a recursive resolver on behalf of the client, and is not authoritative for one or more of the queried zones in the NAPTR->SRV->A/AAAA chain, then it would be a violation of the RFCs for the server to launch additional queries on behalf of the client to return any information not already cached from prior lookups. (Although, potentially all of that information could be cached, and valid to return.) That said, in the typical use case of a SIP client attempting to initiate a connection, all of the above components would need to be resolved before the client could achieve any real forward progress. (For example, you can't connect a VoIP phone call without knowing the IP of the next-hop server/user-agent.) It is obviously less efficient, both from a server resource and client latency perspective, to force the client to launch three queries when the server could potentially launch the second and third queries on behalf of the client (for the SRV and A/AAAA records) without the need to round-trip back to the client with the partial results. Because doing so would violate RFCs however, such behavior should be an optional feature to be enabled, either via resolver/server config, or as part of the request protocol between the client and resolver/server, to indicate this behavior is desired. In practice, a large number of NAPTR records (which may likely correspond to individual telephone numbers) may fan in to a comparatively small number of server farms and IPs (SRV and A/AAAA records). As such, it is likely that good caching performance may be observed without deviating from the RFC-specified query behavior, so long as the TTLs associated with the SRV and A resource records is not unreasonably short. As such, I would consider it a priority to support providing "additional" RR information for the SRV and A/AAAA information when available either via virtue of being the zone authority, or via cache, and consider launching additional queries on behalf of the client a possible future extension if experience suggests it is necessary. (Hopefully the above is not overkill, was trying to provide clarity. If it's still not clear, I can try to muddy the waters further.)

kerem commented

2026-03-07 23:16:16 +03:00

Author

Owner

@bluejekyll commented on GitHub (Apr 8, 2019):

Yes, this all sounds accurate to what I would think is the case.

@bluejekyll commented on GitHub (Apr 8, 2019): Yes, this all sounds accurate to what I would think is the case.

kerem referenced this issue

2026-03-16 02:01:20 +03:00

[PR #285] [MERGED] Support for TLSA #1342