Second dig lookup not the same as the first

[Kalman Feher]

For the TCP issues check your network.

I'm not familiar with DLZ, but it may be worth understanding how it is
effected by the addition-from-[auth|cache] options. Since you get the full
response once, I presume you do not have minimal responses enabled.

My ignorance of DLZ is showing, but consider if there is any caching that is
going on that is returning just the ANSWER after the first query.


On 15/09/10 11:59 PM, "Scott Haneda" <talklists at newgeo.com> wrote:

> Hi, 
> 
> No, I am not running any firewall on the client side at all.  I can perform
> lookups elsewhere that behave as I would expect. I also performed these tests
> on another machine that has a more current and non Apple dig as well.
> 
> The server is RHEL, not Mac OS X.  I have deployed many named servers on Mac
> OS X, but I do not use the Apple supplied version, and always either go to the
> source for a more current version, or lately, I have been using MacPorts to
> aid in that installation process.
> 
> I don't think this question is as much of a platform issue as it is one of my
> lack of understanding in what causes the additional and authority sections to
> change on a subsequent request.
> -- 
> Scott (* For off-list contact, replace talklists@ with scott@ *)
> 
> On Sep 15, 2010, at 1:45 PM, wllarso wrote:
> 
>> From the output of your dig command you show that you are running a MacOSX
>> system. Are you running the firewall on this system also? That may be
>> dropping the TCP communication.
>> 
>> Be aware that Apple's DNS server configrration throws every bell and whistle
>> into the config. If you really are serious about running a DNS server under
>> MacOSX, then make a post on the MacOSX-server list and step back for all of
>> the reasons this isn't a good idea, at least not using what Apple give you.
>> 
>> Bill Larson
>> 
>> and sorry about the top posting, but this was ...
>> Sent from Garminfone by T-Mobile.
>> 
>> Scott Haneda <talklists at newgeo.com> wrote:
>> 
>>> Hello, I have set up a new BIND/named server, being backed by DLZ in this
>>> case, though I don't think that will have any bearing on my question.
>>> 
>>> This NS is not publicly known or listed as an NS anywhere as of yet, so it
>>> is only my own testing that has hit the machine.  If I perform a dig
>>> request, the first request returns additional data, any subsequent lookups
>>> return no additional data.  Does anyone know why this is?
>>> 
>>> I also seem to have issues when forcing tcp, does anyone have any ideas what
>>> that could be caused by?  Is there a setting in named.conf that controls
>>> udp/tcp or should I be talking to the network admin about this?
>>> 
>>> I have to obfuscate this data, I apologize for that...
>>> 
>>> == First dig request, never been looked up before
>>>   ; <<>> DiG 9.6.0-APPLE-P2 <<>> @63.251.yyy.yy example.com
>>>   ; (1 server found)
>>>   ;; global options: +cmd
>>>   ;; Got answer:
>>>   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41088
>>>   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
>>>   ;; WARNING: recursion requested but not available
>>> 
>>>   ;; QUESTION SECTION:
>>>   ;example.com.  IN A
>>> 
>>>   ;; ANSWER SECTION:
>>>   example.com. 3600 IN A 208.122.xxx.xx
>>> 
>>>   ;; AUTHORITY SECTION:
>>>   example.com. 86400 IN NS ns2.some-nameserver.com.
>>>   example.com. 86400 IN NS ns1.some-nameserver.com.
>>> 
>>>   ;; ADDITIONAL SECTION:
>>>   ns1.some-nameserver.com. 86400 IN A 208.122.xxx.xx
>>>   ns2.some-nameserver.com. 86400 IN A 208.122.226.214
>>> 
>>> == Second dig request, moments after the first
>>>   ;; Query time: 41 msec
>>>   ;; SERVER: 63.251.yyy.yy#53(63.251.yyy.yy)
>>>   ;; WHEN: Wed Sep 15 12:15:48 2010
>>>   ;; MSG SIZE  rcvd: 136
>>> 
>>> 
>>>   ; <<>> DiG 9.6.0-APPLE-P2 <<>> @63.251.yyy.yy example.com
>>>   ; (1 server found)
>>>   ;; global options: +cmd
>>>   ;; Got answer:
>>>   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20029
>>>   ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>>>   ;; WARNING: recursion requested but not available
>>> 
>>>   ;; QUESTION SECTION:
>>>   ;example.com.  IN A
>>> 
>>>   ;; ANSWER SECTION:
>>>   example.com. 3600 IN A 208.122.xxx.xx
>>> 
>>>   ;; Query time: 37 msec
>>>   ;; SERVER: 63.251.yyy.yy#53(63.251.yyy.yy)
>>>   ;; WHEN: Wed Sep 15 12:15:50 2010
>>>   ;; MSG SIZE  rcvd: 55
>>> 
>>> And trying to see what is going on with tcp or udp...
>>> 
>>> $dig @63.251.yyy.yy example.com +tcp
>>> ;; Connection to 63.251.yyy.yy#53(63.251.yyy.yy) for example.com failed:
>>> connection refused.
>>> 
>>> If I do the same thing with +notcp, I get the result in example #2 above,
>>> where there is no additional section.
>>> 
>>> Thank you for any assistance, I appreciate it.
>>> 
>>> -- 
>>> Scott (* For off-list contact, replace talklists@ with scott@ *)
>>> 
>>> _______________________________________________
>>> bind-users mailing list
>>> bind-users at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Kal Feher