ietf
[Top] [All Lists]

Re: Last Call: draft-jabley-reverse-servers (Nameservers for IPv4 and IPv6 Reverse Zones) to Proposed Standard

2010-01-05 15:45:26
"Olafur" == Olafur Gudmundsson <ogud(_at_)ogud(_dot_)com> writes:


    Olafur> There is one case where knowledge and special handling of
    Olafur> the name may cause problems: DNS "Liers" i.e. specialized
    Olafur> DNS resolvers that make all non-existing name exist that do
    Olafur> not generate "lie" for sink.arpa.

    Olafur> In this case the name can not be used as test of the
    Olafur> resolvers truthful ness.  If an application knows about the
    Olafur> name that is not a problem as all that will do is to avoid a
    Olafur> name lookup, and this is exactly the reason we want the name
    Olafur> to be have explicit semantics that can not change and are
    Olafur> under IETF/IAB "control" not ICANN's.
I cannot parse the above.
I cannot tell whether you are saying  that those who wish to monatize
    Olafur> DNS error traffic (which I believe is part of the tag line
    Olafur> for a popular such service) should or should not return a
    Olafur> result for sink.arpa.
Nor can I tell whether you're saying they will do so.

I'm quite certain that if someone's business model depends on violating
this specification that they will do so.

It sounds like you're saying that you want a name to use to test and see
if you are getting bogus DNS responses but you're not willing to say
that in a spec.  If so, I think this will be ultimately ineffective and
I think it is misleading to publish a spec without explaining what it's
good for.

In summary, I'm not strongly objecting.  However I do continue to feel
that a clear explanation of what's going on here is not being provided
and that the uses as I understand them seem ineffective.  However this
clearly falls into the category of "mostly harmless".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>