Subject: Re: [spfbis] 4408bis update

From: Arthur Thisell <[email-masked]>
Date: Sat, 18 Aug 2012 07:12:03 -0700 (PDT)

>>Does today's message from Arthur Thisell answer this:
>
>Not really.  
>
>> then isn't it a matter of issuing a query and seeing what 
>>you get back?  If it doesn't meet the relevant requirements to do than, then 
>>it's got to be a permerror.  I'd welcome improved text.
>
>The problem is that it's ill specified.  If you give a resolver
>library an invalid domain name, there's no guarantee that it will
>politely reject it.  It might crash or do other random badness.  This
>isn't a permerror, since the SPF record might well work if used on a
>message with a less nasty bounce address.  Waving my hands, I'd
>suggest a soft fail if a macro expansion creates an invalid domain
>name.

OK, I think we need to be very careful with terms here.

* "host names" have restrictions defined in various RFCs, and those restrictions have changed over the years. Basically, host names have Letter-Digit-Hyphen restrictions.

* "domain names" are things in the DNS and have almost no restrictions beyond what is reiterated in RFC4408bis from DNS RFCs.  Basically a null label has to be at the end, no labels more than 63 octets, no more than 253 octets in total.

* "stuff commonly thrown at the DNS".  This is probably some superset of "host names", but includes things like underscores, all digit labels, etc.

Next, any resolver that has any significant use has had random, uninitialized data thrown at it.  There were serious proposals for IDNs of just letting UTF-8 being used, but they were ruled out not because of any DNS/resolver problems, but because too many application level programs assumed that all domain names were host names.

Last, back before RFC4408 was even being drafted, I did tests on being able to add weird labels to a bind zone file and being able to use dig to look them up, and throwing such labels at libspf2.   I don't remember what all I tested, but it was at least labels with "@", "." and " ".

We added stuff in RFC4408 about DNS over TCP being less reliable because in real-word tests, we found firewalls that threw out any port 53 traffic that wasn't UDP.   Has anyone ever found a real-word resolver that barfs on uncommon domain names?

I really resist adding any language to RFC4408bis about "invalid domain names" beyond what the RFCs specify.   We don't want to restrict all lookups to being strictly host names.   I really don't want to try and define what "common stuff thrown at the DNS" means.  Trying to make such a definition would likely yield far more bugs than are in resolvers.

I'm really not sure what, if anything, should be added here.  Maybe a warning that there might possibly be bugs in some versions of some resolvers that do not handle all domain names?   Should we warn about all potential bugs everywhere?   I lean toward staying silent until we have some evidence that it is a real problem.

>You'd have to find a TCP stack more than 15 years old for TCP sequence
>guessing to be a problem.

Yeah, I never thought that forging TCP sequence numbers was that much to worry about, but back when RFC4408 was being drafted, problems were more recent.   I don't even know if firewalls throwing out port 53 TCP traffic is that common any more.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 18 Aug 2012 12:58:08 -0400

On Saturday, August 18, 2012 07:12:03 AM Arthur Thisell wrote:
...
> Yeah, I never thought that forging TCP sequence numbers was that much to
> worry about, but back when RFC4408 was being drafted, problems were more
> recent.   I don't even know if firewalls throwing out port 53 TCP traffic
> is that common any more.

It's sufficiently common that we still need to warn about it, IMO.  There are 
also resource considerations that also make UDP preferred even if reliability 
weren't a concern.

Scott K