I'm , but I met some questions when reading those
paper from ISC on F-root anycasting.
1. As it's descripted in J.Abley's paper, DNS server
in anycast group should be configured with a real IP
on its NIC and one or two service IP on loopback
interface(s). BIND listen on both real IP and service
IPs. Any DNS answer packet will be encapsulated with
source address as service IP. To my understanding,
this is OK for root servers because they do not invoke
recursive lookup procedure. But, if the DNS server is
a member of ISP's DNS Cache server farm, recursive
lookup packets to other DNS server MUST be
encapsulated with real IP address.
Is BIND or other DNS software capable of
distinguishing between DNS answer back packet and
recursive lookup packets? or could this be done
automatically by operating system like Solaris, Linux,
FreeBSD?
2. If we want to design a hierachical DNS service
system which distribute across multiple private AS of
an ISP, is there any problem to select service IP
randomly from unused address pool?
If anybody else has questions or comments about those papers, they should feel free to send me private mail about them (since this evidently wasn't universally obvious).
Date: Mon, 11 Oct 2004 17:23:19 +0800 (CST)
From: Joe Shen
1. As it's descripted in J.Abley's paper, DNS server
in anycast group should be configured with a real IP
on its NIC and one or two service IP on loopback
Service IP addresses also are "real IP" addresses.
interface(s). BIND listen on both real IP and service
IPs. Any DNS answer packet will be encapsulated with
source address as service IP. To my understanding,
s/encapsulated with/sourced from/
this is OK for root servers because they do not invoke
recursive lookup procedure. But, if the DNS server is
a member of ISP's DNS Cache server farm, recursive
lookup packets to other DNS server MUST be
encapsulated with real IP address.
s/encapsulated with real/sourced from unicast/
Is BIND or other DNS software capable of
distinguishing between DNS answer back packet and
recursive lookup packets? or could this be done
automatically by operating system like Solaris, Linux,
FreeBSD?
Not sure what you're asking, but it's probably OT. If I
understand you correctly, RFC 1034 or 1035 would be the place you
should start; it sounds like you're asking a protocol question.
2. If we want to design a hierachical DNS service
system which distribute across multiple private AS of
an ISP, is there any problem to select service IP
randomly from unused address pool?
Standard routing rules apply. Think of anycast as multihoming
with a disjoint backend.
I'm , but I met some questions when reading those
paper from ISC on F-root anycasting.
1. As it's descripted in J.Abley's paper, DNS server
in anycast group should be configured with a real IP
on its NIC and one or two service IP on loopback
interface(s). BIND listen on both real IP and service
IPs. Any DNS answer packet will be encapsulated with
source address as service IP. To my understanding,
this is OK for root servers because they do not invoke
recursive lookup procedure. But, if the DNS server is
a member of ISP's DNS Cache server farm, recursive
lookup packets to other DNS server MUST be
encapsulated with real IP address.
Is BIND or other DNS software capable of
distinguishing between DNS answer back packet and
recursive lookup packets? or could this be done
automatically by operating system like Solaris, Linux,
FreeBSD?
2. If we want to design a hierachical DNS service
system which distribute across multiple private AS of
an ISP, is there any problem to select service IP
randomly from unused address pool?
This is not a rocket science. Pick a /29 or /30, inject it at multiple places
with capable dns farms into your IGP, or into your IBGP with similar attribs.
Make sure unicast addresses are also supplied to name servers so that they
can source their recursive lookups from unicast, not anycast.
The difference between anycast and unicast in IPv4 is that anycast is simply
a block of what would be unicast addrs, available via multiple end points using
a routing protocol.