BIND A record not returning the correct IP, returning an IP for another record...

How odd... response includes the AA flag (authoritative answer)?

And presumably it's not failing to reload the zone? Or returning more than one result?

Chris

BIND restarts fine after making the change. When I do the nslookup all it shows me is the IP, I don't see anything about AA at all. There is another A record for webmail.domain.com and that one is a different IP from the other 2 and it works fine so I don't know what the deal is.

Oh yeah, sorry, nslookup...

nslookup -d2 subdomain2.domain.com.

Trailing . is intentional, it'll stop it appending suffixes to the query.

We're interested in the header flags for any response it gives.

I guess you're sending the query to the name server you modified directly? Not via a resolver?

Chris

Ya I was doing nslookup, then "server private ip" then subdomain2.domain.com

I ran the command you listed, what should I be looking for exactly?

A section that looks like this:

C:\> nslookup -d2 indented.co.uk. ns1.indented.co.uk

...

Got answer (198 bytes):
    HEADER:
        opcode = QUERY, id = 2, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 1,  authority records = 6,  additional = 2

    QUESTIONS:
        indented.co.uk, type = A, class = IN
    ANSWERS:
    ->  indented.co.uk
        type = A, class = IN, dlen = 4
        internet address = 69.164.211.174
        ttl = 86400 (1 day)
...

Select allOpen in new window

If it's returning the A record with an "auth. answer" flag then it got the answer from the server with no intermediate systems interfering.

And if that is the case, it's back to the zone to check for silly things, missing terminating periods (or accidentally included terminating periods) and all that jazz. Oh and wildcard records, because if it's ignoring the current entry we would do well to explain why it's coming back with an answer at all.

Chris

PS if you find the output from nslookup unfriendly, grab dig, either on your Unix / Linux system or the Windows version here: http://members.shaw.ca/nicholas.fong/dig/

Below is the output from dig

; <<>> DiG 9.7.1-P2 <<>> @<IP of our NS> subdomain2.domain.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52940
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;subdomain2.domain.com.        IN      A

;; ANSWER SECTION:
subdomain2.domain.com. 3600 IN A       Wrong IP

;; AUTHORITY SECTION:
subdomain2.domain.com. 86400 IN NS     ns3.ourns.net.
subdomain2.domain.com. 86400 IN NS     ns1.ourns.net.
subdomain2.domain.com. 86400 IN NS     ns2.ourns.net.

;; ADDITIONAL SECTION:
ns1.ourns.net.         3600    IN      A       Public IP
ns2.ourns.net.         3600    IN      A       Public IP
ns3.ourns.net.         3600    IN      A       Public IP

;; Query time: 16 msec
;; SERVER: 10.0.1.225#53(10.0.1.225)
;; WHEN: Tue Feb 15 13:43:18 2011
;; MSG SIZE  rcvd: 176

Select allOpen in new window

The weird thing is we have a 2nd set of DNS servers that we are getting ready to cutover to which have a frontend to edit records. I added this same record to those thinking that it might be an issue with the configuration on the first set and it did the same thing.

The records on the 2nd set were transferred from the first set but I was hoping that it would fix the issue. SO I am at quite a loss right now.

It all points to an error in the zone file, which is kind of annoying really. I'd ask you to post the zone file (for a third / forth / fifth / ++ set of eyes), but I have to head off to bed now I'm afraid.

Chris

OK, figured this out. There is a domain.com zone and a subdomain2.domain.com zone both with A records for subdomain2.domain.com. I deleted the subdomain2.domain.com zone so that the only A record is within the domain.com zone and that resolved the issue.

Figures :) It was always bound to be something like that, I'm glad you found it :)

Chris

Thanks