peiffer@cs.umn.edu (Tim Peiffer "The Net Guy") (12/18/90)
Milo Medin <9012170259.AA06606@nsipo.arc.nasa.gov> writes: >The problem in your case is that whoever runs your DNS configuration accidentally >left out the address in question, or used the wrong name in the PTR record. Merit misconfigured ccb4.merit.edu as ccb3.merit.edu. This misadventure within the DNS did actually point out a few possible problem areas that I would like to ask about. 1) What is the correct use of wildcarding within named zone files? 2) What is the most effective (and correct) method of showing hosts with dynamic addresses within the .rev zone files? Consider the following: 1) Fastpath Appletalk to TCP/IP gateway. 2) Kstar 8.0+ and PhaseII Appletalk. 3) Base address of 128.101.147.221 4) dynamic addressing from 147.222 to 147.240 $ORIGIN ee.umn.edu. eecsk4f2 IN A 128.101.147.221 ; glue records like any other gateway ( multiple A records) IN A 128.101.147.222 [....] IN A 128.101.147.240 IN HINFO KFPS-4 Native $ORIGIN 147.101.128.IN-ADDR.ARPA. 221 IN PTR eecsk4f2.ee.umn.edu. 222 IN PTR eecsk4f2.ee.umn.edu. [...] 241 IN PTR eecsk4f2.ee.umn.edu. %nslookup -qt=ptr 128.101.147.240 240.147.101.128.in-addr.arpa host name = eecsk4f2.ee.umn.edu %nslookup eecsk4f2.ee.umn.edu Name: eecsk4f2.ee.umn.edu Address: 128.101.147.221 In this case the feature that Milo Medin mentioned would cause a lot of problems. With the example shown, the resolver would also complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240 Tim Peiffer -- ----------- Tim Peiffer peiffer@cs.umn.edu or Computer Science Dept ..!rutgers!umn-cs!peiffer University of Minnesota
medin@nsipo.arc.nasa.gov (Milo S. Medin) (12/18/90)
What we do here at Ames is that the K-box base address PTR points back to the K-box, and then each dynamic address has it's own name, and a PTR record that points back it it. For example, you have: n233-edc-gw IN A 128.102.18.112 IN HINFO "Kinetics AppleTalk Gateway" "N/A" n233-edc-1 IN A 128.102.18.113 IN HINFO "AppleTalk Host" N/A n233-edc-2 IN A 128.102.18.114 IN HINFO "AppleTalk Host" N/A n233-edc-3 IN A 128.102.18.115 IN HINFO "AppleTalk Host" N/A n233-edc-4 IN A 128.102.18.116 IN HINFO "AppleTalk Host" N/A n233-edc-5 IN A 128.102.18.117 IN HINFO "AppleTalk Host" N/A n233-edc-6 IN A 128.102.18.118 IN HINFO "AppleTalk Host" N/A n233-edc-7 IN A 128.102.18.119 IN HINFO "AppleTalk Host" N/A n233-edc-8 IN A 128.102.18.120 IN HINFO "AppleTalk Host" N/A n233-edc-9 IN A 128.102.18.121 IN HINFO "AppleTalk Host" N/A n233-edc-10 IN A 128.102.18.122 IN HINFO "AppleTalk Host" N/A n233-edc-11 IN A 128.102.18.123 IN HINFO "AppleTalk Host" N/A n233-edc-12 IN A 128.102.18.124 IN HINFO "AppleTalk Host" N/A n233-edc-13 IN A 128.102.18.125 IN HINFO "AppleTalk Host" N/A n233-edc-14 IN A 128.102.18.126 IN HINFO "AppleTalk Host" N/A n233-edc-15 IN A 128.102.18.127 IN HINFO "AppleTalk Host" N/A The PTR records all point back to the proper names, which are different for each dynamically assigned address. It's not that hard to build this with a shell script or an awk script. And even if you didn't do this, all that would happen is the gethostbyaddr would fail. No big deal, as people shouldn't be sticking things with dynamically assigned addresses in their .rhosts and the like. No big deal, or perhaps I'm missing something here? In any case, it's a big payoff for the security advantages this provides. Thanks, Milo
medin@nsipo.arc.nasa.gov (Milo S. Medin) (12/18/90)
In article <1990Dec17.182114.14182@cs.umn.edu> peiffer@cs.umn.edu (Tim Peiffer "The Net Guy") writes: ... >eecsk4f2 IN A 128.101.147.221 >; glue records like any other gateway ( multiple A records) > IN A 128.101.147.222 > [....] > IN A 128.101.147.240 > IN HINFO KFPS-4 Native > >$ORIGIN 147.101.128.IN-ADDR.ARPA. >221 IN PTR eecsk4f2.ee.umn.edu. >222 IN PTR eecsk4f2.ee.umn.edu. >[...] >241 IN PTR eecsk4f2.ee.umn.edu. > >%nslookup -qt=ptr 128.101.147.240 > 240.147.101.128.in-addr.arpa host name = eecsk4f2.ee.umn.edu >%nslookup eecsk4f2.ee.umn.edu > Name: eecsk4f2.ee.umn.edu > Address: 128.101.147.221 > >In this case the feature that Milo Medin mentioned would cause a lot >of problems. With the example shown, the resolver would also >complain of nres_gethostbyaddr(): eecsk4f2.ee.umn.edu != 128.101.147.240 > BTW, I forgot to point out in this case, you should still be OK, because unlike your nslookup output, gethostbyname will return a struct with a list of all the addresses inside. The resolver code acting the way I described will still specify a match provided that ONE of the returned A records matches the original address. In the situation you describe, 128.101.147.240 would be one of the A records associated with eecskff2.ee.umn.edu, and the call would return sucessfully. We at Ames prefer to do it in the way I described in my earlier posting, but both ways are valid, and both work with this resolver behavior. Now, I'll contend our way is a bit more robust, as the last BIND code I looked at had had some absurdly low maximum number of A records per hostname, and thus you might not get all 32 of your A record entries back in response to the query, but in theory, this should be doable. You can however discover a whole pile of DNS misconfigurations or oversights in this way, and that's always a good thing. Thanks, Milo