On Wed, 2005-11-02 at 11:03 -0500, Derek Martin wrote: > On Tue, Nov 01, 2005 at 06:08:04PM +0000, Paul Howarth wrote: > > >; <<>> DiG 9.2.5 <<>> @192.168.0.253 www.uit.no > > >; (1 server found) > > >;; global options: printcmd > > >;; Got answer: > > >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39902 > > >;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > > > > >;; QUESTION SECTION: > > >;www.uit.no. IN A > > > > > >;; ANSWER SECTION: > > >www.uit.no. 10000 IN A 129.242.5.89 > > > > > >;; Query time: 4 msec > > >;; SERVER: 192.168.0.253#53(192.168.0.253) > > >;; WHEN: Tue Nov 1 18:31:51 2005 > > >;; MSG SIZE rcvd: 44 > > > > Hmm, that's interesting. Your nameserver appears to be returning bad > > data, though curiously the first answer was the right one in this case. > > No, I don't think so... The address returned is the same as in the > first query; the answer is correct. I believe the reason the data is > different is because the first query showed authoritative data that > the name server looked up, whereas the second query returned > non-authoritative data that the name server had cached. > > There seems to be nothing wrong with this -- the client got the same > address in both cases. No, the answer is wrong in the second case. Dig is a tool for doing low-level DNS lookups, and the first response indicates that www.uit.no is an alias for w3s2.uit.no (www.uit.no CNAME w3s2.uit.no in DNS), which has IP address 129.242.5.89. Tbe second response misses out this important distinction. The distinction is important because, if say someone was to try sending mail to webmaster@xxxxxxxxxx, what *should* happen is that the sender's MTA should spot the CNAME record and rewrite the address as webmaster@xxxxxxxxxxx, then do MX lookups for w3s2.uit.no, which might well redirect the mail to be delivered to an entirely different host than 129.242.5.89 (which may not even have a listening mail server). Paul. -- Paul Howarth <paul@xxxxxxxxxxxx>
