Re: [v6ops] WGLC for RFC6555bis

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Mikael Abraha
msson writes:
> On Mon, 14 Aug 2017, Mark Andrews wrote:
> 
> > ISP's and providers need to know when to switch off IPv4.  To do
> > that they will look at the amount of IPv4 traffic they are getting.
> > Devices that initiate IPv4 connections when there is a full working
> > IPv6 path just because there was a DNS cache miss don't help anyone
> > make that decision.  50ms is measuring cache misses not broken /
> > misconfigure authoritative servers and turning them into IPv4
> > traffic.  250ms is less so.  500ms is more less so.  This is just
> > with plain DNS.  Add DNSSEC into the mix where a cache miss may
> > well require multiple queries as DNSKEY and DS RRsets have also
> > expired 250ms is becoming too small.
> 
> You are correct, however, this problem should be solved in DNS land, not 
> in setting a really high advantage for IPv6 over IPv4 (at this point in 
> time).

The document fails to account for cache misses.  It assumes that
there will be *no* A or AAAA records present or that both A and
AAAA records will be present in the cache.  In both those caches
~50ms is fine as it accounts for variance in the lookups.

When only one of A or AAAA RRsets is present in the cache you have
lookup times < 10ms for the RRset that is present in the cache and
~200ms for the RRset that isn't in the cache but the nameserver
information is present.  Waiting a realistic period for the cache
miss to be filled is not "setting a really high advantage for IPv6
over IPv4".  It's giving them equal standing.

Another way to express this would be to require that the AAAA lookup
has a minimum amount of time to succeed before failing over to IPv4
which is of the order of the time of a cache refresh.

Below is a example of a cache miss for bbc.co.uk/A where the answer
is fetched from the other side of the world.  Thats one UDP there
and one UDP packet back.

[rock:~/git/bind9] marka% dig a bbc.co.uk
;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> a bbc.co.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38363
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d3a9ce37593e504dfd7a68a45991596c1a2a6c63bc284349 (good)
;; QUESTION SECTION:
;bbc.co.uk.			IN	A

;; ANSWER SECTION:
bbc.co.uk.		300	IN	A	212.58.246.79
bbc.co.uk.		300	IN	A	212.58.244.23
bbc.co.uk.		300	IN	A	212.58.244.22
bbc.co.uk.		300	IN	A	212.58.246.78

;; Query time: 206 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 14 18:03:56 AEST 2017
;; MSG SIZE  rcvd: 130

[rock:~/git/bind9] marka% 

 
> So while everything you say is correct, I do not agree with your 
> prioritization of "avoid long tail IPv4 usage" as opposed to "if IPv6 is 
> broken, the user will turn off IPv6 (forever) because it slows down the 
> user experience once".

When IPv6 lookups are broken they usually take significantly longer
than a additional 200ms to complete as you end up with multiple
queries being made.

> I also think that the caching resolver should refresh soon-to-be-expired 
> RRs that are getting close to their TTL=0. For instance, if someone is 
> asking for an RR and it has less than 5% of its TTL left, then just 
> refresh it.

Which hides some cache misses from the client but not all of them.
Been there, done that.

> I believe there are drafts regarding this in DNSOP?
> 
> https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 
> is one. I thought there was another one, but I can't find it right now.
>
> -- 
> Mikael Abrahamsson    email: [e-mail]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]