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 
sa...@bambenekconsulting.com for details

On Jul 10, 2019, at 01:16, Mark Andrews <ma...@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 <jab...@hopcount.ca> wrote:
>> 
>> Hi John,
>> 
>>> On 9 Jul 2019, at 10:36, John Bambenek <j...@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: ma...@isc.org
> 

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to