Hello,
has someone experience in anycast ipv4 networks (to support DNS)?
Regards
Lutz
InterNetX - Lutz Muehlig wrote:
Hello,
has someone experience in anycast ipv4 networks (to support DNS)?
"Never been done" "Dangerous" "TCP does not work" etc etc etc.
I assume quite a number of people know how to do it, especially as
several root DNS servers abuse it.
Simple recipe:
- Box with:
- Your favourite OS
- Quagga or OpenBGPd
- Your favourite DNS server
- Announce the IP of the anycast node in BGP
- Monitor the DNS server, when it does not work kill your local BGPd
and notify the admins that it broke
That is it. Probably with the above couple of things, google a bit and
find the rest.
Greets,
Jeroen
> has someone experience in anycast ipv4 networks (to support DNS)?
"Never been done" "Dangerous" "TCP does not work" etc etc etc.
- Yes but as for DNS, anycast is essentially used for user requests (UDP)
not to perform zone transfer(TCP).
-M
InterNetX - Lutz Muehlig wrote:
Hello,
has someone experience in anycast ipv4 networks (to support DNS)?
"Never been done" "Dangerous" "TCP does not work" etc etc etc.
Can't really tell if you're being serious here due to caffeine underrun.
Slide 23 seems quite appropriate.
has links to other work on this.
It certainly seems to work "well enough".
> > has someone experience in anycast ipv4 networks (to support DNS)?
>
> "Never been done" "Dangerous" "TCP does not work" etc etc etc.- Yes but as for DNS, anycast is essentially used for user requests (UDP)
not to perform zone transfer(TCP).
How-to with working configurations for Linux+Quagga:
<www.linuxsa.org.au/meetings/2006-07/anycast-dns.odt>
Further information is found in RFC3258:
<http://tools.ietf.org/html/rfc3258>
Remember to disable PMTU discovery on your DNS servers if you are using this.
Paul
DNS uses TCP for more than just XFR. For instance, if you're running a
resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC
signed reply, it's going to be over 512 bytes and the lack of EDNS0 will
cause it to re-ask via TCP.
Just mentioning it because the sort of sites that think TCP==XFR are the
sort most likely to be running firewalls that munch the EDNS0 bits, and
are setting themselves up for big surprises in the very near future.
Max Larson Henry wrote:
> has someone experience in anycast ipv4 networks (to support DNS)?
"Never been done" "Dangerous" "TCP does not work" etc etc etc.
- Yes but as for DNS, anycast is essentially used for user requests
(UDP) not to perform zone transfer(TCP).
Also that would work, unless you have a very unstable routing table that
makes the node swap all the time.
Please also note that if a DNS answer does not fit inside a a UDP packet
(default 512, MTU with EDNS0) that the fallback is TCP mode...
John Payne wrote:
[..]
Can't really tell if you're being serious here due to caffeine
underrun.
As it is already almost 15:00 in Europe (and it is a friday), take a
guess 
Also note the next line I wrote and the point to the google,
which you now have done for the person, who probably is also having a
lazy friday afternoon
Greets,
Jeroen
* Jeroen Massar:
Simple recipe:
- Box with:
- Your favourite OS
- Quagga or OpenBGPd
- Your favourite DNS server
- Announce the IP of the anycast node in BGP
- Monitor the DNS server, when it does not work kill your local BGPd
and notify the admins that it broke
This is fine if you just use BGP to indirectly hook into your IGP.
For global anycast, you need a sufficiently short prefix with no
non-anycast services on it. This can be difficult to justify for
newcomers.
--==_Exmh_1269611568_4209P
Content-Type: text/plain; charset=us-ascii> - Yes but as for DNS, anycast is essentially used for user requests (UDP)
> not to perform zone transfer(TCP).DNS uses TCP for more than just XFR. For instance, if you're running a
resolver that doesn't do EDNS0, and you hit an (increasingly common) DNSSEC
signed reply, it's going to be over 512 bytes and the lack of EDNS0 will
cause it to re-ask via TCP.
DNSSEC depends on EDNS and DO being set in the EDNS OPT record, so
won't get DNSSEC records, except in response to * queries, for non
EDNS queries.
Just mentioning it because the sort of sites that think TCP==XFR are the
sort most likely to be running firewalls that munch the EDNS0 bits, and
are setting themselves up for big surprises in the very near future.
Mark
This is a general reference that tries hard not to be DNS-specific:
http://www.ietf.org/rfc/rfc4786.txt
These are two papers written whilst at ISC describing many aspects of how ISC did what you are talking about with the F root nameserver:
http://ftp.isc.org/isc/pubs/tn/isc-tn-2003-1.txt
http://ftp.isc.org/isc/pubs/tn/isc-tn-2004-1.txt
This is a rendering of the OSPF/IGP anycast tech note above as a USENIX paper:
http://www.usenix.org/events/usenix04/tech/sigs/full_papers/abley/abley.pdf
This is a more sarcastic article about anycast that was published in the USENIX publication ;login:
http://www.usenix.org/publications/login/2008-02/openpdfs/abley.pdf
This is a presentation about building nameserver clusters that was presented at NANOG 34:
http://nanog.org/meetings/nanog34/presentations/abley.nameservers.pdf
Joe
The number of DNS queries for user requests that are in UDP in IPv4
is nearly all. When you start seeing hosts with more than a couple
of AAAA records, you will start seeing more user requests in TCP.
FWIW, World of Warcraft authentication actually involves some hosts
with enough A records to require TCP.
Owen
It doesn't require an unstable routing table. There is a small set of
locations that could hit routers with multipath that may "balance"
the anycast packets down divergent paths.
Essentially, these are the topological midpoints between any two
(or more) anycast servers.
Owen
As others have mentioned, TCP can generally be used for any DNS query, not just AXFR.
This becomes more important as DNS responses get bigger, e.g. responses from root servers due to the root zone containing DNSSEC information, see <http://www.root-dnssec.org/>.
If your nameserver can't be reached over TCP, it's likely that there are people who can't talk to your nameserver. This means your DNS records can't be found. This is a bad thing.
Here, in glorious LOLCAPS:
ALWAYS MAKE SURE YOUR DNS SERVER CAN BE REACHED OVER TCP
TCP IS NOT JUST FOR ZONE TRANSFERS
FIX YOUR FIREWALLS
Joe
As with most things, there are risks and benefits to distributing services using anycast. There are also risks and benefits from not doing so.
Far too many words to bother people with here on this list, but the ;login: article I include a link to earlier (<http://www.usenix.org/publications/login/2008-02/openpdfs/abley.pdf>) attempts to discuss ways in which people can decide whether anycast suits their own particular circumstances ("Horses for Courses").
Joe
I was involved in building an anycast setup where we had two anycast
DNS /32 addresses. Each of them was the backup for the other i.e. each
DNS server was announcing both /32s via BGP, with opposite weights. If
one failed, the other DNS server then took over the failed DNS
cache's queries, and as it was also already an operational DNS
server for one of the anycast addresses, it's DNS cache was already hot.
For load balancing, we alternated the order of announcing the DNS
server addresses in e.g. PPP IPCP, DHCP. That worked somewhat
surprisingly well - the peak query per second values on each of them
were no more than about 10% different.
One trap we got caught by was stateful firewalling on the host. We knew
to up the number of stateful connections, however on that particular
Linux distro there were two places it was set - /etc/sysctl.conf and in
the iptables configuration. We only knew about the first, so when the
firewall rules were updated the number of supported stateful
connections was dropped down to too low a level. It wasn't funny to
have one DNS server stop answering queries, and have it's own
monitoring script fail itself, switch all the traffic to the other one
and then have that die too for the same reason. Lots of gnashing of
teeth until we worked out .
The final and better solution was to stop doing stateful firewalling on
DNS queries, using the iptables 'raw' table.
Regards,
Mark.