what should PTR recs look like for multihomed hosts

[Kevin Darcy]

Not to start another flamewar about DNS and security (the old "should I restrict
zone transfers?" issue having only recently flared up again), but why accommodate
bad security practices? "r-commands" or any kind of IP-address-based authentication
is just plain insecure. All of our PTR's on multi-homed hosts point back to
interface-specific names: this makes the non-Kerberized "r-commands" etc. as
inconvenient as possible to use, which is considered a Good Thing.

And having reverse lookups return interface-specific names solves the other
ping/traceroute/netstat/snoop problem as well.


- Kevin

Don Buchholz wrote:

> If your sites uses the Berkeley "r-commands" (rcp, rsh, rlogin, etc.),
> you will probably want to do:
>
>         foo     A       10.10.232.11
>                         10.10.132.11
>         foo-e0  A       10.10.232.11
>         foo-e1  A       10.10.132.11
>
>         10.10.232.11  PTR  foo.domain.
>         10.10.132.11  PTR  foo.domain.
>
> Otherwise your users need to put multiple hostnames in their .rhosts
> files.
>
> NFS is also subject to this, too.  When you put lines in an
> "/etc/exports" file (or Solaris "dfstab"), you have the choice of
>
>    /filesystem access,root=foo.domain
>
>   vs.
>
>    /filesystem access,root=foo-e0.domain:foo-e1.domain
>
> Not a real problem with only 2 interfaces, but when faced with
> a half-dozen or more it starts to get messy.
>
> Similarly, for consistency, your hosts file(s) ought to look like
>
>        10.10.132.11  foo.domain foo  foo-e1.domain foo-e1
>        10.10.232.11  foo.domain foo  foo-e0.domain foo-e0
>
> This way forward lookups on "foo.domain", "foo", "foo-e1.domain",
> "foo-e1", "foo-e0.domain", and "foo-e0" all return pretty much the
> same as if you'd asked the DNS system.
>
> And the reverse lookups for 10.10.132.11 and 10.10.232.11 always
> return the fully qualified hostname regardless of which name service
> was queried.
>
> The only problem is when people want to ping, traceroute, netstat, snoop,
> etc. and have the IP-address resolve back to a interface-specific name.
> That's when I point them to a man-page and suggest they find the option
> to suppress address->name resolution for their tool.
>
> I standardized on this system about 5 years ago, and a whole bunch of
> problems (inconsistencies) I had in my first 3 years of system
> administration have disappeared.
>
> - Don
>
> On Wed, 19 Jan 2000, Barry Margolin wrote:
>
> > In article <3886070B.3BD8999D at msdw.com>,
> > Anthony Golia  <Anthony.Golia at msdw.com> wrote:
> > >If my A recs look this for host foo:
> > >
> > >mydomain.com:
> > >foo     A       10.10.232.11
> > >                10.10.132.11
> > >foo-e0  A       10.10.232.11
> > >foo-e1  A       10.10.132.11
> > >
> > >What would most folks have the PTR recs look like?
> >
> > You should have PTR records pointing to foo-e0 and foo-e1.  Don't bother
> > with PTR records pointing to foo.
> >
> > >                                                  Does anyone know of
> > >any probs. using multiple PTR recs for a host?
> >
> > There shouldn't be any serious problems, but I recommend against it.  It
> > will be unpredictable which name will show up when you do a reverse lookup.
> > If you look up 10.10.232.11, sometimes you'll get foo (and you won't know
> > which foo it's referring to) and other times you'll get foo-e0.