Qualche tempo fa ho scoperto namebench, una utility per trovare il server DNS più performante nella zona in cui siamo in quel momento.

Il suo uso è molto semplice, basta lo screenshot:

Quello che all’inizio mi ha sorpreso, però, è vedere il DNS sulla LAN battuto regolarmente da quelli esterni. Credo che il motivo sia dovuto semplicemente a questioni di caching: è più probabile che i nomi da risolvere siano già in cache sui server esterni che su quello interno.

Infatti, se ripetiamo i test il divario fra il DNS interno e quello esterno tendono a diminuire. Usando come domini da risolvere quelli nella cache di Safari, otteniamo:

1. 179% più veloce;
2. 90% più veloce;
3. 73%.

Il DNS interno rimane sì il più veloce in termini assoluti, con ~2ms di miglior risposta contro ~ 26ms del DNS esterno migliore ma dall’altra parte il tempo peggiore di risposta è di ~1,5s per l’interno e ~0,5 per l’esterno, con una distribuzione delle risposte nettamente a favore del server esterno.

Un DNS interno può rimanere indispensabile per risolvere i nomi sulla LAN ma il suo beneficio come cache può essere importante di quanto si pensi.

Mac OS X Hints mi rinfresca la memoria su come trovare l’indirizzo ip del server DHCP e mi “ispira” a proporre una versione alternativa e più grezza. La soluzione del post è un AppleScript mentre quello che segue è un semplice wrapper intorno a ipconfig(8).

 

#! /usr/bin/env tclsh 

foreach if [split [exec ifconfig -lu]] {
    if {[catch {
        exec ipconfig getoption $if server_identifier
    } result]} {
    } else {
 puts "$if: $result"
    }
}

 

Dal sempre utile Mac OS X hints ecco le istruzioni per limitare l’uso della banda di alcune porte ip.

Nel caso non l’aveste sentito, Apple ha pre­sentato fra le altre cose un nuovo portatile, il MacBook Air ed è abbastanza probabile che ne abbiate già le tasche piene dei commenti pro e contro, per cui aggiungo solo un paio di info che credo siano interessanti.

La prima riguarda la batteria che, secondo la documentazione, non è sostituibile dall’utente finale. Detto che è ovviamente meglio potersi cambiare la batteria da soli, i pareri al riguardo sono discordanti ma in ogni caso la questione è probabilmente irrilevante: secondo AppleInsider la sostituzione è comunque banale.

La seconda notizia, più succosa tecnologicamente, riguarda la questione del (mancante) lettore ottico. Apple, per ovviare a questa mancanza, fornisce un programma chiamato Remote Disc per l’installazione via rete. Rete?  Ma il MacBook Air non ha nemmeno la porta Ethernet!

Questo vuol che Remote Disc è capace di fare da server NetBoot e che il MacBook Air può fare il boot via wireless, cosa che Apple stessa sconsigliava fino a ieri. La questione non è di poco conto sia per l’entità delle modifiche pre­sumibilmente richieste all’EFI e alla soluzione di “dettagli” come l’accesso a WLAN criptate, ad esempio.

Come spesso accade, la proposta di Apple non fa molti compromessi: “love it or leave it”. La mia opinione? Non è la mia macchina ideale, non ora… E voi, siete tentati?

Questo articolo di Apple sul firewall di Leopard contiene alcuni dettagli interes­santi. Il primo – e più noto – è che si tratta di un firewall che lavora a livello di applicazione e non a livello di porte: mi basta dire che deve accettare le connes­sioni entranti per iTunes, invece che dover specificare quali siano le porte usate dall’applicazione, ad esempio.

Ma più oltre si trovano pre­cisazioni da tenere a mente. Sul “livello” a cui lavora questo software:

The Application Firewall does not overrule rules set with ipfw, because ipfw operates on packets at a lower level in the networking stack.

Riguardo ai legami fra il firewall e il code signing:

When you add an application to this list, Mac OS X digitally signs the application (if it has not been signed already). If the application is modified, you will be prompted to allow or deny incoming network connections to it. Most applications do not modify themselves, and this is a safety feature that notifies you of the change.

Quindi il code signing può avvenire anche ex post, per una singola applicazione, mentre pensavo fosse una pre–condizione da soddisfare prima di applicare delle regole con il firewall. Tant’è vero che più sotto si pre­cisa che se un’applicazione non pre­sente nell’elenco cerca di effettuare un qualche tipo di connes­sione, viene pre­sentata una finestra di dialogo che chiede all’utente cosa fare e, nel caso in cui, acconsenta all’esecuzione dell’applicazione, quest’ultima viene firmata.

Infine, se non esplicitamente aggiunte come applicazioni escluse, tutti i processi che girano come root o sono firmate da una Certificate Authority fidata (come quelle di Apple) hanno pos­sibilità di effettuare connessioni.

Come molti di voi sapranno, ieri è uscito Mac OS X 10.5 e una delle cose che mi incuriosivano di più era capire il funzionamento della feature chiamata “Back to My Mac”, ovvero, la pos­sibilità di accedere ad un proprio computer registrato su .Mac da un’altra macchina via internet, anche se il computer sta in un rete locale dietro un NAT.

Perché questa cosa funzioni è neces­sario che il router della propria rete locale supporti uno di questi due protocolli: il NAT-PMP o l’UPnP. Il primo è sicuramente supportato dagli ultimi modelli di Airport, l’altro – UPnP – è più probabilmente attivabile sugli altri router.

Per altre info:

• Using Back to My Mac in Mac OS X 10.5 Leopard;
• Mac OS X 10.5: Back to My Mac requires AirPort base station or UPnP-capable third-party router;
• Back to My Mac: Supported router devices (Mac OS X 10.5 Leopard).