One small concern I wanted to discuss here. I know few registry/registrars
which do not accept both (or all) name servers of domain name on same
subnet. They demand at least 1 DNS server should be on different subnet for
failover reasons (old thoughts).
How one can deal with such case in case of anycasting setup which using one
single subnet everywhere?
>
> One small concern I wanted to discuss here. I know few
> registry/registrars which do not accept both (or all) name servers of
> domain name on same subnet. They demand at least 1 DNS server should be
> on different subnet for failover reasons (old thoughts).
>
> How one can deal with such case in case of anycasting setup which using
> one single subnet everywhere?
You still want name servers on more than one subnet in case the anycast
setup breaks.
I am building redundancy within that setup. I mean it will be software
based BGP so if hardware if fried up, it will break BGP session and pull
off routes anyway and for cases like DNS server (software) failure, I will
monitor it via simple bash script which can turn bgp daemon down. So once
it is off, routing tables should take it to different node.
Famous last words: "I am building redundancy...." As if "redundancy" stops someone else announcing your prefix and sucking in half the packets on the 'Net meant for you. (Just one of many failure modes against which you cannot possibly defend.)
That said, IMHO, if you want to shoot yourself in the foot, you should be allowed to do so. Your foot, your decision. I'm sure there are registrars out there that do not babysit you. Find one that doesn't tell you how to run your own infrastructure.
>>>
>>> One small concern I wanted to discuss here. I know few
>>> registry/registrars which do not accept both (or all) name servers of
>>> domain name on same subnet. They demand at least 1 DNS server should be
>>> on different subnet for failover reasons (old thoughts).
>>>
>>> How one can deal with such case in case of anycasting setup which using
>>> one single subnet everywhere?
>>
>> You still want name servers on more than one subnet in case the anycast
>> setup breaks.
>>
> I am building redundancy within that setup. I mean it will be software
> based BGP so if hardware if fried up, it will break BGP session and pull
> off routes anyway and for cases like DNS server (software) failure, I
will
> monitor it via simple bash script which can turn bgp daemon down. So once
> it is off, routing tables should take it to different node.
Famous last words: "I am building redundancy...." As if "redundancy"
stops someone else announcing your prefix and sucking in half the packets
on the 'Net meant for you. (Just one of many failure modes against which
you cannot possibly defend.)
Well, you could make me realize those painful points more humble way.
Anyways, really appreciate points you made and yes, I must find some way
out to them. May be I was wrong in posting question here before doing my
homework. I am sorry everyone.
Thanks.
That said, IMHO, if you want to shoot yourself in the foot, you should be
I am building redundancy within that setup. I mean it will be software
based BGP so if hardware if fried up, it will break BGP session and pull
off routes anyway and for cases like DNS server (software) failure, I will
monitor it via simple bash script which can turn bgp daemon down. So once
it is off, routing tables should take it to different node.
i have a tee shirt which says
All Devices Break
Two Devices Will Break at Once
Global BGP Never Converges
[snip]
It dramatically reduces the value, and meets the basic RFC requirement
for geographically distributed DNS servers, although there are still
routing issues that will impact all DNS servers to share a prefix
It is more important that a domain registrar not refuse to register a
domain, or erroneously declare a valid listing invalid.
The purpose of using a registrar is to establish DNS delegation, not
to validate your site's redundancy meets the absolute best possible
practices for fault tolerance.
Ideally certainly should have DNS servers under multiple prefixes --
and it seems a little bit silly to go through all the trouble of
implementing a complicated anycast geo. dist scheme, while ignoring
a simpler failure mode. It's your choice.
It's not appropriately so for a registrar to say anything your choice;
thats your network
not theirs. By the same token the registrar can't tell you not to
alias all 3 IP addresses on
different subnets to the same physical server.
Again, it's ill-advised, but a "mistake" that has nothing to do with
the registrar's network or the registration service.
It is more important that a domain registrar not refuse to register a
domain, or erroneously declare a valid listing invalid.
The purpose of using a registrar is to establish DNS delegation, not
to validate your site's redundancy meets the absolute best possible
practices for fault tolerance.
just for my curiosity, where do you draw the line for technical
compliance? do the servers need to serve the zone? does the served
zone need to have the same NS RRset as the request and hence parent?
do the servers need to be able to answer compliant dns queries? over
tcp too?
your first paragraph quoted above would seem to say that none of this is
needed. the registrar's job is to stick the delegation in the parent
zone and actually functioning name service be damned.
The purpose of using a registrar is to establish DNS delegation, not
to validate your site's redundancy meets the absolute best possible
practices for fault tolerance.
Terminology nit: the purpose of a registrar is to allow folks the freedom to choose the service level/price that meets their needs. I assume you mean 'registry'.
It's not appropriately so for a registrar to say anything your choice; thats your network not theirs.
An alternative viewpoint is that the parent zone is responsible for the child zone, thus the parent registry can impose what they feel are appropriate requirements to ensure the zones within that registry are maintained correctly. If you do not agree with these requirements, there are now over 200 other registries to choose from (and soon to be many, many more).