Don Hackett: [BIND-BUGS #1090] [bind bug] leading zero's give bad address

[Tom Limoncelli]

Paul A Vixie wrote:
> 
> tom, i'm halfway in your camp already.  i've always hated this octal stuff
> for the individual octets of a dotted quad.  when i last rewrote inet_aton()
> i could have ripped it out.  several old RFC's print dotted quads with leading
> zeros in the octets and interpret the results as DECIMAL.

The fact that octal representation has even confused RFC authors
tightens my case.  Thanks!

> but even though i am sensitive to how broken and counterintuitive this is, i
> am likewise sensitive to the installed base and the number of people who might
> be depending on this function to work this way.  what do you think would happen
> if we made a late change of this kind?

I think some things would break.  They would be very minor.

The "bad breakage" is legit code that breaks.  This would be minor and
would be prevented if people had, say, a 6-month warning that the change
was coming.

The "good breakage" is people using octal codes to obfuscate things. 
Spammers advertise a url until it becomes a marker to indicate that that
message is spam.  Then they change to a url like http://3434221611 which
goes to the same site, but is not a marker.  When that string gets into
the spam-detector databases, they change it to dotted octal
combinations... of which there are many.  This would eliminate many of
their tricks.  As Martha Stewart would say, "It's a good thing.".

I do not think that there should be an option that enables the old
behavior.  That kind of cruft slows down systems for no particularly
good reason.  As someone (pv?) mentioned, it would make the atol routine
no longer self-contained.

--tal

P.S.  Wasn't the last big change to that parser when 3com.com became a
valid domain?  I'm surprised this wasn't fixed at the same time.

-- 
          Tom Limoncelli -- tal at lucent.com -- tal at plts.org