Ultradns, qmail e libero.it
Da alcuni giorni Ultradns e Libero stanno dando anche loro un piccolo contributo alla doverosa eradicazione di qmail in Italia.
Dopo la separazione delle attività del portale libero.it da Wind, per motivi ignoti è stato deciso di fare gestire i name server autorevoli in outsourcing da Neustar/Ultradns, uno dei principali soggetti nel mercato dei servizi di DNS.
Da alcune settimane Ultradns ha iniziato a implementare progressivamente sui propri name server una discutibile tecnica che rende leggemernte più complicato usarli per attacchi ad amplificazione, e che prevede di rispondere REFUSED alle query per ANY fatte con UDP (mentre funzionano regolarmente via TCP, che non è falsificabile).
dig +norec @n1.libero.it libero.it any
Questo in teoria non dovrebbe causare problemi, visto che le query per ANY normalmente sono usate solo per debugging e nessun software le fa direttamente, però come sappiamo bene qmail è speciale. Le usa per canonicalizzare un eventuale CNAME del dominio di destinazione (una pratica abolita un decennio fa dall'Internet civile in seguito alla pubblicazione di RFC 2821 nel 2001) e quindi quando queste query falliscono genera l'utile messaggio:
deferral: CNAME_lookup_failed_temporarily._(#4.4.3)/
Ho verificato che in pratica il funzionamento di qmail dipende dal resolver utilizzato. BIND prima tenta una query ANY ai server autorevoli, e subito risponde SERVFAIL al client, ma in seguito risponde comunque con i record imparati grazie alle altre query normali per quella label. Unbound continua a fare query per ANY e quindi non risponde mai. Non ho verificato PowerDNS, ma uno degli sviluppatori mi ha detto che stanno implementando un workaround.
Per ulteriori informazioni consiglio di leggere le discussioni in merito sulle mailing list dns-operations e oss-security.
Non c'entra niente, ma è curioso notare anche che la zona it.net non ha più record NS:
dig +norec @dns.it.net it.net ns
Per concludere il freak show segnalo che gli MX di libero.it hanno associati 56 diversi record A. Non è un'idea bellissima, ma di norma non crea problemi visto che il server autorevole non è obbligato a metterli tutti nella additional section quando risponde a una query per gli MX. Però lunedì mattina stranamente i name server di UltraDNS lo facevano, causando di conseguenza troncamento e obbligando i resolver a ripetere la query su TCP. Ma i server non rispondevano al mare di query TCP, e quindi la posta per il dominio non funzionava più.
Aggiornamento: ho appena controllato, e dopo qualche giorno di normalità oggi una query per gli MX restituisce di nuovo l'additional section completa. Ma almeno ora TCP funziona...
dig +norec @n1.libero.it libero.it mx