Re: [DNSOP] Proposal: Whois over DNS

I’m not sure the point aside of illustrating if there is no response for the domain records by the auth server that there would also be no response for a _whois record. That’s true. 

1) Using _whois is completely optional, like SPF or any other record. 
2) I can’t envision much legitimate need to contact a domain owner for something that doesn’t exist (aside of domain renewal spam or trying to buy the domain). 

Am I missing something?

—
John Bambenek

On July 1st, 2019, my DGA feeds are converting to a CC-BY-NC-SA 4.0 license which means commercial use will require a license. Contact sales@bambenekconsulting.com for details

On Jul 10, 2019, at 01:16, Mark Andrews <marka@isc.org> wrote:

> Take activedisplay.org.uk.  The DNS server for this zone has a broken
> DNS COOKIE implementation (see the mismatch between the request cookie and
> the response cookie).
> 
> COOKIE: 5dc8e2253d5f2702 
> COOKIE: e0d5650141611e0110474b0003000000dce86501ad361e01
> 
> % dig ns1.activedisplay.org.uk @88.208.234.46 +qr
> 
> ; <<>> DiG 9.15.1 <<>> ns1.activedisplay.org.uk @88.208.234.46 +qr
> ;; global options: +cmd
> ;; Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18721
> ;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 5dc8e2253d5f2702
> ;; QUESTION SECTION:
> ;ns1.activedisplay.org.uk.    IN    A
> 
> ;; QUERY SIZE: 65
> 
> ;; Warning: Client COOKIE mismatch
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18721
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: e0d5650141611e0110474b0003000000dce86501ad361e01 (bad)
> ;; QUESTION SECTION:
> ;ns1.activedisplay.org.uk.    IN    A
> 
> ;; ANSWER SECTION:
> ns1.activedisplay.org.uk. 86400    IN    A    88.208.234.46
> 
> ;; AUTHORITY SECTION:
> activedisplay.org.uk.    86400    IN    NS    ns1.activedisplay.org.uk.
> activedisplay.org.uk.    86400    IN    NS    ns2.activedisplay.org.uk.
> 
> ;; ADDITIONAL SECTION:
> ns2.activedisplay.org.uk. 86400    IN    A    88.208.234.46
> 
> ;; Query time: 332 msec
> ;; SERVER: 88.208.234.46#53(88.208.234.46)
> ;; WHEN: Wed Jul 10 15:31:53 AEST 2019
> ;; MSG SIZE  rcvd: 145
> 
> % 
> 
> Whois is useless
> 
>    Domain name:
>        activedisplay.org.uk
> 
>    Data validation:
>        Nominet was able to match the registrant's name and address against a 3rd party data source on 20-Jun-2015
> 
>    Registrar:
>        Fasthosts Internet Ltd [Tag = LIVEDOMAINS]
>        URL: http://www.fasthosts.co.uk
> 
>    Relevant dates:
>        Registered on: 20-Jul-2011
>        Expiry date:  20-Jul-2020
>        Last updated:  20-Jun-2019
> 
>    Registration status:
>        Registered until expiry date.
> 
>    Name servers:
>        ns1.activedisplay.org.uk  88.208.234.46
>        ns2.activedisplay.org.uk  88.208.234.46
> 
>    WHOIS lookup made at 06:50:41 10-Jul-2019
> 
> There is no web site.
> 
> The registrar’s web site is useless.
> 
> The SOA contact is a Compuserve email address which hasn’t yet bounced.
> Time will tell.
> 
> Mark
> 
>> On 10 Jul 2019, at 1:07 am, Joe Abley <jabley@hopcount.ca> wrote:
>> 
>> Hi John,
>> 
>>> On 9 Jul 2019, at 10:36, John Bambenek <jcb@bambenekconsulting.com> wrote:
>>> 
>>> If the proposal is to create a standard by which to put contact
>>> information into DNS records, what venue would you suggest?
>> 
>> I think that the protocol aspects of this are the least difficult ones. If this is fundamentally the data governance issue that I think it is, I think it would make a lot more sense to align exactly with what is happening in RDAP, treating self-publication as a new profile and DNS as a possible transport. If there's data to publish, thinking about transport afterwards seems far more sensible than inventing a transport and hoping that the data will follow.
>> 
>> RDAP profiles are not being discussed in the IETF. I think this is a feature.
>> 
>>>> I also agree that without any widespread incentive to implement, test and maintain, the data is going to be noisy and sparse to the point where it's useless for any practical use anyway.
>>> 
>>> You could say the same for SPF.
>> 
>> There's an operational incentive to publish SPF records: the need for recipients to accept legitimate mail that is being sent. I don't know what the operational incentive is to publish "whois" data in zone files.
>> 
>> 
>> Joe
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
> 