Is it possible to derive all the internet addresses from a hostname using the Network framework

When making a connection to a hostname, the Network framework explicitly selects the 'best' internet address to use. For some use cases, for example NTP, the application would like to obtain all the internet addresses. For example, the hostname "time.apple.com" resolves to five internet addresses:


% host time.apple.com
time.apple.com is an alias for time-osx.g.aaplimg.com.
time-osx.g.aaplimg.com has address 17.253.20.253
time-osx.g.aaplimg.com has address 17.253.24.125
time-osx.g.aaplimg.com has address 17.253.20.125
time-osx.g.aaplimg.com has address 17.253.14.125
time-osx.g.aaplimg.com has address 17.253.24.253


This information is readily available from `getaddrinfo` but I was wondering if the Network framework had a provision for revealing all such addresses? My hunting suggests not. Invoking `getaddrinfo` from Swift is a bit of a pig, but if that's the way, so be it!

Replies

What do you plan to do with these addresses? If you plan to connect to one of them, my advice is that let Network framework do its things. OTOH, if you have other plans, can you explain those? The context really matters here.

Invoking

getaddrinfo
from Swift is a bit of a pig

It’s not that bad (see below) but yeah, it’s best avoided if you can.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

ps DTS is closed 21 Dec through 1 Jan.

func addressForName(_ name: String) throws -> [String] {
    var addrList: UnsafeMutablePointer<addrinfo>? = nil
    let err = getaddrinfo(name, nil, nil, &addrList)
    guard
        err == 0,
        let first = addrList
    else {
        // Use a better error, obviously.
        throw NSError(domain: NSPOSIXErrorDomain, code: Int(ENOTTY), userInfo: nil)
    }
    defer { freeaddrinfo(addrList) }
    return try sequence(first: first, next: { $0.pointee.ai_next }).map { addr throws -> String in
        var host = [CChar](repeating: 0, count: Int(NI_MAXHOST))
        let err = getnameinfo(addr.pointee.ai_addr, addr.pointee.ai_addrlen, &host, socklen_t(host.count), nil, 0, NI_NUMERICHOST | NI_NUMERICSERV)
        guard err == 0 else {
            // Again, a better error is needed.
            throw NSError(domain: NSPOSIXErrorDomain, code: Int(ENOTTY), userInfo: nil)
        }
        return String(cString: host)
    }
}

Years back, when iPhones took time from the phone company, it was not uncommon for AT&T to set time that was up to about two minutes off true time. My satellite tracking app, while not requiring high precision, needed better than that to avoid people hunting on the wrong side of the sky! I wrote a little SNTP library so my app didn't have to rely on clock time.


The [S]NTP process relies on, simplifiying, averaging resonses from multiple time-servers. It collects those server names from a pool address (pool.ntp.org, etc) which uses DNS round robin to make a random selection from a pool of time servers that have volunteered to be in the pool, for example:


% host pool.ntp.org
pool.ntp.org has address 173.255.215.209
pool.ntp.org has address 44.190.6.254
pool.ntp.org has address 74.6.168.73
pool.ntp.org has address 96.8.121.205


The client software then fires UDP queries at all the servers, filters out less reliable one and uses the rest averaging their responses in aggregate, and over time. I know, Quinn, that there's nothing new to you in this but I've laid it out for future readers.


Some people, and organizations, used my library to get a true time when naughty users were trying to defeat software expiration by setting their device clock back to an earlier date. My library is antiquated (written many years ago) and somewhat redundant (it's my experience that Apple's devices keep sub-second accurate time). Because of the age of my software, and the remaining ability to defeat expiry dates, I started to write an improved version in Swift using the Network framework and tripped over the topic of my original question.


I'm amused to re-read my Radar report related to this topic you suggested I submit in 2010 (FB6015112) .. today I'd add to to my CoreTime suggestion the ability to ask the OS for true time, regardless of any fiddling with the system clock setting! Happy Hogmanay ..