Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

[Mukund Sivaraman <[e-mail]>]

On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> On Fri, Jun 22, 2018 at 8:57 AM Joe Abley <[e-mail]> wrote:
> 
> > On 19 Jun 2018, at 17:03, Ray Bellis <[e-mail]> wrote:
> >
> > > On 19/06/2018 17:44, Tony Finch wrote:
> > >
> > >> SRV should have been part of the fix (and it was invented early
> > >> enough to be!) but it wasn't a complete fix without support from the
> > >> application protocols.
> > >
> > > AIUI, a large part of the supposed issue with SRV was the inertia of the
> > > installed base of browsers that wouldn't know how to access them.
> > >
> > > Ironically the proposed fix seems to require upgrades to the
> > > installed base of one of the most important network infrastructure
> > > services on the planet.
> > >
> > > Meanwhile, a very large portion of the installed base of web browsers
> > > gets automatically and silently upgraded every month or so...
> >
> > I think so long as there's a fallback for clients that don't yet have SRV
> > implemented (e.g. publish A/AAAA RRSets at the same owner name as the SRV
> > RRSet, and specify the behaviour by SRV-compliant servers in the event that
> > both are present) this is not a plausible engineering argument.
> >
> > Processing an SRV might require additional DNS lookups to get name -> SRV
> > -> SRV target -> address, but that's a one-time hit per TTL and I think
> > it's a stretch to paint that as definitely a problem. Modelling is required
> > and worst cases remain to be understood.
> >
> 
> ​It certainly is the ​case that a number of browser / large web properties
> have stated that an additional DNS lookup is a price that they are not
> willing to pay, especially for something not "critical".
> 
> I believe that this also would require firing off simultaneous lookups for
> SRV along with the A and AAAA (or, even worse, firing off a SRV, waiting
> for the "nooerror" error and *then* trying for the A / AAAA) and waiting
> for the long tail before you even know of you need to resolve the target.

With additional-from-cache (default on), BIND will return address of
target of SRV if it is already in cache. The second RTT will get
amortized. It won't take a lot to make it fetch and return the target
too, if it isn't found in cache.

[muks@jurassic ~]$ dig -t srv _xmpp-server._tcp.conference.banu.com

; <<>> DiG 9.11.3-RedHat-9.11.3-4.fc27 <<>> -t srv _xmpp-server._tcp.conference.banu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42270
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0578a97e07ef62a47b1993205b2d491527ff6b5b4672bea0 (good)
;; QUESTION SECTION:
;_xmpp-server._tcp.conference.banu.com. IN SRV

;; ANSWER SECTION:
_xmpp-server._tcp.conference.banu.com. 3543 IN SRV 0 0 5269 jabber.banu.com.

;; AUTHORITY SECTION:
banu.com.		3003	IN	NS	ns2.akira.org.
banu.com.		3003	IN	NS	ns1.banu.com.

;; ADDITIONAL SECTION:
jabber.banu.com.	3599	IN	A	46.4.129.229
ns2.akira.org.		3004	IN	A	46.4.129.253
ns1.banu.com.		3003	IN	A	46.4.83.135

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 23 00:38:05 IST 2018
;; MSG SIZE  rcvd: 222

[muks@jurassic ~]$ 

		Mukund