Subject: RE: Faux wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 09:54:35 -0800

> [mailto:[email-masked]] On Behalf Of John Levine
> Gee, we had this argument, too.  It's because subzones of 
> Uni-Bielefeld.DE are delegated from Uni-Bielefeld.DE, of 
> course, and are completely at the mercy of the operator of 
> the higher level zone already.  There seem to be a lot of 
> subzone operators who wish this weren't true, but if you want 
> to constrain the behavior of the zones that delegate to you, 
> you have to do it administratively, not within the DNS.  And 
> for the third time, zone cuts aren't relevant to this design.

Here I think there is a problem. This type of argument can come unstuck
really baddly, it is close to 'as secure as' which is how http passwords got
spec'd to be sent en-clair and how WEP became a disaster etc.

I think that the problem you will find here is not so much a deliberate
attack but accidental treading on su-admin zones. 

For example MIT has a network group that manages *.mit.edu, but the LCS and
AI labs have traditionally managed *.ai.mit.edu and *.lcs.mit.edu (now
*.csail.mit.edu) independently. 

What your proposal does is to change the balance of power between the apex
operator and the subzone operator. There is no process in place to make sure
that changes at the apex do not inadvertently tread on configuration at the
leaves.

The same thing will turn up all over the place. It's a really bad plan.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 11:30:23 -0800

> [mailto:[email-masked]] On Behalf Of wayne

> First, the folks running the in-addr tree have said "DON'T!  
> We can't deal with the extra traffic."

That is not a reason. If there is purpose to use of an infrastructure then
we should fix the infrastructure. SPF will increase the load on core DNS
significantly, that means real cost to DNS infrastructure operators but I
have not hear any complaints from there.

I mind a lot when I am being asked to spend real money and use real
electricity to no purpose at all, if it is going to be used and there is a
reason there is no problem.

> Secondly, the domain names show up in email headers, such as the
> Received: header.  Experience has shown that there is a very 
> large number of people who know enough to get their mail 
> agents to show the headers, and yet can not actually read and 
> detect forgeries in them. As a result, just having your 
> domain name show up near the top of the
> Received: headers can result in a lot of people incorrectly 
> assuming your domain is somehow responsible.

This is a much better reason. The admin of the reverse DNS is not great,
that can be improved but the admin zones are never going to match very well.

Reverse DNS is used to mean 'I am responsible for this IP address'. It is a
really good infrastructure for handing off services like INCH/RID. It is not
suitable for application level.

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 16 Jan 2005 11:40:59 -0800

> From: [email-masked] 

> In 
> <[email-masked]
> .vrsn.com> "Hallam-Baker, Phillip" <[email-masked]> writes:
> 
> > Actually the wildcards do absolutely nothing to solve any of the 
> > maintenance issues that John is concerned with, not one.
> >
> > The problem is that a wildcard only matches a node that 
> DOES NOT EXIST 
> > AT ALL. The only use for a DNS wildcard in the context of 
> spam is to 
> > say THIS NODE DOES NOT EXIST AT ALL from which the only reasonable 
> > assumption would be DO NOT ACCEPT EMAIL FROM THIS NODE.
> 
> If you do not accept email from nodes that don't exist, then 
> you will be throwing out a lot of legitimate email.  Far too 
> much email gets sent using HELO domains with either domain 
> names that are only viewable inernally, are typos, or are due 
> to misconfigurations for most people to take this stand.  
> Spammers and phishers have taken advantage of this situation.

In which case what you really want is something like the following, a
wildcard that defaults the lookup of the entire subtree to some existing
node then a set of policy records tied off that node. Ie.

*.example.com ---> default.example.com
exists.example.com  A blahhh
_prefix.default.example.com  TXT "Default policy record"

OK so we when we do the lookup for the node that exists we hit a record that
exists, find that there is no stated policy for that node.

If we look up anything else we hit the mapping record and get directed to
default. 

Just think of it as a wildcard SOA :-)

> 
> In theory, this is very true.  In practice, it has problems.  
> Such features do not exist in name server software, requiring 
> everyone to create local modifications.  Also, if every host 
> in your zone file needs to have an SPF, CSV, DK, RP, etc. 
> record added to it, you are going to greatly increase the 
> size of the zones.

These people said that there was no problem at all causing the .com zone
file to expand by about 10Gb. That was not a deployment problem that needed
to be considered so I don't think that 10,000 nodes times a few Kb is a show
stopper.

Companies such as AOL who have millions of records will simply use a DNS
server that can synthesize records on the fly if they have that much
difficulty. They probably already do something of this sort anyway.

The macro preprocessor thingie is only for folk who have smallish zone
files.