Silly question: how well would using 1.0.0.257.in-addr.arpa match the
need identified in draft-jabley-sink-arpa ?
It seems like it would be equally well guaranteed to be non-existant
(short of change in the def of IPv4 and in-addr.arpa). Like
sink.arpa, it would get you a valid SOA and nothing else.
Am I missing something, or is this operationally equivalent?
regards,
Ted
That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist.
The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants.
Joe
Joe Abley wrote:
Silly question: how well would using 1.0.0.257.in-addr.arpa match the
need identified in draft-jabley-sink-arpa ?It seems like it would be equally well guaranteed to be non-existant
(short of change in the def of IPv4 and in-addr.arpa). Like
sink.arpa, it would get you a valid SOA and nothing else.Am I missing something, or is this operationally equivalent?
That seems operationally equivalent, in the same way that sink.hopcount.ca doesn't exist.
The philosophical difference is that (it is proposed that) SINK.ARPA be guaranteed never to exist, whilst it's conceivable I suppose that someone could one day propose a use for 257.in-addr.arpa and descendants.
I was actually thinking that what could be useful would be a generic
way to signal that a service is not available. Something like
"noservice" (actual label is not important) as the first label of any
hostname. Then if you are a person of good will and see that MNAME or
the RHS of an MX record is assigned to "noservice.example.com" you
would know not to bother to try doing whatever you were trying to do
(dynamic dns updates, deliver mail, etc.).
I would think that further specifying that any hostname with
"noservice" as the first/only label MUST resolve to 127.0.0.1, etc.
I'm sure there are also some other rough edges I'm not thinking of
from off the top of my head.
If this is interesting I would volunteer to write a draft for it,
hopefully with Joe's help? (Both since I'm poaching his idea and
because he's really good at writing drafts.)
Doug
which is likely to be a more persistent as a non-existant
delegation? the forward space is almost entirely controlled
by simple policy - while the reverse tree has some more structure
around its non-existant state... imho of course.
--bill
I don't think we really want to see the return of the HINFO record
do we?
--bill
Ted Hardie wrote:
Silly question: how well would using 1.0.0.257.in-addr.arpa match the
need identified in draft-jabley-sink-arpa ?It seems like it would be equally well guaranteed to be non-existant
(short of change in the def of IPv4 and in-addr.arpa). Like
sink.arpa, it would get you a valid SOA and nothing else.Am I missing something, or is this operationally equivalent?
regards,
Ted
Isn't the fundamental problem that SMTP can fall back to an implicit MX? None of these solutions will stop spammers from skipping MX records and using direct-to-host connections. Shouldn't we just consider dropping the implicit MX back door as opposed to getting creative with MX records that spammers will surely note and avoid anyway?
Isn't the fundamental problem that SMTP can fall back to an implicit MX?
None of these solutions will stop spammers from skipping MX records and
using direct-to-host connections.
This has nothing to do with spam.
Shouldn't we just consider dropping the implicit MX back door as opposed
to getting creative with MX records that spammers will surely note and
avoid anyway?
It's impossible to make that kind of incompatible change with an installed
base of billions of users. It's already impossible to eliminate the AAAA
fallback and keep the A fallback.
Tony.
Tony Finch wrote:
Isn't the fundamental problem that SMTP can fall back to an implicit MX?
None of these solutions will stop spammers from skipping MX records and
using direct-to-host connections.This has nothing to do with spam.
For the OP in the original thread, it dealt with spam. I would also argue that spammers abusing the implicit MX, most often through forgeries, provides the biggest motivation to find a fix.
Shouldn't we just consider dropping the implicit MX back door as opposed
to getting creative with MX records that spammers will surely note and
avoid anyway?It's impossible to make that kind of incompatible change with an installed
base of billions of users.
I wouldn't call it impossible...difficult, maybe. Do metrics exist on how many current installs still rely on the implicit MX? Is the abuse of the implicit MX causing more harm than the effort it would take legacy DNS admins to specify an MX?
I wouldn't call it impossible...difficult, maybe. Do metrics exist on
how many current installs still rely on the implicit MX? Is the abuse
of the implicit MX causing more harm than the effort it would take
legacy DNS admins to specify an MX?
If I understand your question, you're asking how many sites don't
bother with an MX record, but count on the fallback to A to get their
mail delivered. I have to say I don't know and don't know of anyone
who has checked. I'm not sure that's its even possible to know
without starting with a full knowledge of the mail-sending entities
out there. Given that many entities allow for subdomain-level
mail address (research.example.com, cs.example.edu), the number of
extant domain names at some level of the hierarchy would only be
a predictor. Possibly someone with a very large mail installation
could run statistics to show how often they fell back; that wouldn't
be perfect, but it would be somewhat useful.
But I think the key question is actually different. Look at this
text in RFC 2821:
If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.
If I put in an MX record pointing to a guaranteed non-present
FQDN, someone complying with that text will throw an error rather than
keep seeking for an A/AAAA. Is *that* useful? If so, then
sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be.
regards,
Ted Hardie
Ted Hardie wrote:
But I think the key question is actually different. Look at this
text in RFC 2821:If one or more MX RRs are found for a given
name, SMTP systems MUST NOT utilize any A RRs associated with that
name unless they are located using the MX RRs; the "implicit MX" rule
above applies only if there are no MX records present. If MX records
are present, but none of them are usable, this situation MUST be
reported as an error.If I put in an MX record pointing to a guaranteed non-present FQDN, someone complying with that text will throw an error rather than
keep seeking for an A/AAAA. Is *that* useful? If so, then
sink.arpa/1.0.0.257.in-addr.arpa as an MX record entry may be.
Yes, I understand the RFC. That section is what allows this topic to be discussed in the first place. sink.arpa may very well be the interim solution, too. It definitely looks better than "0 .". It just seems like an ugly, smelly hack when the fundamental problem lies with allowing the implicit MX. It implies that I should, for the benefit of everyone, create a sink.arpa MX for every A record, where the effort could be better spent dropping the implicit MX rule and requiring an MX record for hosts that really do accept mail.
/Jason
"MX 0 ." is not useable. "." is not a legal host name. For those
MTA's that ignore the legal hostname rule there shouldn't be any
address records at "." which also make it unusable. And for those
of you worring about DNSSEC costs. NODATA is 1 NSEC/NSEC3 record
unless it is from a wildcard where there are some addition records,
whereas NXDOMAIN is usually 2 NSEC or 3 NSEC3 records + signatures.
Mark
It's very common for email from web servers to be poorly configured such
that it uses the webserver's hostname as the return path's mail domain.
Tony.