[no subject]

> > > My local DNS is the resolver and /etc/hosts with
> > >     ::1         localhost localhost.localdomain
> > >     127.0.0.1   localhost localhost.localdomain
> >
> > Nope.  Not used the way you think.  The reverse lookup doesn't
> > treat the hosts file as authoritative, when trying to index by
> > IP.  I'm not sure if this is just because it hates the "::1"
> > shorthand, or if there's some deeper issue, but I think it's
> > that there's a deeper issue here.
> 
> I've never thought about it beyond the "localhost" case.  So is
> "/etc/hosts" obsolete (eg, for LAN hosts) if you need reverse lookup,
> like if you want to use sendmail?

It's ugly, but try adding:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1 localhost
localhost.localdomain

The answer is probably that /etc/hosts is obsolete, and should
probably be replaced by a caching local DNS server that's treated
as authoritative for the local wire.  The RFC-correct name is
actually "link.local", not "localdomain", if you care, which you
probably don't.  8-).


> But I mentioned "/etc/hosts" mostly to point out that I'm using only the
> non-server parts of "bind" which I called the "resolver" and that it
> seemed to be doing reverse lookup on 127.0.0.1 (or have it hard coded).

I think this is the library bug I mentioned earlier.  I think that
"::1" is not properly cannonized to convert it into the long form
of "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1",
before the compare happens, so the compare fails.


> > You need to set up a caching DNS server on the machine, specify
> > it as your DNS server in your /etc/resolv.conf, and then set
> > the forwarder to whatever DNS server you currently have in your
> > resolv.conf, tun on forwarding, turn on caching, and then make
> > it authoritative for 127.in-addr.arpa., and the equivalent for
> > IPv6, and add reverse records.
> 
> Easier said than done, of course.  And there's the complication that my
> forwarder info gets put in resolve.conf dynamically by DHCP.  (But I
> suspect it's stable enough for my purposes to hard code it in the named
> files.)  I think I'll live with my kludge for a while.

Yes, it's annoying that the relationship between a caching DNS
forwarder and the DHCP assigned DNS server is not automatic in
FreeBSD clients, like it is in Windows clients.


> > Technically, this is probably a bug in either the FreeBSD resolver
> > library, or the default FreeBSD hosts file, or both.
> 
> I'll try using the longhand version of "::1" (which I saw in another
> message); I didn't know there were two versions.  And I'll write a PR on
> it, though if it's not a /etc/hosts problem, there's going to be too
> much hand waving for a good chance of the PR being closed before it's
> obsolete.

That's my recommendation.


> > The local delivery mailer is not marked expensive, so local
> > delivery goes immediately.
> 
> Unless it can't go immediately, in which case it's queued.

If it can't go immediately, no matter what you do, it's going to
be queued... so "no change".


> > The "HoldExpensive" just means that it won't try to send or
> > lookup mail that has to go via SMTP -- mail that isn't local --
> > until you do an explicit queue run.
> >
> > The queue runner doesn't bang it's head... it brings the link up,
> > and does what it needs to do.  But since it runs with a .cf generated
> > from a different .mc, it has timeouts that make the DNS work, instead
> > of failing before the link is established.
> 
> The runner would bang its head trying to bring the link up on MY system
> and I (currently) want it that way.

That's even easier: only do the queue run in the "linkup" script:
no head bumping at all.  8-).


-- Terry

To Unsubscribe: send mail to majordomo@xxxxxxxxxxx
with "unsubscribe freebsd-current" in the body of the message