make AAAA type the default for dig

[Sachin Garg]

On the point of customers not getting IPv6 (last point below) please see
this issue for android opened 5 (!) years ago:

Support for DHCPv6 (RFC 3315)
https://issuetracker.google.com/issues/36949085

So, when a corp like Google also takes such a pathetic position, what
can one say about ISPs?


On Wednesday 14 June 2017 09:56 PM, Timothe Litt wrote:
> On the original topic, it would be nice to have a dig option that
> returned both A and AAAA with one command.
>
> Since it does this, I tend to use 'host' (note that host -v gives the
> same response detail as dig -t A ; dig -t AAAA; and dig -t MX).
>
> On the other remarks, inline.
>
> On 14-Jun-17 21:09, Mark Andrews wrote:
>> In message <20170614132510.6ff832a5 at ime1.iment.local>, Paul Kosinski writes:
>>> Has IPv4 faded away and I didn't notice? Unlike the well planned switch
>>> to Area Codes, IPv6 is not backward compatible.
>> It has started to fade away.  If you have IPv6 at home, statistically,
>> most of your traffic will be IPv6.  There will be outlier homes but
>> in general IPv6 will carry more traffic than IPv4.
> Not that I've noticed here in the US.  Comcast does have IPv6 to the
> home (well, except for some of their
> acquisitions that haven't been upgraded yet.)  Pretty much no other
> ISP offers it.  The fiber projects - google and verizon both stopped
> deployment (of fiber).  I think Google's supports IPv6.  Verizon does not.
>
> Beyond that, you can get fiber (and sometimes IPv6) if you're a large
> business.  When I looked for an alternative to Verizon, I was quoted
> ~$50K for an "engineering feasibility study" for getting fiber to the
> house, with corresponding monthly charges.  Not viable for my hobbies.
>
> There are some fringe ISPs in a few markets that offer IPv6 over DSL
> if you insist - but who wants DSL speeds (and prices) when you can
> usually at least get cable, and if you're lucky fiber at a much lower
> cost/bit/sec?
>
>> B2B traffic isn't quite as high but there too IPv6 takes a significant
>> amount of traffic.
>>
>>> (The telcos would have gotten rather a lot of complaints if they said
>>> every had to get a new telephone number, and also -- new telephones.)
>> I've had to get new telephone numbers to fit in more customers over
>> the years with support for the old number being removed after a
>> year or so.
>>
>> 	462910 -> 4162910 -> 94162910
> Yes, here in the US we have periodic "area code" splits that cause
> renumbering, stationary and advertising changes, and general angst.
>
>> As for new telephones, yes this has been manditory, switching from
>> rotary to DTMF.  There was a period of overlap but support for
>> rotary phones was turned off in the exchange.
> Rotary phones are still supported here.
>
> But I use VoIP.  Over IPv4.  (And my VoIP adapters do support rotary
> dialing....)
>
>> Most of you have thrown out several generations of computing devices
>> that have supported IPv6 without even being aware you were doing
>> so.  IPv6 support is 20+ years old.  My daughter, who has now left
>> home, has lived her entire life with equipement in the house that
>> has supported IPv6.  The house had working IPv6 connectivity before
>> she went to primary school.  She graduatuted from Y12 last year.
>>
>> I'm still waiting for my ISP to turn on IPv6.  The CPE router
>> supports it.  I just routed around them to get IPv6 at home.
> I still can't get native IPv6 - but I have FTTH and can get 500Mb/s
> IPv4 (for a price I won't pay).
> So Tunnels.  BTW, SixXS has retired, leaving no U.S. tunnel provider
> that supports DNSSEC
> for the reverse delegations.  (Well, none in my price range.)
>
> Bottom line is that experiences vary.  The US has a complex regulatory
> environment - and large diverse geography.  It moves with a deliberate
> lack of speed.
>
> The other consideration for the ISPs is that it's a lot harder for
> them to justify charging for static/more than 1 IPv6 address.  There's
> an extreme disincentive for them to cut their revenue stream.  (I've
> seen some plans where they're seriously proposing to issue /128s.  As
> you say, Luddites - capitalist Luddites.  Sigh.)
>
> The address space exhaustion hasn't really moved the needle at the
> consumer/small business level - the ISPs are quite happy to NAT - and
> they hoard.
>
>> If you have a piece of computing equipement bought in the last 10
>> years that doesn't suppport IPv6 today it is because the manufacture
>> is a ludite, not because IPv6 doesn't work.
> Agree, though there is also the point of view that since customers
> cant' get IPv6, shipping it in products adds cost (qualification, risk
> of bugs, memory/documentation) with no perceived benefit to the vendor
> or customer.  I don't subscribe to that POV - but it isn't entirely
> irrational.
>
>> Mark
>>
>>> On Wed, 14 Jun 2017 22:10:25 +1000
>>> Mark Andrews <marka at isc.org> wrote:
>>>
>>>> In message <f165d73a-ef43-a28e-758a-3a509eabc930 at sidn.nl>, "Marco
>>>> Davids (SIDN)" writes:
>>>>> Hi,
>>>>>
>>>>> Not sure if this has been proposed before, but I am wondering:
>>>>>
>>>>> Has ISC ever considered to change the default 'dig -t' option from
>>>>> A to AAAA?
>>>>>
>>>>> --
>>>>> Marco
>>>> This would break too many scripts.  You can do this for yourself
>>>> by setting the type in $HOME/.digrc
>>>>
>>>> % cat ~/.digrc
>>>> -t AAAA
>>>> % dig isc.org
>>>> ;; BADCOOKIE, retrying.
>>>>
>>>> ; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>> isc.org
>>>> ;; global options: +cmd
>>>> ;; Got answer:
>>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1235
>>>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL:
>>>> 1
>>>>
>>>> ;; OPT PSEUDOSECTION:
>>>> ; EDNS: version: 0, flags:; udp: 4096
>>>> ; COOKIE: 3ababe63d14205ae8cec9f7659412776a8b43cb46b335466 (good)
>>>> ;; QUESTION SECTION:
>>>> ;isc.org.			IN	AAAA
>>>>
>>>> ;; ANSWER SECTION:
>>>> isc.org.		6	IN	AAAA
>>>> 2001:4f8:0:2::69
>>>>
>>>> ;; Query time: 0 msec
>>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>>>> ;; WHEN: Wed Jun 14 22:09:26 AEST 2017
>>>> ;; MSG SIZE  rcvd: 92
>>>>
>>>> % 
>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170614/d9e820d2/attachment.html>