this was sent personally, but i'm answering to the list.
It might help the A Root, at least, if the SOA record listed
bogus.root-servers.net instead of A.root-servers.net, and then a record
mapped bogus.root-servers.net to 127.0.0.1. That should keep Win2K and
follow-ons from sending dynamic updates to the root zone.
now that we have separate servers for the rfc1918 ptr zones, these updates
are not going to the root servers and indeed cannot affect the root servers.
since ddos attack backscatter shows up in these log files, it's darn useful
to centralize the logging for it.
any AS owner who wants to localize these updates can do so by simply
anycasting the 192.175.48/24 netblock and serving dns on .1, .6, and .42.
SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing email to bounce (amongst other things). Is there something out there specifically describing putting [your.domain].local in the SOA to achieve this? What is the rational behind this?
Best Regards,
Simon
Ermm... Do you have any actual evidence for this assertion? An mta that
examines MNAME is horribly, horribly broken. I can't imagine anything
but the worst sort of spamware actually doing this.
-Pete
>
> SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing
> email to bounce (amongst other things).
Ermm... Do you have any actual evidence for this assertion?
Not yet. But the common thread to this is that every domain that vanishes (and causes email to bounce) has got a bogus MNAME entry (i.e. MNAME is unroutable). This isn't a root specific problem as legacy root users have reported this problem alongside ORSC users. The bogus MNAME may be a red herring, but it's what we're looking at as a possible common cause.
An mta that
examines MNAME is horribly, horribly broken. I can't imagine anything
but the worst sort of spamware actually doing this.
Yes, but given that all software is broken by nature, and that there is a filing cabinet full of CERT advisories, why would you be surprised at either SendMail or BIND being the culprit under certain circumstances? Maybe even for a totally different reason.
Best Regards,
Simon
Hmm... Bork-ware box boots, gets a DHCP address, tries to stick it into the
AD tree at the MNAME address, and loses. It then tries to send mail,
and the remote end bounces it because it doesn't have a valid PTR entry?
Yes, a DHCP'ed mail server is silly, and rejecting mail entirely because
of a missing PTR is silly - but this is a world where sites reject mail
that has a 'MAIL FROM:<>' and then wonder why things dont work....
Just 2AM speculation, but I've seen stupider failure modes.. 
I wouldn't know how that could happen.
However, we see *very* sporadic http connections the mname of a popular zone
(iex.nl) and even have one report of somebody seeing a page hosted on its
mname when trying to visit iex.nl.
But we're very unsure why this is happening. It looks like some kind of
fallback 'if there is no A record for what I'm looking for, try the mname of
the SOA of the zone' perhaps?
It has been too sporadic to investigate properly.
Regards,
bert hubert
In the immortal words of Simon Higgs (simon@higgs.com):
SOAs with bogus.domain.names pointing to 127.0.0.1 appear to be causing
email to bounce (amongst other things).
If there is actually an MTA out there so broken that it tries to
connect to the server mentioned in the SOA MNAME field instead of the
MX or A record for that domain, I'd be inclined to consider this a
benefit, not a drawback.
-n, (Let me guess...cc:SMTP?)
------------------------------------------------------------<memory@blank.org>
"We build our computers the way we build our cities -- over time, without a
plan, on top of ruins." (--Ellen Ullman)
<http://blank.org/memory/>----------------------------------------------------