Re: Repotting report
> > --Apple-Mail-32-671463028 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; > charset=US-ASCII; > delsp=yes; > format=flowed > > > On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote: > > > IPv6 capable nameservers are supposed to use EDNS (see IPv6 > > node requirements). The roots can be tuned to preference > > A vs records. Most/all currently maintained caching > > servers support EDNS now or the next release will support > > EDNS. > > So would there be benefit in the roots being tuned to only return > if the request is EDNS? No. > Just out of curiousity that is. > --Apple-Mail-32-671463028 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; > charset=ISO-8859-1 > > -webkit-line-break: after-white-space; "> > On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote: class=3D"Apple-interchange-newline"> style=3D"margin: 0.0px 0.0px 0.0px 0.0px"> size=3D"3" style=3D"font: 12.0px Helvetica"> style=3D"white-space:pre"> IPv6 capable nameservers are = > supposed to use EDNS (see IPv6 0.0px 0.0px 0.0px"> 12.0px Helvetica"> style=3D"white-space:pre">node requirements). class=3D"Apple-converted-space">=A0 The roots can be tuned to = > preference face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"> class=3D"Apple-tab-span" style=3D"white-space:pre"> A vs = > records.=A0 Most/all = > currently maintained caching 0.0px 0.0px"> Helvetica"> = > servers support EDNS now or the next release will = > support face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica"> class=3D"Apple-tab-span" style=3D"white-space:pre"> = > EDNS. So would there be = > benefit in the roots being tuned to only return if the request is = > EDNS?Just = > out of curiousity that is.= > > --Apple-Mail-32-671463028-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: Repotting report
On Feb 6, 2008, at 12:48 AM, Mark Andrews wrote: IPv6 capable nameservers are supposed to use EDNS (see IPv6 node requirements). The roots can be tuned to preference A vs records. Most/all currently maintained caching servers support EDNS now or the next release will support EDNS. So would there be benefit in the roots being tuned to only return if the request is EDNS? Just out of curiousity that is.
Re: Repotting report
> On Feb 6, 2008 12:11 AM, Mark Andrews <[EMAIL PROTECTED]> wrote: > >> (from me) > > >How does a cache-resolver know that it's time to issue a query with edns0? > > > > cache-resolver that support EDNS0 will make EDNS0 queries > > by default. They will fallback to plain DNS if the query > > fails or they get a response that indicated the authoritative > > server doesn't support EDNS. > > > > BIND's been making EDNS0 queries for ~8 years now. If your > > cache-resolver doesn't support EDNS it is long past time to > > upgrade. > > > > excellent, thanks! (as always). Any thoughts on the possible lack of > resilence from losing 9 server names/ips in the v4 to v6 move? (and I > realize that later most/all root boxes will have both addresses) It won't be a issue. IPv6 capable nameservers are supposed to use EDNS (see IPv6 node requirements). The roots can be tuned to preference A vs records. Most/all currently maintained caching servers support EDNS now or the next release will support EDNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: Repotting report
On Feb 6, 2008 12:11 AM, Mark Andrews <[EMAIL PROTECTED]> wrote: >> (from me) > >How does a cache-resolver know that it's time to issue a query with edns0? > > cache-resolver that support EDNS0 will make EDNS0 queries > by default. They will fallback to plain DNS if the query > fails or they get a response that indicated the authoritative > server doesn't support EDNS. > > BIND's been making EDNS0 queries for ~8 years now. If your > cache-resolver doesn't support EDNS it is long past time to > upgrade. > excellent, thanks! (as always). Any thoughts on the possible lack of resilence from losing 9 server names/ips in the v4 to v6 move? (and I realize that later most/all root boxes will have both addresses)
Re: Repotting report
In article <[EMAIL PROTECTED]> you write: > >On Feb 5, 2008 2:10 AM, Pekka Savola <[EMAIL PROTECTED]> wrote: >> >> On Mon, 4 Feb 2008, Leo Bicknell wrote: >> > may try "dig any . @[a-m].root-servers.net." >> > >> > When I do that, I get the following response: >> > >> > a, c, d e, f, g, i and j return 1 SOA, 8 A, and 3 's (the first 3). >> > b, h, l, k, and m return 1 SOA, 13 A, no records. >> > >> > If you make this mistake you might think b, h, l, k and m have no >> > IPv6 data, which is wrong. Querying with NS (as nameserver would >> > do) clearly shows that. >> > >> > While a cosmetic problem, I fear it may confuse a number of admins >> > as the troubleshoot problems in the near future. >> >> It certainly will. Section 1.4 of RFC 4472 may be helpful here, >> though it mainly talks about this from the viewpoint of caching, not >> root servers. > >So, how will this sort of thing affect traffic levels to the servers >in question? Will this affect stability on a v6only or v4-limited >site/network? (13 v4 servers, 4 v6 servers...) > >How does a cache-resolver know that it's time to issue a query with edns0? cache-resolver that support EDNS0 will make EDNS0 queries by default. They will fallback to plain DNS if the query fails or they get a response that indicated the authoritative server doesn't support EDNS. BIND's been making EDNS0 queries for ~8 years now. If your cache-resolver doesn't support EDNS it is long past time to upgrade. Mark >Having inconsistent information seems like it might cause more than >just troubleshooting headaches... > >-Chris
Re: Repotting report
In article <[EMAIL PROTECTED]> you write: > > >On 4-Feb-2008, at 16:05, Iljitsch van Beijnum wrote: > >> And the new named.root has arrived: >> >> ftp://rs.internic.net/domain/named.root > >I seem to think it has become fairly widespread practice for people to >refresh their named.root files (or whatever they decide to call it) >using something like this: > >$ dig . NS >named.root > >This worked before today. From today, it still works (in the sense >that it will still result in a named.root file which is sufficiently >complete in most situations for a nameserver to be able to send a >priming query) but it won't contain a complete set of glue. > >So, if you're in the habit of doing > > dig . NS >named.root > >you would ideally change that habit to something like > > curl -O ftp://rs.internic.net/domain/named.root Why? dig is quite capable of coping. Depending apon dig's age and firewall configuration one or more of these will work. dig +edns=0 . NS @a.root-servers.net > named.root dig +bufsize=1200 . NS @a.root-servers.net > named.root dig +vc . NS @a.root-servers.net > named.root As none of these sets DO, they should suffice for the foreseeable future. When DNSSEC is deployed for the root and root-servers.net you will want to do crypto checks. Even then the above queries won't break. Mark >instead. (Incidentally, for me, rs.internic.net is giving "530 Login >incorrect" after PASS when logging in using "ftp" > > >Joe
