>> > except that we heard at the side meeting in Montreal (albeit from >> > browser people rather than content people) that they *don't* want >> > SRV, because it has fields that are not compatible with the web >> > security model. >> >> Can you summarize the particulars of the web security model (I'm not >> sufficiently well versed in that area to immediately key off that >> phrase) which makes use of SRV non-attractive? Is the aspect that a >> URL can contain a port number part of the problem, or is it >> something (a lot?) more involved? >> >> When defining the use of SRV for the web protocols (something which >> remains to be done), one could of course standardize "ignore the >> port number in the SRV record, use the port number from the URL, or >> whatever http and https defaults to", especially if that makes the >> problem go away. > > What I said in Montreal is SRV works great if you are a robot, > but when humans are involved it never ends well.
I must say I'm not able to follow that argument. Can you please explain? This is also a different argument than the one I asked about above, about the web security model and how SRV is incomatible with it. > I also don't see the issue with online signing, but that is just me. There are current operational DNSSEC deployments where the publishing name servers do not have access to the key material needed to sign new or "dynamic" records in the zone on the fly. Insisting that the publishing name servers all have to have the private key material available in order to sign new or "dynamic" records is in my view a Major Change to DNSSEC. Regards, - Håvard _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
