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