wayne wrote:
In <427C1A64(_dot_)2010102(_at_)ohmi(_dot_)org> Radu Hociung
<radu(_dot_)spf(_at_)ohmi(_dot_)org> writes:
Today, as the zone expired due to failure to contact the master zone
server for a week, the trusted-forwarder domain just disapeared.
Is it possible that you had a hard coded IP address? When I switched
ISPs, I had to switch IP addresses.
During the switch-over, both new and old IP addresses worked, and
after the three day TTL on the various trusted-forwarder.org records
timed out, queries from the old IP address dropped to maybe a half
dozen requests per day.
Yes, that was it... I used this:
#zone "trusted-forwarder.org" {
# type slave;
# file "trusted-forwarder.org";
# masters { 206.222.212.234; 199.175.137.211; 209.69.32.138; };
#};
BIND only allows IP addresses in the masters list.
I believe this is by design, because there is no requirement in DNS
architecture for the MASTER of a zone to be a publicly accessible name
server.
In that case, if you didn't use IP addresses, the slaves of the zone
could never even do the first zone transfer, because the only server
that can answer that AXFR query is the master server, but is location is
not public record (ie, there is no name that must point to it).
To point to your master zone server with a name, I would have had to use
a cron script that updates the IP address in the named.conf file, *and*
query a NS server other than the local server.
Of course, a name server config file that is updated by a cron job is
not a good idea at all, so this cron thing would have been a really ugly
hack.
It's a bootstrapping problem that BIND avoids by requiring an IP address
for the masters. I don't think other server brands can do different (at
least not reliably)
I am only pointing this out in case you also use this service with zone
trasfers.
It would have been nice if the move was more prominently announced, on
the spf lists.
If I thought it would have caused problems, I certainly would have
made an announcement.
You said that your logs only show 2 sources for AFXR requests. So it's
only me and one other domain that are affected. The other domain would
only be affected if he rejected based on SPF. If they don't, currently
all their SPF results are TempFail, and they're wondering why. ;)
The change would indeed be transparent to sites that don't use zone
transfers, but do normal queries to the name servers that you maintain.
By the way, when you changed (if you did) the IP address of your master
server, did you not have to inform your slaves of the IP address change
in some way?
For my zones, if I had to move my master, I know for sure I'm required
to log into the slave's websites and update the new IP address of the
master.
If you can provide me with the IP address that would have done the
query, the times and the dates, I can look through my DNS logs to see
if I can find any errors. I confess that, due to the volume of the
T-FWL, I don't keep logs for more than a few days.
Hmmm... I just checked my logs. Since May 1, I can find only two
requests for AXFRs for outside sources, one of which is ns2.ohmi.org.
According to the logs, this succeeded at 20:53:07 06-May-2005 CDT. I
have no record of any earlier attempts.
I can't find that timestamp in my logs, and my clock is NTP synchronized
to time.nrc.ca hourly, and is never off my more than 50 milliseconds or so.
I have log entries like these, every 55 minutes or so (since the retry
period in your SOA is 1 hour)
May 6 09:07:41 sun named[32577]: zone trusted-forwarder.org/IN:
refresh: retry limit for master 206.222.212.234#53 exceeded
May 6 09:07:41 sun named[32577]: xfer-in: info: transfer of
'trusted-forwarder.org/IN' from 199.175.137.211#53: resetting
May 6 09:07:41 sun named[32577]: xfer-in: error: transfer of
'trusted-forwarder.org/IN' from 199.175.137.211#53: failed while
receiving responses: end of file
May 6 09:07:41 sun named[32577]: xfer-in: info: transfer of
'trusted-forwarder.org/IN' from 199.175.137.211#53: end of
transfer
May 6 09:07:42 sun named[32577]: xfer-in: info: transfer of
'trusted-forwarder.org/IN' from 209.69.32.138#53: resetting
May 6 09:07:42 sun named[32577]: xfer-in: error: transfer of
'trusted-forwarder.org/IN' from 209.69.32.138#53: failed while
receiving responses: REFUSED
May 6 09:07:42 sun named[32577]: xfer-in: info: transfer of
'trusted-forwarder.org/IN' from 209.69.32.138#53: end of transfer
However, this is one more experience item that we (I) did not have until
today. Say what you will, but to me SPF is still an experiment. We'll
just have to agree to disagree on this one. :)
I don't think that SMTP is experimental just because DNSBLs don't
always work. Similarly, I don't think that SPF is experimental just
because the T-FWL doesn't always work. As said on the
trusted-forwarder.org web page, the T-FWL is *not* part of the SPF
standard, for many very good reasons.
An SPF implementation should fail open, ie, give no SPF result if the
local policy results in TempFail or PermFail. This is the learning
lesson I take from all this. Perhaps this has been a known fact for a
long time, and I did not know it.
Regards,
Radu