-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of John A.
Martin
Sent: Monday, March 21, 2005 4:30 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: Draft ammendments on DNS lookup limits
"Scott2" == Scott Kitterman
"RE: Re: Draft ammendments on DNS lookup limits"
Mon, 21 Mar 2005 14:49:08 -0500
>>>>>>> "Scott" == Scott Kitterman
>>>>>>> "RE: Draft ammendments on DNS lookup limits"
>>>>>>> Fri, 18 Mar 2005 17:22:53 -0500
>>
>>> I use a zone template file, and using a Makefile I can update
>>> it any time anything in my zone changes. This system works very
>>> well.
>>
Scott> That works for those running their own DNS. For those of
Scott> us with outsource DNS it's a little more troublesome.
>>
>> Hmmm... several domains under my influence use a number of
>> "outsourced" slave nameservers that pull their zone files from
>> individually maintained "stealth" nameservers that do not
>> respond to normal queries from "The Net". This seems to have
>> worked very well for years and I've not yet run into a "captive
>> audience" (ISP/hosting provider) nameserver that will not pull
>> from a stealth master nameserver. The stealth master needs to
>> be 24x7 but can be on a slow link. With such an arrangement
>> you can use a Makefile to maintain your zone files just like
>> some "real people" do.
>>
Scott2> Yes, there are outsource setups that work like that.
Enough that one can use them instead of the other kind at least as
independent providers.
Right, but in many cases, DNS service is bundled with another service such
as web hosting or domain registration.
Scott2> There are also very many that only allow manual changes
Scott2> through either a trouble ticket or access via a web
Scott2> interface.
For the "captive audience" type provider, have you tried asking nicely
of someone at the provider who is in a position to know what a
"stealth" master is? Folks I happen to know who have tried have had
success when they know how to talk to someone who knows a little about
DNS.
I probably could, but how many domain owners are going to get through that
process. SPF has to work for the bulk of domain owners. Limits have to
work for the non-tehcnical (or slightly technical) domain owner too. Sign
up for the spf-helper team that responds to e-mails to the spf.pobox.com
site and see what we are dealing with.
Scott2> For those types of setups, this kind of record flattening
Scott2> just isn't feasible.
Would a flattened RR be harder to paste into a web form?
Yes, because it changes unpredictably (that is if it crosses administrative
boundaries). That's the tricky part. I've no problem with compiling the
records that are under my control and posting them. It's turning things
that other people control into IP addresses that I find problematic.
Scott2> Bottom line is that forcing a single SPF record to
Scott2> directly maintain an accurate IP address list across
Scott2> administrative boundries is inherently dangerous.
I was not addressing that issue, only the unqualified statement that
Makefiles could not be used with outsourced DNS servers.
FWIW I believe that Radu Hociung has made it abundantly clear that
indiscriminate inclusion of policy from outside one's sphere of
influence is largely a fool's errand. Flattening has little to do
with the folly.
And yet he insists that I must do that to conform to his version of a
reasonable number of DNS queries.
Scott2> Unless the update interval is zero, there is a period
Scott2> where by design the record is irretreivably wrong.
Hmmm... That brings to mind the notion that inclusion across
administrative boundaries violates the principle of
authority/delegation as it is embodied in the traditional public DNS.
Perhaps it should be stipulated that, because it breaks the path of
the DNS delegation of authority, inclusion beyond an administrative
domain is likely to be unwise. Or, should it be disallowed?
I think that the processing limits should be set high enough that it
shouldn't be required. It should certainly be discouraged. If someone
wants to take the risk after they've been warned, I'm OK with that.
Indiscriminate redirection also seems problematic, no?
Sure. But my scenario isn't excessively complex. We need to find a
balance.
Scott Kitterman