In message <[email protected]>, Saku Ytti writes: > On (2014-05-21 12:38 +0100), Tony Finch wrote: > > Hi, > > > SVCINFO still requires concurrent A and AAAA queries. > > Until newer versions of current protocols replace current protocols and > mandate SVCINFO (or requivalent) at which case client has no need to query fo > r > anything else. > Some services mandate SRV, but even then they must query A/AAAA as well, with > SVINFO they wouldn't need to.
Hog wash. Both SRV and SVINFO supply addresses via additional section processing. Additional records like these are always optional. Additionally SVINFO doesn't support indirection to different machines which is one of the primary features of SRV. The reason why CNAME like functionality is wanted at the apex of a zone. SVINFO doesn't come close to being a alternative to ENAME or CNAME or SRV. > ---- 2.3 ---- > In all cases when an SVCINFO record is returned, all A and AAAA record for > the domain SHOULD be returned in the additional information section. This > eliminates excess queries without adding additional risk of cache > poisoning. > ------------- > > > I don't see how it does anything to reduce the need for anycast. > > It would not reduce need for anycasting, but that is not the common > application for BGP. Most typically you have no geographical diversity or > deliver-to-closest-exit strategy, you have single location, but vou need > global BGP visibility to offer your service to clients even in absense of > single connection. > If DNS could (like SRV could) tell alternative options, then client could mas > k > the outage of single connection, not requiring server to be have redundant > connection with single IP. > > -- > ++ytti > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
