[RFCI-Discuss] wirralnews.com
Alex van den Bogaerdt
alex at ergens.op.het.net
Fri Sep 7 12:00:28 EDT 2007
OK,
If you don't mind then we discuss this some more.
On Fri, Sep 07, 2007 at 10:57:19AM -0400, Derek J. Balling wrote:
>
> On Sep 7, 2007, at 8:07 AM, Alex van den Bogaerdt wrote:
> >But you *do* have an authoritative NS set. It just happens to be
> >an empty set.
>
> And there's nothing necessarily "wrong" with an authoritative answer
> which says "there are no NSes" ... it's an unused domain, etc., etc.
I think you really ought to fill in "etc., etc.".
An unused zone (you mean zone, right?) cannot contain domains, which
in turn cannot hold RRs (Resource Records). So, if you are hunting
down wirralnews.com's MX records and you end up at an authoritative
answer "No such zone", then any MX record in this non-existing zone
is bogus as well. Even if that MX record would not otherwise match
the requirements for the rfci zone.
But this is all academic.
You have seen a clearly bogus MX record contents. All you want to
do is to see if an authoritative nameserver for the domain has
other information, in other words you want to verify the claim.
In this case, you cannot find such information. You can find the
MX record, so why not list it. I really don't see why not.
You would not list the domain if another server, one which does
officially provide answers, gives another answer than the record
you are hunting down. There isn't.
> >Never mind if this is too complicated to handle in real life. I was
> >just trying to help.
>
> This is like the old adage about pornography... the "I can't define
> indecent, but I know it when I see it." Does this LOOK hinky? Oh
> hell yeah. But can you find it in a programatic/algorithmic manner?
I can't, but I fail to see how this is relevant. Analyzing images
is much more complicated IMHO than what we are discussing.
> Ahhhh, that's not NEARLY so easy, without borking lots of other
> ways.... :-/
1: someone claims there is a bogus MX record
2: you search for this record, and find it
3: you need to make absolutely sure that you are not looking at
data which was given by a non-authoritative nameserver, even
if such a nameserver claims to be authoritative.
Therefore you need to hunt down delegation. Root points to gtld.
Gtld points to dnsnameserver.org. dnsnameserver.org claims there
is no such zone (authoritatively no SOA) and no nameservers (
authoritatively no NS). In addition these nameservers do know
about the bogus MX record.
If I understand what you are saying, you say that there are other
scenario's where you would end up at these nameservers, and thus
wrongfully accept a bogus MX record listing. For this to happen,
you need to look at a modified cache (for the bogus MX record),
and you need to be directed the wrong way by the gtld servers.
Correct?
Even if the servers pointed to by gtld nameservers do not exist,
do not answer or do not provide SOA and/or NS records in any other
way, the zone does not exist. Any further delegation can also not
work and thus any domain inside this supposed zone or any of its
subzones can also not exist. There's at most one path from the dns
root to a zone.
It seems to me that you are trying to prove that a record exists.
I think it is enough to prove that another record does not exist.
A subtle but relevant difference.
> That's all I've been trying to say from the beginning really... I am
> not claiming the site in question here has made an "honest mistake",
> and I'm not trying to protect them. I'm simply saying that changing
> the algorithm to be able to "catch" them opens up way way more cans of
> worms than could feed all of Hitchcock's birds. ;-)
If you don't want to, then just stop the conversation. But if you
are willing to educate me, I would be most interested in what problems
you expect.
Regards,
Alex
More information about the RFCI-Discuss
mailing list