No subject

we can resolve:

[c:\etc]dig @192.168.11.11 -t soa earthlink.net

; <<>> DiG 9.3.2-P1 <<>> @192.168.11.11  -t soa earthlink.net
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1071
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;earthlink.net.                 IN      SOA

;; ANSWER SECTION:
earthlink.net.          1800    IN      SOA     itchy.earthlink.net.
hostmaster.earthlink.net. 2006092203 3600 300 2592000 1800

;; AUTHORITY SECTION:
earthlink.net.          1800    IN      NS      itchy.earthlink.net.
earthlink.net.          1800    IN      NS      scratchy.earthlink.net.

;; ADDITIONAL SECTION:
itchy.earthlink.net.    154455  IN      A       207.69.188.196
scratchy.earthlink.net. 154455  IN      A       207.69.188.197

I'm not sure why, but the request for just SOA records above also returns to
the name server records, followed by the name server's IP addresses.

I issue the same dig command on cox.net, I get a pur timeout with:

[c:\etc]dig @192.168.11.11 -t soa cox.net

; <<>> DiG 9.3.2-P1 <<>> @192.168.11.11 -t soa cox.net
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

Using a sniffer on the server I am digging to, what I see are cox.net SOA
records, and I also see NS records.   I don't put together how those get
there, but they do.

It's a mystery to me why dig sees nothing for cox.net, when the resolver on
192.168.11.11 is getting at least partial information on the domain.

How much of what is being returned above is given to the resolver by the
root server (or its equivalent)?   If I could understand how the sequence is
supposed to work, and who is responsible for handing out what information
prior to contacting the domain's primary name servers, I could check if
there is some server

-- 
Will


"Barry Margolin" <barmar at alum.mit.edu> wrote in message
news:efsc6m$bdk$1 at sf1.isc.org...
> In article <efrape$2gf$1 at sf1.isc.org>,
>  "Will" <westes-usc at noemail.nospam> wrote:
>
> > To recap, our DNS server, which is set to do recursive lookups, fails to
> > resolve many popular Internet addresses.
> >
> > "Barry Margolin" <barmar at alum.mit.edu> wrote in message
> > news:efkc0v$11ni$1 at sf1.isc.org...
> > > You said you asked it to look up MX records, so why is it now doing A
> > > record lookups?  Although I doubt that the record type actually
matters.
> >
> > I am certainly no DNS expert, but the sniffer trace I saw suggests that
the
> > algorithm DNS resolver in BIND is using for an MX record lookup is the
> > following:
> >
> > 1) Get the SOA record for the domain.
>
> As far as I know, BIND never looks up the SOA record when performing
> recursion; the only time it looks up the SOA is when a slave server is
> polling its master, to see if the serial number has changed.
>
> > 2) Do an A record lookup for the NS records in the SOA
>
> What "NS records in the SOA"?  When you get query for an SOA record, you
> get an SOA record, not NS records.
>
> > At least what I saw was our name server doing A lookups on hosts like
> > ns.cox.net, which certainly does look like a nameserver, and is in fact
in
> > the cox.net NS records list.
> >
> > The A lookup to ns.cox.net would timeout, and then the name server's
> > resolver would do an A lookup on the next NS record, timeout, then the
next
> > one, timeout, and after that it reports permanent failure to the DNS
client
> > (nslookup).
>
> I'm a little unclear on what you say is timing out -- is it trying to
> resolve the name ns.cox.net, or is it trying to resolve something else
> by sending TO ns.cox.net?
>
> >
> > Should I just post the output of dig +trace?   I'm probably mangling
some
> > important detail(s) here.
>
> Yes, that would be helpful, I don't think you're describing things
> properly.
>
> > > > What are some possible causes for this?    Could cox.net be
blacklisting
> > > > many Internet hosts on their nameservers?
> > >
> > > That's a definite possibility.  Perhaps at one point some problem
caused
> > > your server to bombard them with DNS queries, so they set up a filter
to
> > > block it.
> > >
> > > I suggest you contact them and ask if they're blocking DNS from your
> > > server's IP.
> >
> > My general experience with large ISPs has been that they make it their
full
> > time job to not talk to anyone, including customers :)     At least the
few
> > times I have had security problems with customers on any large ISP, they
> > have ignored all inquiries for weeks, then they try to pass off some
absurd
> > irrevelant form letter as an answer.   So with all respect, talking to
large
> > ISPs about why they do anything feels like a losing strategy.
>
> Well, if they are blocking you, there's no way you're going to get them
> to unblock without talking to them.
>
> -- 
> Barry Margolin, barmar at alum.mit.edu
> Arlington, MA
> *** PLEASE post questions in newsgroups, not directly to me ***
> *** PLEASE don't copy me on replies, I'll read them in the group ***
>
>