Для разнообразия, если Вы на самом деле хотите/нуждаетесь считать файл назад (последняя строка сначала):
tac filename | less
Проблема, о которой вы говорите, хорошо известна и представляет собой тип атаки ядом. Примеры (1) «Алгоритм разрешения RFC 1034 позволяет любому серверу в Интернете уничтожить или захватить yahoo.com». - http://cr.yp.to/djbdns/notes.html (2) http://en.wikipedia.org/wiki/DNS_spoofing#Redirect_the_NS_record_to_another_target_domain
По сути, решение сегодня используется: наборы RR в дополнительной информации игнорируются.
Неофициальное свидетельство: «Даже если ссылка включает записи A для« ns1.example.net »и« ns2.example.net »в дополнительном разделе DNS сообщения, современные итеративные преобразователи игнорируют эти записи как защиту от заражения кеша ". - http: // verisigninc. ru / en_US / products-and-services / domain-name-services / domain-information-center / часто задаваемые вопросы / dns-behavior-changes / index.xhtml
«Уточнение» (т. е. исправление) для RFC1034 находится в разделе 5.4.1 RFC 2181:
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.