To go along with this proposal, maybe we can adapt the approach from RFC3514
for DNS?
We could send a new RRTYPE with a bitfield value, giving a more granular level
of detail than that in RFC3514. RFC3514 was constrained to only use one bit
because IP headers are small; with DNS, we don't have the same level of
constraint.
I would suggest that responses for all new GTLDs have the bit for "evil" set to
1, unless responses are sent via RFC1149, in which case they'd merit a default
of 0.
On Jul 9, 2019, at 05:09, Vittorio Bertola
<vittorio.bertola=40open-xchange....@dmarc.ietf.org
<mailto:vittorio.bertola=40open-xchange....@dmarc.ietf.org>> wrote:
>
>> Il 9 luglio 2019 00:01 John Bambenek
>> <jcb=40bambenekconsulting....@dmarc.ietf.org
>> <mailto:jcb=40bambenekconsulting....@dmarc.ietf.org>> ha scritto:
>>
>>
>> Like I said, I’m ok with someone lying to me. Its easy to detect
>> and easy to deal with. For instance, in DNS a mailserver could
>> query these records, see phone number is set to 0000000000 and
>> then just reject email from said domain. With existing whois that
>> was never possible, due to rate limiting.
>
> At first sight, your proposal looked ok - if someone wants to publish their
> information voluntarily, why not? But then I read this and now I am seriously
> concerned: it looks like this is explicitly being designed to penalize
> registrants that care about their privacy and choose not to publish
> information about themselves (or publish fake information, which used to be
> the only practical way in the old mandatory Whois times).
-david waitzman
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
