About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: RV: [dns-wg] DNS migration draft

  • To: Fernando Garcia < >
  • From: Brad Knowles < >
  • Date: Fri, 17 Sep 2004 15:57:23 +0200
  • Cc: "dns-wg@localhost" < >

At 11:06 AM +0200 2004-09-17, Fernando Garcia quoted "Alvaro Vives" <alvaro.vives@localhost:

 1) In case of having IPv4 and IPv6 addresses for the DNS server
 of example.org domain, changing addresses in different moments could
 lead to reduce the blackout, at least for the dualstack user
 resolvers. For example:

  example.org.  NS  A    10.1.2.3
                NS  AAAA 2001:800:40:2a2f::1
 IPv6 is one of the main items of my "to do" list for the meeting (not being
 a big expert in IPv6). I will include your proposal in the presentation to
 be discused/agreed (it seems fine to me)
Sorry, this just hit me.

Unfortunately, we don't use IP addresses in NS records. We use domainnames. Try this instead:

example.org. NS ns1.example.org.
ns1.example.org. A 10.1.2.3
AAAA 2001:800:40:2a2f::1


 - The same equipment with to IP address/interfaces. Everything will follow
 the default route regardless of the source IP routing and A) packets wont
 follow best route B) could be filtered by anti spoofing filters.
Well, if the routes are via different providers, and the network administrator ensures that the incoming and outgoing packets are routed via the appropriate provider, I don't see what the problem is. You can always have sub-optimal routing, that's just something you have to live with. Otherwise, BIND is good at knowing which interface a given query came in on, and making sure that the reply goes back out on the same interface. So, there shouldn't be any filtering problems, at least not any more than you could potentially run into anyway.

And I don't see any reason to use any of the other methods, regardless.


The only issue I see here is that the delegation data won't match the in-zone data for these hostnames, unless you make changes at your registrar. Of course, some registrars may limit the number of known IP addresses for a given host/domain name, so you may have to decide how you want to deal with that problem.

 -PROs: avoid installing a temporary machine
 -CONs: Two changes in the NIC in place of one.
 I prefer one change in the NIC (I am really, really afraid of some NICs
 working methods) and use your solution if no duplicate server is possible.
 We can discuss it, of course.
I think you have the problem of multiple changes at the registrar no matter what.

--
Brad Knowles, brad@localhost

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

-- Benjamin Franklin (1706-1790), reply of the Pennsylvania
Assembly to the Governor, November 11, 1755

SAGE member since 1995. See <http://www.sage.org/> for more info.




  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community