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