Re: [DNSOP] Extended CNAME (ENAME)

(2014/05/22 14:00), S Moonesamy wrote: > Hi John, > At 10:43 21-05-2014, John Levine wrote: >> See RFC 1123, section 5.2.2. > > Tony Finch already commented about RFC 1123. That section has been > replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for mail > submission and CNAME.

Re: [DNSOP] Extended CNAME (ENAME)

Hi John, At 10:43 21-05-2014, John Levine wrote: See RFC 1123, section 5.2.2. Tony Finch already commented about RFC 1123. That section has been replaced (see RFC 5321). Section 8.7 of RFC 6409 is applicable for mail submission and CNAME. Regards, S. Moonesamy

Re: [DNSOP] Extended CNAME (ENAME)

Saku Ytti wrote: > Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the > draft, it made really compelling arguments to me. > Goal should be that 1 query returns all the information client > needs to decide The problem of URI and SVCINFO RRs is that they return too much infor

Re: [DNSOP] Extended CNAME (ENAME)

Tony Finch wrote: >> What? A CNAME, redirection purely within DNS, rewrites an email >> address? > > See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and > successors. Perhaps, it is a misunderstanding of a suggestion of rfc974: Note that the algorithm to delete irrelevan

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: >>> Sure, but I am talking of about 5-20 variants per name, not all that are >>> combinatorially possible. > The idea is that the registrant simply decides which of the variants he > wants to have included with his original name. Those would be added to > the zone via redir

Re: [DNSOP] Extended CNAME (ENAME)

In message <20140521123324.ga2...@pob.ytti.fi>, Saku Ytti writes: > On (2014-05-21 12:38 +0100), Tony Finch wrote: > > Hi, > > > SVCINFO still requires concurrent A and queries. > > Until newer versions of current protocols replace current protocols and > mandate SVCINFO (or requivalent) a

Re: [DNSOP] Extended CNAME (ENAME)

In message , Ralf Weber writes: > Moin! > > On 21 May 2014, at 16:16, Mark Andrews wrote: > > More that it was assumed that people would read the rfc and enforce > > the prohibition themselves. When that wasn't happening it was first > > made into a warning '97 and fatal in '99. > > IMHO a softw

Re: [DNSOP] Extended CNAME (ENAME)

Moin! On 21 May 2014, at 16:16, Mark Andrews wrote: > More that it was assumed that people would read the rfc and enforce > the prohibition themselves. When that wasn't happening it was first > made into a warning '97 and fatal in '99. IMHO a software should not allow me to make incorrect entrie

Re: [DNSOP] Extended CNAME (ENAME)

>What? A CNAME, redirection purely within DNS, rewrites an email >address? Yes, of course. See RFC 1123, section 5.2.2. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Extended CNAME (ENAME)

Getting validators updated will just happen once the code is written. Try to find a validator that doesn't accept NSEC3 records today. It is actually hard to do. RFC 5155 is just over 6 years old at this point. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE:

Re: [DNSOP] Extended CNAME (ENAME)

Commenting on deployment... On May 20, 2014, at 11:11 PM, Mark Andrews mailto:ma...@isc.org>> wrote: In message <537c15b4.2000...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: Mark Andrews wrote: The reason why CNAME is prohibited at a zone apex is described in

Re: [DNSOP] Extended CNAME (ENAME)

On Wed, May 21, 2014 at 10:50:42AM +0200, Klaus Malorny wrote: > interesting for domain name registries that have to deal with (maybe > lots of) IDN variants. I don't think that SRV records are a viable > solution for their use case. While this is true, xNAME remains a crummy way to handle variant

Re: [DNSOP] Extended CNAME (ENAME)

In message , Ralf Weber writes: > Moin! > > On 21 May 2014, at 10:50, Klaus Malorny wrote: > > please take into account that a CNAME + DNAME, the previously discussed BNA > ME or the now discussed ENAME solution is still interesting for domain name r > egistries that have to deal with (maybe lot

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 13:30, Masataka Ohta wrote: Klaus Malorny wrote: Sure, but I am talking of about 5-20 variants per name, not all that are combinatorially possible. I'm afraid you don't distinguish "name" and "label". Anyway, what if you encounter a label with 21 variants? Are you saying regis

Re: [DNSOP] Extended CNAME (ENAME)

On (2014-05-21 12:38 +0100), Tony Finch wrote: Hi, > SVCINFO still requires concurrent A and queries. Until newer versions of current protocols replace current protocols and mandate SVCINFO (or requivalent) at which case client has no need to query for anything else. Some services mandate S

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > > What? A CNAME, redirection purely within DNS, rewrites an email > address? See RFC 1123 section 5.2.2. This requirement was dropped in RFC 2821 and successors. Tony. -- f.anthony.n.finchhttp://dotat.at/ West Shannon: Northerly 6 to gale 8. Rough or very rough. Showe

Re: [DNSOP] Extended CNAME (ENAME)

Tony Finch wrote: >> What's wrong with allowing a zone apex have SOA, NS, CNAME but >> nothing else? > > One problem is that CNAME pointing at MX is an interop disaster area, > since different MTAs disagree about whether this implies an email address > rewrite. What? A CNAME, redirection purely

Re: [DNSOP] Extended CNAME (ENAME)

Saku Ytti wrote: > Any opinions on SVCINFO. I was really big fan of SRV until I read the > draft, it made really compelling arguments to me. It doesn't provide indirection, and it piles potentially-unrelated SVCINFO records on to the same QNAME. It would be better to prefix the QNAME with _servi

Re: [DNSOP] Extended CNAME (ENAME)

Masataka Ohta wrote: > > What's wrong with allowing a zone apex have SOA, NS, CNAME but > nothing else? One problem is that CNAME pointing at MX is an interop disaster area, since different MTAs disagree about whether this implies an email address rewrite. Tony. -- f.anthony.n.finchhttp://d

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: > Sure, but I am talking of about 5-20 variants per name, not all that are > combinatorially possible. I'm afraid you don't distinguish "name" and "label". Anyway, what if you encounter a label with 21 variants? Are you saying registries MUST reject registrations requests

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 12:08, Masataka Ohta wrote: Klaus Malorny wrote: please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registries that have to deal with (maybe lots of) IDN variants. Scalability of

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 11:52, Ralf Weber wrote: Moin! Hi Ralf, Oh and then came DNAME for redirecting whole domain trees and that might have been a nice idea if I have a couple of domains and want them all to have the same data. But I do not know of Registries/Registrars that picked that up. Or is t

Re: [DNSOP] Extended CNAME (ENAME)

Any opinions on SVCINFO[0]. I was really big fan of SRV until I read the draft, it made really compelling arguments to me. I'm not sure I agree on how the information is encoded, coworker sent some of his thought to the author explaining how to encode in a way which makes machine-parsing easier. B

Re: [DNSOP] Extended CNAME (ENAME)

Klaus Malorny wrote: > please take into account that a CNAME + DNAME, the previously discussed > BNAME or the now discussed ENAME solution is still interesting for > domain name registries that have to deal with (maybe lots of) IDN > variants. Scalability of IDN labels of equivalent characters

Re: [DNSOP] Extended CNAME (ENAME)

Moin! On 21 May 2014, at 10:50, Klaus Malorny wrote: > please take into account that a CNAME + DNAME, the previously discussed BNAME > or the now discussed ENAME solution is still interesting for domain name > registries that have to deal with (maybe lots of) IDN variants. I don't think > that

Re: [DNSOP] Extended CNAME (ENAME)

On 21.05.2014 08:09, Mark Andrews wrote: What's wrong with: _http._tcp.example.net. SRV ... www.example.net. Nothing. Hi, please take into account that a CNAME + DNAME, the previously discussed BNAME or the now discussed ENAME solution is still interesting for domain name registr

Re: [DNSOP] Extended CNAME (ENAME)

In message <537c47f9.4040...@necom830.hpcl.titech.ac.jp>, Masataka Ohta writes: > Mark Andrews wrote: > > >> What's wrong with: > >> > >>_http._tcp.example.net. SRV ... www.example.net. > > > > Nothing. > > So, without (C/E)NAME changes, the possibility of the following > configuration: >