> On Thu, 18 Dec 2003 [EMAIL PROTECTED] wrote:
> > > The main point I was trying to make is that when you get only
> > > *partial* additional data (e.g. only A records but not AAAA), how do
> > > you know that it's *partial*, not the whole truth (i.e., that you
> > > should go asking for AAAA records because you know you want them as
> > > well as the A records you got already).
> >
> > You don't know if there are dropped records however this
> > really isn't a problem. You use what you get then look
> > for missing glue when you exhaust the supplied glue.
>
> Perhaps I should clarify what I was after from the v4/v6 transition
> point of view: this does not seem to be as straightforward in some
> cases.
>
> Consider a case where using IPv4 or IPv6 to reach a destination are
> somehow inequal (e.g., IPv4 will have to go through a protocol
> translator, IPv4 will have to get a dynamically allocated v4 address
> using some mechanism, etc.) -- and the lack of glue might force one to
> use v4 (for example) when it strictly speaking wouldn't be necessary.
>
> When v4 and v6 are completely equal, this doesn't seem to matter as
> much. But in some scenarios at least some folks (I'm not sure whether
> I subscribe to that or not :-) would prefer to avoid using particular
> protocol if there are other options. And that appears to be
> difficult if glue is not sufficiently consistent.
Glue is glue. It doesn't matter whether it is A or AAAA. You
use what you can then request what is missing.
None of the issues hear have changed with the introduction of IPv6.
You have glue being dropped today because sites have excessive
numbers of nameservers. Try asking for a really long name from
the root servers under com or net. You may only have one glue
record.
; <<>> DiG 9.2.3 <<>>
456789.12456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.vix.com
@f.root-servers.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31348
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 1
;; QUESTION SECTION:
;456789.12456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.123456789.vix.com.
IN A
;; AUTHORITY SECTION:
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 172800 IN A 192.5.6.30
;; Query time: 171 msec
;; SERVER: 192.5.5.241#53(f.root-servers.net)
;; WHEN: Fri Dec 19 07:05:52 2003
;; MSG SIZE rcvd: 511
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
> .
> dnsop resources:_____________________________________________________
> web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
> mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
