This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
RV: [dns-wg] DNS migration draft
- Previous message (by thread): RV: [dns-wg] DNS migration draft
- Next message (by thread): RV: [dns-wg] DNS migration draft
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Fernando Garcia
fgarcia at eurocomercial.es
Sat Sep 18 00:41:50 CEST 2004
Hello Brad On 17/9/04 15:57, "Brad Knowles" <brad at stop.mail-abuse.org> wrote: > 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 Good point. I take note. > 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. I was not only thinking about DNS but all the other servers that must be migrated AND this document should not be BIND centered (though the examples use bind). I'm not sure about how the DNS server for Windows work, but let me be a little suspicious. The problem in your phrase is "network administrator ensures.. Outgoing packets are routed via the appropiate provider", this usually means "source routing" (I can paint many scenarios with this meaning), a not so simple task and the person -network administrator- that will use this document (I hope) is not a very qualified technician, if she/he is qualified, she/he wouldn't need this document. > > 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. Its a problem, so the less changes, the better. Do you agree with this statement? Regards, Fernando -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia at eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- --
- Previous message (by thread): RV: [dns-wg] DNS migration draft
- Next message (by thread): RV: [dns-wg] DNS migration draft
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]