Hello Alvaro First of all, Thanks a lot for your feedback!. I really appreciate it. On 17/9/04 09:45, "Alvaro Vives" <alvaro.vives@consulintel.es> wrote:
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)
2) Your solution is based on replicating equipment (having two servers), but, could this be avoided using two addresses in the same interface? Or for example installing two network cards to the server, one for each address?
I though about it, but it can lead to interesting problems. (thinking aloud): - 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. - Using source routing is a possible solution, but not al servers OS have source routing and using it is tricky at best. - Other solution is using source NAT in one connection. I.e. All packets received through the non default connection, to be NATed so the server seems them as coming from the NAT machine and so the reply goes to the NAT machine. Its ok if your software works ok with NAT (if you don't use statistics source IP autentication, etc.) perhaps we could add it as a option.
3) It is a common practice to have servers in different ASs , this way being prepared for network looses of conectivity. This could be used as a backup solution, previous the address changes. For example, you have your master DNS server in you network with your future ex-ISP. You also have one or more secondaries in other networks with addresses from other ISP(S). Before changing the addreses of you master DNS server, you can change the configuration in order to make one of the secondaries being the new master. Then, after the changes of addresses, change the whole configuration (NIC, etc.) with the new address. This involves a lot of administrative work, but seems to me as a possible solution. This idea is based in our experience, as we have control over DNS servers in different ASs. Looks like your section 9.1, but with no help of third-party DNS server(s).
-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. Thanks a lot y Saludos. Fernando
Best regards, Alvaro Vives Consulintel
********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
-- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia@eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- --
On Fri, 2004-09-17 at 11:06, Fernando Garcia wrote:
Hello Alvaro
First of all, Thanks a lot for your feedback!. I really appreciate it.
On 17/9/04 09:45, "Alvaro Vives" <alvaro.vives@consulintel.es> wrote:
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
When documenting things or making examples please use the 192.0.2.0/24 and 2001:db8::/32 prefixes and not made up or real addresses... Greets, Jeroen
Hi Jeroen, Yes, my fault... Thanks. BR, Alvaro Vives Consulintel ----- Original Message ----- From: "Jeroen Massar" <jeroen@unfix.org> To: "Fernando Garcia" <fgarcia@eurocomercial.es> Cc: <dns-wg@ripe.net> Sent: Friday, September 17, 2004 11:12 AM Subject: Re: RV: [dns-wg] DNS migration draft ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
At 11:06 AM +0200 2004-09-17, Fernando Garcia quoted "Alvaro Vives" <alvaro.vives@consulintel.es>:
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@stop.mail-abuse.org> "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.
Hello Brad On 17/9/04 15:57, "Brad Knowles" <brad@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@eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- --
At 12:41 AM +0200 2004-09-18, Fernando Garcia wrote:
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.
Fair enough.
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.
The issue is that there's not really anything we can do to fix this problem. If their administrators are not minimally competent, there is nothing that you can do with any written document that can help, and indeed you are likely to make a bad situation worse by overwhelming them with procedures and policies that they are unlikely to understand. I think the principle needs to be kept as simple as possible, and the resulting document should be kept as short as possible.
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?
Changes should be kept to a minimum, yes. However, I don't think we can assume that the Registrar will automatically screw up everything, every time. Simple sets of changes should be no problem, even if they need to be done more than once. If we assumed that the Registrar would screw up everything, every time, then the entire DNS would collapse. -- Brad Knowles, <brad@stop.mail-abuse.org> "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.
Hi everybody On 18/9/04 01:16, "Brad Knowles" <brad@stop.mail-abuse.org> wrote:
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.
The issue is that there's not really anything we can do to fix this problem. If their administrators are not minimally competent, there is nothing that you can do with any written document that can help, and indeed you are likely to make a bad situation worse by overwhelming them with procedures and policies that they are unlikely to understand.
I think the principle needs to be kept as simple as possible, and the resulting document should be kept as short as possible.
Good point. Jim said the same, so we probably should cut or split the document. I think this is something that must be speak in the wg on Thursday. BTW, mi personal opinion is that "source routing" doesnt fit in the "simple" category. I know a lot more people that feel comfortable with DNS but doesnt know source routing (but this is my personal opinion).
Changes should be kept to a minimum, yes. However, I don't think we can assume that the Registrar will automatically screw up everything, every time. Simple sets of changes should be no problem, even if they need to be done more than once.
Not necesarily screw up, but sometimes delay. The spanish NIC used to have a waiting queue of one week. 1 change= 1 week delay, 2 changes=2 weeks delay. (I think they have improve now, but I can guarantee the same for all the NIC under the RIPE umbrella). Regards, Fernando -- ---------------------------------------------------------------------------- -- Fernando Garcia - fgarcia@eurocomercial.es Eurocomercial Informática y Comunicaciones 91 435 96 87 ---------------------------------------------------------------------------- --
participants (4)
-
Alvaro Vives -
Brad Knowles -
Fernando Garcia -
Jeroen Massar