[RFCI-Discuss] wirralnews.com

[Alex van den Bogaerdt]

On Sat, Sep 08, 2007 at 05:43:56PM -0400, Derek J. Balling wrote:

> On Sep 8, 2007, at 3:07 PM, Alex van den Bogaerdt wrote:
> >record".  After gettin the "zero NS records" answer, you do not
> >need to ask other nameservers, do you?
> 
> Yes, I do, because other nameservers might return different results.  
> And "demonstrably bogus NS records (or lack of NS records entirely)"  
> is not within the scope of the bogusmx zone.

OK,

I do not have to agree but I do understand what you say.

I am not trying to have you list bogusns data in the bogusmx zone.

I will try to show, backed by RFC 2181 and 1034, why I think you
should just accept the MX answer given to you.  And if that MX
record has bogus content, the domain belongs in bogusmx.

> If you're not in the NS set **I don't care what your answer is because  
> nobody should be listening to you, regardless of who told them you  
> were ok, and regardless of whether or not you set the AA flag**.

OK,

you're saying here that you don't give any credit to the parent.

When the parent points to other nameservers, you want those other
nameservers to have NS records pointing to themselves, or else
you are not going to believe them.

This effectively means you are not going to catch the real cheaters,
only those that do not effectively "hide" themselves.


> >3: I got an answer, but I'm ignoring it because the server denies
> >  to be a nameserver for the domain eventhough the parent says so.
> 
> A zone can certainly abandon authority, or say explicitly "nobody  
> actually is authoritative for this zone".

OK,

then let's explore this case.  If nobody is responsible for the
zone, then the zone does not exist.  Therefore the MX record won't
be found, thus cannot be tested, and the domain won't be listed.

I consider this a bug in the system.  I mean rfci, not dns.


Some escapes:

The zone does not exist, but in the wild resolvers do find
authoritative data.  Accept that data, just because nothing
better is at hand.

The zone does not exist but according to its parent, it should.
Believe the submitter, and accept the request to list.
(personally I think this is the most dangerous one).

The zone does exist, but its keeper forgot or "forgot" to add
NS records and a SoA record.  Accept the zone anyway, because
it not only says it provides authoritative data but so does
its parent.  It isn't a random nameserver that happens to say
it provides authoritative data, it is *the* nameserver which
is *expected* to do so, and it does.


IMHO the last mentioned escape is the proper thing to do, because
it is safe.

RFC 2181 has a section on this. See 5.4.1 (ranking data).
NS records provided by the parent are listed there 6th in rank.
You don't have a better answer, and you can trust the parent
to provide a good answer.

2181 isn't a STD yet, so I also looked in 1034.  Interestingly,
the algoritm presented there seems to allow you to accept the
MX response, without checking the NS record.  Section 5.3.3
step 4 paragraph 3 looks at the NS records provided by gtld
servers.  The delegation is accepted, back to step 1, continue
to step 2 and ask server dpns1.dnsnameserver.org. about the
MX record for domain wirralnews.com.  An authoritative answer
is given, no further delegation. End of search, return the data.


cheers
alex