The AA bit is a useless bit of frippery in the DNS protol, "nslookup" is a deeply flawed tool, and arranging delegations involves talking to human beings.

Jonathan de Boyne Pollard J.deBoynePollard at Tesco.NET
Mon Aug 23 16:44:00 UTC 2004


SR> $ nslookup -sil 66.35.133.90

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/nslookup-flaws.html>

SR> Non-authoritative answer:

The AA bit (the value of which is what "nslookup" is in fact reporting 
here) is a useless bit of frippery the DNS protocol that should be 
ignored.  Apart from the egregiously broken "dnstracer", BIND itself, 
and several versions of Sendmail, the only things that take note of it 
are humans reading the outputs of DNS diagnosis tools.  Don't become 
hung up on its value.  It doesn't actually mean what you apparently 
think it to mean, in any case.

SR> Why does our T[ransit] provider show up as authoritative anwsers
SR> and our server does not[?]

Because, quite simply, the owner of "133.35.66.in-addr.arpa." has not 
delegated "90.133.35.66.in-addr.arpa." to your content DNS server, which 
is in turn almost certainly because of your having omitted the 
all-important talking-to-human-beings step.

<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/dns-server-roles.html#ArrangingDelegationsInvolvesHumans>
<URL:http://homepages.tesco.net./~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html>

SR> Is it possible for our server to be an authoritiver server
SR> for our domain?

Your server already has, as you've shown, the DNS data in its DNS 
database.  All that needs to happen is for you to talk to human beings.


More information about the bind-users mailing list