Re: [DNSOP] PSD records, was Verifying TLD operator authorisation

[John Levine]

In article  
you write:
>-=-=-=-=-=-
>
>If y'all care what gets published in a TLD, please take a look at
>https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
>which is an experimental draft that will go into WGLC last call soon.
>This was driven by wanting to add _dmarc records
>into TLDs, per ICANN rules it needs to be an RFC.

I'm not thrilled about it since I would prefer that we nerd harder on
the general domain boundary problems (the ones for which we all use
the PSL), but PSD for its particular use case of name trees seems
pretty harmless.

R's,
John

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

[DNSOP] IPR Disclosure Cisco s Statement about IPR related to draft-ietf-dnsop-serve-stale

[IETF Secretariat]

Dear David C Lawrence, Warren Ace Kumari, Puneet Sood:


An IPR disclosure that pertains to your Internet-Draft entitled Serving
Stale Data to Improve DNS Resiliency (draft-ietf-dnsop-serve-stale) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3590/). The title of the IPR disclosure is
"Ciscos Statement about IPR related to draft-ietf-dnsop-serve-stale"


Thank you

IETF Secretariat

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

[DNSOP] IPR Disclosure Cisco s Statement about IPR related to draft-ietf-dnsop-serve-stale

[IETF Secretariat]

Dear David C Lawrence, Warren Ace Kumari, Puneet Sood:


An IPR disclosure that pertains to your Internet-Draft entitled Serving
Stale Data to Improve DNS Resiliency (draft-ietf-dnsop-serve-stale) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3589/). The title of the IPR disclosure is
"Ciscos Statement about IPR related to draft-ietf-dnsop-serve-stale"


Thank you

IETF Secretariat

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

Re: [DNSOP] Verifying TLD operator authorisation

[Matthew Pounsett]

On Sat, 15 Jun 2019 at 19:36, Nick Johnson  wrote:

>  On Sat, Jun 15, 2019 at 2:21 AM Stephane Bortzmeyer 
> wrote:
>
>> On Fri, Jun 14, 2019 at 02:38:11PM +1200,
>>  Nick Johnson  wrote
>>  a message of 173 lines which said:
>>
>> > Indeed - it's my understanding that ICANN forbids publishing anything to
>> > the root zone other than necessary records such as SOA, NS and DNSKEY.
>>
>> You mean the TLD zone?
>
>
> Sorry, yes I did.
>
>
The set of allowed RRTYPEs in a gTLD zone can (and does) change, given a
reasonable justification, and enough interest and pressure from the
registries.  For example, the last revision of the Registry Services
contract that ICANN put out[0] added a record for zone versioning
independent of the SOA record.

You can get a new RRTYPE reserved for your purposes quite easily[1].  With
that, you could run a trial with some early-adopting ccTLDs (not
constrained by ICANN's Registry Services contract) to demonstrate the
utility of your scheme.  If it's attractive enough to warrant the internal
process and development costs to deploy, and the ICANN lobbying efforts,
then the gTLD operators could have it added to the contract.

Whatever your deployment method, you will need to demonstrate some benefit
to the registries if you want them to adopt your scheme.  Making changes to
their process isn't cheap, and there is no such thing as a one-off cost;
everything added to their operation needs to be maintained and monitored,
which incurs an ongoing cost.

[0]: Exhibit A, §1.1 <
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf
>
[1]: 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Verifying TLD operator authorisation

[Tim Wicinski]

If y'all care what gets published in a TLD, please take a look at
https://datatracker.ietf.org/doc/draft-ietf-dmarc-psd/
which is an experimental draft that will go into WGLC last call soon.
This was driven by wanting to add _dmarc records
into TLDs, per ICANN rules it needs to be an RFC.

Tim

(Murray Kucherawy, Seth Blank and myself may have something to do with the
DMARC working group management).



On Wed, Jun 19, 2019 at 7:41 PM Mark Andrews  wrote:

>
>
> > On 20 Jun 2019, at 8:45 am, Joe Abley  wrote:
> >
> > On 19 Jun 2019, at 18:28, Nick Johnson  40ethereum@dmarc.ietf.org> wrote:
> >
> >> On Tue, Jun 18, 2019 at 10:15 PM Bjarni Rúnar Einarsson 
> wrote:
> >> The SOA record for a TLD contains two DNS names which should be
> >> under the control of the NIC: that of the primary master
> >> nameserver, and the e-mail of the responsible administrator
> >> (which includes a domain name).
> >>
> >> This seems like an excellent idea - thanks! I'll wait to see what
> others have to say.
> >
> > I think you could probably build a heuristic around MNAME and RNAME that
> would work at least most of the time. However, there's no definitive
> identifier and there will always be exceptions you have to work around.
> Sometimes MNAME relates to a back-end registry provider, sometimes to a
> registry operator, and sometimes something else entirely. Ditto RNAME.
> >
> >> I think I addressed this upthread: If someone has the ability to change
> a zone's DNS records and generate valid DNSSEC signatures for them (which
> we will be requiring and verifying), they're sufficiently 'in control' of
> the zone that I'm comfortable treating them as the authorised user. If
> someone malicious has that control, the TLD owner has much larger problems.
> >
> > The organisation that generates the SOA/NS/A/ RRSets in a
> delegation-only TLD zone is not always the same organisation that signs it.
> Also, not all signatures in a zone can be guaranteed to have been created
> by the same organisation. Also, not all TLDs are signed.
> >
> > The contacts that the IANA relies upon to authorise changes for TLD
> operators can be found at whois.iana.org, for what that's worth, or in
> due course at the RDAP server specified in the object <
> https://data.iana.org/rdap/dns.json>. But if you're looking for something
> reliable you can validate using DNSSEC, I think you're out of luck.
>
> And if you try sending to them you find the email addresses are often
> do not exist, bounce because the mailbox is full, are gatewayed to a
> restricted distribution list, or just ignored.  Some do work though.
> My experience maybe biased because I’m always reporting problems when I
> send to them and if the operator hasn’t already noticed the problem
> there is a good chance the contact is also broken.
>
> > 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop