make AAAA type the default for dig

Timothe Litt litt at acm.org
Thu Jun 15 01:56:03 UTC 2017


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
>>>
>>> % 
>>>
>> _______________________________________________
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170614/7787a4c1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4577 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20170614/7787a4c1/attachment.bin>


More information about the bind-users mailing list