Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!VM1.ULG.AC.BE!PIRARD From: PIRARD@VM1.ULG.AC.BE (Andr'e PIRARD) Newsgroups: comp.protocols.tcp-ip Subject: Re: Is the DNS "working"? Message-ID: <9105030727.AA01419@ucbvax.Berkeley.EDU> Date: 2 May 91 08:54:18 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: University of Liege (Belgium), SEGI (Computing Center) Lines: 71 I pick this subject for a question about a strange DNS behavior. The NIC has introduced our 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE with no A-records for these servers. "be" is delegated to other servers, so there's no hint to our servers off the root otherwise. Name servers often reply that 1.32.165.139.in-addr.arpa, for one, doesn't exist the first time they are queried, but reply correctly afterwards, until cached data disappeared (query examples below). Is a resolver compelled to enter forward resolution to complete a reverse one? Or are A-record mandatory hints with NS replies and should I ask the NIC? I hope only this detail causes the problem. My servers seem to reply correctly indeed. VM1.ULG.AC.BE 139.165.32.1 (primary) ============= Question: 1 1.32.165.139.in-addr.arpa PTR IN Answer(s): (ie. Primary Results of the Query) 1 1.32.165.139.IN-ADDR.ARPA PTR IN 84900 VM1.ULG.AC.BE Elapsed time 0.07 sec. A query of a non-recursive server shows there are no A-records: NS.NIC.DDN.MIL 192.67.67.53 (root, non recursive) ============== Question: 1 1.32.165.139.IN-ADDR.ARPA PTR IN Authority: (ie. Authoritative Nameservers) 1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE 2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE Elapsed time 1.60 sec. I think the problem occurs when a recursive server is queried. As shown below, when cached data do not exist, these servers successively give 3 kind of replies: 1) does not exist 2) answer only 3) answer+authority+additionals x) idem until cache expiration: TERP.UMD.EDU 128.8.10.90 (root, recursive) ============ --- Query Name: 1.32.165.139.IN-ADDR.ARPA Qtype: PTR Server 1/1: 128.8.10.90 128.8.10.90 Question: 1 1.32.165.139.IN-ADDR.ARPA PTR IN Name Does Not Exist. RC=3 Elapsed time 1.16 sec. Question: 1 1.32.165.139.IN-ADDR.ARPA PTR IN Answer(s): (ie. Primary Results of the Query) 1 1.32.165.139.IN-ADDR.ARPA PTR IN 86400 VM1.ULG.AC.BE Elapsed time 2.81 sec. Question: 1 1.32.165.139.IN-ADDR.ARPA PTR IN Answer(s): (ie. Primary Results of the Query) 1 1.32.165.139.IN-ADDR.ARPA PTR IN 86385 VM1.ULG.AC.BE Authority: (ie. Authoritative Nameservers) 1 165.139.IN-ADDR.ARPA NS IN 518400 VM1.ULG.AC.BE 2 165.139.IN-ADDR.ARPA NS IN 518400 GEORGES.MONTEFIORE.ULG.AC.BE Additional: (ie. A records for others) 1 VM1.ULG.AC.BE A IN 86366 139.165.32.1 2 GEORGES.MONTEFIORE.ULG.AC.BE A IN 86366 139.165.16.1 Elapsed time 1.97 sec. Andr'e PIRARD SEGI, Univ. de Li`ege 139.165 IP coordinator B26 - Sart Tilman B-4000 Li`ege 1 (Belgium) +32 (41) 564932 pirard@vm1.ulg.ac.be alias PIRARD%BLIULG11.BITNET@CUNYVM.CUNY.EDU