> Lots. I'm sure that there are lots of ISPs/IAPs on NANOG
> that do RFC 2317 style delegations for their customers.
How many is lots?
Does it really matter? Even if it was only one site the problem
would still have to be addressed. I know that it is lots more
than one because I've had to help lots of sites debug their RFC 3217
style delegation.
And how often do the IP addresses of (outgoing) Mailservers change within
a subnet? None of ours has changed in the last 10 years and our
customers (mainly business customers) usually never change them, either.
Stablility has nothing to do with whether a site can just go
and add the records or not without having to talk to their
address provider.
> Every one of them would need to upgrade their servers to
> support DNAME. Their clients would also need to upgrade
> their servers to support DNAME as they should be stealth
> servers of the parent zone, to allow local lookups to work
> when the external link is down.
If MTAMARK requires DNAME then RFC 2317 style delegations would require
them, too. None of which is true.
1 CNAME 1.0/25.2.0.192.in-addr.arpa.
works exactly the same way
_send._smtp._srv.1 CNAME _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa.
does. No special magic required. One can even use BINDs $GENERATE
statement for that.
Unless I am missing something I don't know of any RFC that prohibits that.
RFC 2317 CNAMES the well known name.
MTAMARK wants to add a prefix to the well known name.
What happens when someone else decides to add yet another scheme
and another and another.
The point of RFC 2317 style delegations was to give control.
You don't get control without switching to using DNAMES.
You are still at the mercy of your address supplier when
you want to make changes in your reverse in-addr.arpa space
otherwise.
Mark
Does it really matter?
Yes it does.
(As we all know at least since the Godzilla movie "size does matter" 
It has direct influence on the deployment.
Even if it was only one site the problem
would still have to be addressed. I know that it is lots more
than one because I've had to help lots of sites debug their RFC 3217
style delegation.
I have adressed and solved the problem in my last posting.
Stablility has nothing to do with whether a site can just go
and add the records or not without having to talk to their
address provider.
Sure it has. If it never happens you try to solve a problem that does not
exist. But, see below why this "problem" is even a good thing.
RFC 2317 CNAMES the well known name.
MTAMARK wants to add a prefix to the well known name.
What happens when someone else decides to add yet another scheme
and another and another.
A man is in the desert for a week without water, dying with thirst.
A van passes by with 100000 bottles of water. The man is begging the
driver to give him a bottle and the driver replies: "I can't give one
to you because if there are 99999 others I would have none left".
There is no one else and there is no other scheme. We'll solve that issue
when there is and maybe then DNAME is widely deployed and it isn't an
issue at all.
What happens if someone wants to add a new record type and another and
yet another? This is even more complicated to deploy and it happens all
the time.
The point of RFC 2317 style delegations was to give control.
You don't get control without switching to using DNAMES.
So you say RFC 2317 failed miserably in its goal?
You are still at the mercy of your address supplier when
you want to make changes in your reverse in-addr.arpa space
otherwise.
You are at the mercy of your address supplier
- to do RFC 2317 delegation at all (a lot don't)
- to get the delegation right
- to not fsck the delegation some point later
- to not fsck the zone, so it will expire
- to not fsck the dns server config
- to not fsck the routing
- to not fsck the routing filters
- to not block port 25 or any other
- ...
But - this is the main advantage of MTAMARK: spammers cannot easily
mark an IP address as a valid mailservers without support by the
address provider.
Cracking hosts or abusing them through viruses/worms doesn't help, as
they can't set the labels giving them good reputation. With other
methods they can easily turn an 0wned host into a valid mailserver
for a (vanity) domain, with MTAMARK they can't set the "I'm a mailserver"
flag by themselves.
\Maex