Clarification on DNSServiceGetAddrInfo and its query behavior

Question

harshal_goyal OP

Created Jan ’25

Replies 3

Boosts 0

Participants 2

Hi everyone,

I’m working with the DNSServiceGetAddrInfo API and came across the following statement in the documentation:

If the call succeeds then it initializes the DNSServiceRef, returns kDNSServiceErr_NoError, and the query begins and will last indefinitely until the client terminates the query by passing this DNSServiceRef to DNSServiceRefDeallocate(_)

I’m trying to understand exactly what this means in practice. Specifically, after receiving a response with kDNSServiceFlagsMoreComing, being set to 0 does it imply that the OS itself continues querying the DNS periodically or indefinitely, even after we've already received some results? Or does it only continue fetching additional results related to the initial query until we explicitly terminate it?

Any clarification on the behavior of this query would be greatly appreciated!

Thanks in advance!

Answered by DTS Engineer in 823024022

Written by harshal_goyal in 773337021

after receiving a response [without] kDNSServiceFlagsMoreComing … does it [continue] querying the DNS … ?

Yes.

The more-coming flag is all about information that mDNSResponder already knows. If it receives a DNS reply containing a bunch of records, it delivers them to you one at a time, setting the more-coming flag on all but the last. The original motivation was for browsing; it allows you to defer your UI updates until you have all the records, and thus avoid a bunch of unsightly redraws. However, it’s useful in other situations too. For example, if you’re implementing Happy Eyeballs, you can collect A records until you get one without the more-coming flag, and then sort the addresses before kicking off your parallel connections [1].

OTOH, it says nothing about The Future™. mDNSResponder can’t tell whether a query will generate more replies if you leave it running. This is very common with mDNS, but it can also happen with uDNS [2].

In a lot of cases you actually want to receive updates. If you don’t, do what the doc says and explicitly cancel the query. Or set kDNSServiceFlagsTimeout to get a system-chosen timeout.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] A good Happy Eyeballs implementation is way more complex than that. I’m just trying to illustrate how the more-coming flag is useful for one step in the algorithm.

[2] There’s a specific long-lived query mechanism (kDNSServiceFlagsLongLivedQuery) but you shouldn’t assume that this is the only way this can happen.

Boost

Answer 1

DTS Engineer OP

Apple

Jan ’25

Recommended

Written by harshal_goyal in 773337021

after receiving a response [without] kDNSServiceFlagsMoreComing … does it [continue] querying the DNS … ?

Yes.

The more-coming flag is all about information that mDNSResponder already knows. If it receives a DNS reply containing a bunch of records, it delivers them to you one at a time, setting the more-coming flag on all but the last. The original motivation was for browsing; it allows you to defer your UI updates until you have all the records, and thus avoid a bunch of unsightly redraws. However, it’s useful in other situations too. For example, if you’re implementing Happy Eyeballs, you can collect A records until you get one without the more-coming flag, and then sort the addresses before kicking off your parallel connections [1].

OTOH, it says nothing about The Future™. mDNSResponder can’t tell whether a query will generate more replies if you leave it running. This is very common with mDNS, but it can also happen with uDNS [2].

In a lot of cases you actually want to receive updates. If you don’t, do what the doc says and explicitly cancel the query. Or set kDNSServiceFlagsTimeout to get a system-chosen timeout.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] A good Happy Eyeballs implementation is way more complex than that. I’m just trying to illustrate how the more-coming flag is useful for one step in the algorithm.

[2] There’s a specific long-lived query mechanism (kDNSServiceFlagsLongLivedQuery) but you shouldn’t assume that this is the only way this can happen.

0

Answer 2

harshal_goyal OP

Jan ’25

Hi @DTS Engineer ,

I need to resolve DNS through unicast IP-based resolution rather than multicast DNS (mDNS). Based on your previous post, I understand that mDNSResponder typically handles mDNS queries and uses the kDNSServiceFlagsMoreComing flag to manage responses.

However, I’m wondering if mDNSResponder is involved in any way when performing unicast DNS resolution or if there is a separate mechanism to resolve DNS using the traditional query flow: local resolver (stub resolver) → recursive resolver → TLD servers → authoritative servers.

Is there a way to perform DNS resolution through this traditional unicast route while bypassing mDNSResponder entirely? Or does mDNSResponder still play a role even for unicast queries?

0

Answer 3

DTS Engineer OP

Apple

Jan ’25

Written by harshal_goyal in 823192022

I’m wondering if mDNSResponder is involved in any way when performing unicast DNS resolution

mDNSRespnoder is the daemon that implements all DNS resolution on our platform, unicast and multicast. The mDNS in the name is an accident of history. For example, if you call getaddrinfo with example.com, it calls DNSServiceGetAddrInfo, which IPCs into mDNSResponder, which does the resolution over unicast, and returns the result.

The only way to bypass this chain is to implement your own DNS resolver, something that I strongly recommend against in the general case [1].

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] TN3151 Choosing the right networking API talks about this, outlining the general case (“Use the system DNS resolver”) and the rare cases where it makes sense (“building a DNS debugging tool”).

0