On Thu, 13 Jan 2005 22:43:24 -0800 (PST), william(at)elan.net <william@elan.net> wrote:

On Thu, 13 Jan 2005, Owen DeLong wrote:

...

That's bad sincd DNAME is deprecated and has been removed from BIND.

No, its A6 that is to be depreciated (and too bad because its superior to AAAA), but last I heard DNAME stays as standard RR.

Cue DJB's "kill A6" page http://cr.yp.to/djbdns/killa6.html -- Suresh Ramasubramanian (ops.lists@gmail.com)

That's bad sincd DNAME is deprecated and has been removed from BIND.

Owen

Really? Thats news to me. RFC 2672, Non-Terminal DNS Name Redirection, is still a proposed standard <http://www.ietf.org/iesg/1rfc_index.txt>. If you are thinking about RFC 3363, Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS). It does NOT deprecate DNAME. There is no UPDATES RFC 2672 at the top. I was well aware that it didn't deprecate DNAME when it passed through the WG. I would have complained long and loudly if it did. Mind you, in hind site, I should have a strongly argued that section 4 of RFC 3363 just be deleted. All it has done is generate confusion about the status of DNAME and to top that the opening sentence contains assertions which don't hold water once you think about them a little bit. DNAME is just as useful with nibbles in the reverse tree as it was with bitlabels. Take RFC 2874, DNS Extensions to Support IPv6 Address Aggregation and Renumbering, and redo the examples with nibbles. Everything just works. To renumber the reverse you need to get the appropriate DNAME records updated. You don't need to re-establish several levels of delegation under IP6.INT. Yes I expect the RIRs to add DNAMES not NS records at some point in the future for IP6.INT. For the forward part all the end systems just register their new addresses in the DNS using UPDATE. Mark. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org

On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote:

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? 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.

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. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin"

On Wed, Jan 26, 2005 at 07:31:44AM +1100, Mark Andrews wrote:

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 -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin"

On Wed, Jan 26, 2005 at 09:26:04AM +1100, Mark Andrews wrote:

You are adding a prefix not a type. If you added a type there would be no issue. It would work with existing RFC 2317 sytle delegations.

The issue would be deployment. Design Choices When Expanding DNS (draft-iab-dns-choices-00.txt) While I agree with the proposal in principle that a new RR type would be the best choice (at least for a lot of situations) there are situations where a) deployment is way too slow (even with RFC 3597) DNS servers/stub resolvers/caches is one but not the only issue, management software is one of the many others b) it is not usable (just think SRV records and one would need a new RR type for every protocol/service) When we started with MTAMARK we thought about using Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. and using TXT labels "ASRG.MTA=yes" or "ASRG.MTA=1" "ASRG.MTA=no" or "ASRG.MTA=0" at the same level as the PTR records. This is without any problems as related to RFC 2317, however there may be collisions with other TXT records, if there are other TXT records you have to wade through them to find if there is one suitable and if there are others there is always the 512 bytes limit. Thus we were convinced to switch to a scheme with a precise question that should also be extensible, as reputation and publishing policies in the future will be an even more important issue as they are now.

No. I'm saying that by unnecessarily using a prefix for MTAMARK it is introducing complications.

We don't think the prefix is unnecessary, quite the contrary.

So you are not going to delegate /24s? Are you going to remove the existing /24 that have been delegated? They fact that customer needs a /24 doesn't magically make them compentant. I repeat size is no indictation of compentance.

The fact that a customer needs a /24 doesn't automatically imply that he needs control over the reverse DNS. Our support staff usually adds/changes records to zones within 30-60 minutes. We monitor every reverse zone we delegate, if the customer thinks he must have control. However there is no obligation to do so and if the customer breaks the zone and is unable to put things straight and keep it that way, we remove the delegation.

Well for this to be effective you have to own the DNS server. Then again for really small shops this box will already be the mail server and will already have a MTAMARK or are you going to ban your customers from running mail servers on their bussiness class accounts.

A lot of the problems arise from 0wned broadband hosts. With SPF or Sender-Id and even DomainKeys spammers can use throwaway domains like qrve079uyvqweriuq.biz, put the IP addresses of the 0wned broadband hosts in the records of the domain and voila, the 0wned host is a legit mailserver for qrve079uyvqweriuq.biz. With short TTLs for that records they can exchange the "mailservers" fast. They control the reputation system (i.e. the forward zone).

Nothing will magically stop spam. One can reduce / channel / identify it by applying a number measures. None of those measures is 100% effective.

A lot of the methods could be some orders of magnitude more effective if some admins would take more care. Some of methods don't require anything more than a bit of thinking. Not breaking RtoL hierarchy of DNS is one of them. A naming scheme hNNN.mail.example.com instead of mailNNN.example.com is another (so a easy whitelist *.mail.example.com could be used). Using 4.3.2.1.dyn.rev.example.com instead of dyn-1-2-3-4.rev.example.com (as has been pointed out in this thread before) would help a lot. Everyone agrees, no one acts, nothing changes. RP (Responsible Person) records are there since RFC 1183. Populate the DNS and make the work of abuse reporting tools more easy to contact the right person, instead of having to wade through whois servers with broken referrals. It even helps ones own abuse desk, as one gets one email and not 5 or 6 to all kind of addresses the reporting tools think *could* be right as they found them somewhere, related or not. MTAMARK gives caring admins one of a few instruments to make their IP different and to give it a better reputation. If an address provider refuses to make this possible, one can always complain and raise the pressure - or get an address provider who cares. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin"