Re: NS failover as opposed to A record failover

[Scott A. Wozny]

Thank you for the feedback, Tony.  I think a better understanding of what's 
going on under the hood will prove useful in both designing my operational 
management strategy as well as just talking me down off the ledge.  :)  Much 
obliged.  :)


Scott



From: Tony Finch 
Sent: February 26, 2020 10:05 AM
To: Scott A. Wozny 
Cc: bind-users@lists.isc.org 
Subject: Re: NS failover as opposed to A record failover

Scott A. Wozny  wrote:
>
> Failures aside, I’m worried about creating a bad user experience EVERY
> time I need to take a DNS server down for patching.

I generally let resolvers handle retry/failover when I'm patching my
authoritative servers. Each resolver that encounters an authoritative
server that is down will retry on another server within a few seconds, and
should send follow-up queries to more responsive auth servers. There are
several retries within the libc resolver timeout, so there are multiple
opportunities to automatically deal with an outage within a reasonable
amount of time. So the badness isn't that terrible. (i.e. less than the
load time for a web page with megabytes of JavaScript.)

I reckon this should be good enough for you, because it's a similar amount
of badness that your users will encounter from your DNS UPDATE web server
failover setup.

If you want something better, on my recursive servers I use keepalived to
move the service IP addresses off servers while they are being patched.
You can do something similar for auth servers, if you have a little
cluster in each location. On your web servers, keepalived and HAproxy is
supposed to be a good combination (though I have not tried it myself).
For servers that are too far apart for layer 2 failover to work, you'll
need to get funky with anycast.

Tony.
--
f.anthony.n.finchhttp://dotat.at/
Tony Finch's homepage
dotat.at
Tony Finch's homepage. my work web page (including stuff about email, 
especially in Cambridge University) my blog (in which I mostly write about 
things I'm working on) my Twitter account (to which I feed my link log and a 
steady diet of retweets) my link log (wildly weird and wonderful) My git 
repositories on chiark and on github; My git server at work.

German Bight: Northwest backing southwest later 4 to 6. Slight or moderate.
Showers. Good, occasionally moderate.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NS failover as opposed to A record failover

[Scott A. Wozny]

Thanks for the feedback, Bob.  This is encouraging news.  I think now I need to 
do some testing to see what works best for my application.


Scott



From: Bob Harold 
Sent: February 26, 2020 9:02 AM
To: Mark Andrews 
Cc: Scott A. Wozny ; bind-users@lists.isc.org 

Subject: Re: NS failover as opposed to A record failover


On Tue, Feb 25, 2020 at 6:38 PM Mark Andrews 
mailto:ma...@isc.org>> wrote:

> On 26 Feb 2020, at 09:51, Scott A. Wozny 
> mailto:sawo...@hotmail.com>> wrote:
>
> I know this isn’t a question ABOUT BIND, per se, but I think is still a 
> question bind-users might have an answer to. I’ve seen various failover 
> questions on the list, but nothing that talks specifically about NS records 
> (at least nothing in the last decade), so I thought I’d inquire here.
>
> I’m familiar with round-robin DNS and using multiple A records for the same 
> name. I also understand that most clients, if the top server on the list 
> doesn’t respond, will wait ~30 seconds before trying the next address on the 
> list. This is pretty good, as far as automatic failover goes, but still, 
> having X% of your users (X being down servers / all A records offered) wait 
> an extra 30 seconds is not great so I’m going to run a regular health check 
> on my front facing web servers from each BIND server and, if a server stops 
> responding, change my zone file and reload until the server starts responding 
> again, reversing the process. Then X% of my users will only need to wait 30 
> seconds until I fix the zone file (TTL will also be about the same frequency 
> as the health checks so worst case scenario will be 2xTTL for X% of users 
> having to wait those extra 30 seconds). Overall I’m satisfied with this 
> balance between complexity and resiliency, particularly considering I can do 
> record manipulation in advance of planned maintenance and then this problem 
> only becomes an issue during unexpected outages.

There is nothing that requires clients to wait a full thirty seconds before 
moving onto the next address.  In fact Happy Eyeballs (RFC 83050) uses 
sub-second delays before attempting connections to other addresses.  Yes, you
can have multiple connection attempts to different servers in flight at the 
same time and just take the one that
connects first while dropping the others.  The standard socket API supports 
this sort of behaviour but most applications doesn’t use it that way.

https://users.isc.org/~marka/ has code samples, that pre-dates Happy Eyeballs, 
that attempts to connect to multiple addresses at once with small delays.  Once 
a connection is established the other attempts are aborted.

There are examples using select(), poll() and multiple threads.

> This is all well and good until I think about failure or maintenance of the 
> name servers, themselves. I’ll need to give my registrar my NS IPs for my 
> domain but they will not be nearly as flexible regarding changes as I am 
> running my own nameservers (TTL will probably be an hour, at the very least) 
> which makes maintenance work a MUCH longer process for set-up and tear-down, 
> if I have to make NS record changes in coordination with my registrar. 
> However, this made me wonder, is NS failure responded to in the same way as 
> the failure of an A record? Various Internet randos have indicated some DNS 
> clients and resolvers will do parallel lookups and take the first response 
> and others have indicated that the “try the next record” parameter for NS 
> comms is 5 to 10 seconds rather than 30 and still others claim it’s the same 
> as A record failover at 30 seconds before trying the next candidate on the 
> list. Is there a definitive answer to this or, because it’s client related, 
> are the answers too widely varied to rely upon (which is why the answers on 
> the Internet are all over the map)?

Well you have the stub resolver and the recursive server to talk about.

Stub resolvers generally use low second timeouts before moving on to the next 
address but some just shotgun every recursive server.

Recursive servers can do the same thing.

The 30 seconds comes from the TCP connect timeout.  Where the TCP/IP stack 
makes multiple connection attempts over that 30 seconds before giving up.

DNS, initially, is UDP and the client manages retransmission attempts.  Named 
uses sub second initial timeouts.  Most of the world is less that 200ms RTT 
from any other point though there are exceptions.

Mark

> Failures aside, I’m worried about creating a bad user experience EVERY time I 
> need to take a DNS server down for patching. I can’t be the first person to 
> run into this problem. Is it just something people live with (and shuffle NS 
> records around all the time) or is NS failover really smoother than A record 
> failover and I should concentrate on keeping my A records current in case of 
> failure OR planned maintenance?
>
> Any feedback would be greatly appreciated.
>
> Thanks,
>
> Scott

Re: NS failover as opposed to A record failover

[Scott A. Wozny]

Thanks very much for the feedback.  I clearly have more research to do.  :)


Scott



From: Mark Andrews 
Sent: February 25, 2020 6:38 PM
To: Scott A. Wozny 
Cc: bind-users@lists.isc.org 
Subject: Re: NS failover as opposed to A record failover


> On 26 Feb 2020, at 09:51, Scott A. Wozny  wrote:
>
> I know this isn’t a question ABOUT BIND, per se, but I think is still a 
> question bind-users might have an answer to. I’ve seen various failover 
> questions on the list, but nothing that talks specifically about NS records 
> (at least nothing in the last decade), so I thought I’d inquire here.
>
> I’m familiar with round-robin DNS and using multiple A records for the same 
> name. I also understand that most clients, if the top server on the list 
> doesn’t respond, will wait ~30 seconds before trying the next address on the 
> list. This is pretty good, as far as automatic failover goes, but still, 
> having X% of your users (X being down servers / all A records offered) wait 
> an extra 30 seconds is not great so I’m going to run a regular health check 
> on my front facing web servers from each BIND server and, if a server stops 
> responding, change my zone file and reload until the server starts responding 
> again, reversing the process. Then X% of my users will only need to wait 30 
> seconds until I fix the zone file (TTL will also be about the same frequency 
> as the health checks so worst case scenario will be 2xTTL for X% of users 
> having to wait those extra 30 seconds). Overall I’m satisfied with this 
> balance between complexity and resiliency, particularly considering I can do 
> record manipulation in advance of planned maintenance and then this problem 
> only becomes an issue during unexpected outages.

There is nothing that requires clients to wait a full thirty seconds before 
moving onto the next address.  In fact Happy Eyeballs (RFC 83050) uses 
sub-second delays before attempting connections to other addresses.  Yes, you
can have multiple connection attempts to different servers in flight at the 
same time and just take the one that
connects first while dropping the others.  The standard socket API supports 
this sort of behaviour but most applications doesn’t use it that way.

https://users.isc.org/~marka/ has code samples, that pre-dates Happy Eyeballs, 
that attempts to connect to multiple addresses at once with small delays.  Once 
a connection is established the other attempts are aborted.

There are examples using select(), poll() and multiple threads.

> This is all well and good until I think about failure or maintenance of the 
> name servers, themselves. I’ll need to give my registrar my NS IPs for my 
> domain but they will not be nearly as flexible regarding changes as I am 
> running my own nameservers (TTL will probably be an hour, at the very least) 
> which makes maintenance work a MUCH longer process for set-up and tear-down, 
> if I have to make NS record changes in coordination with my registrar. 
> However, this made me wonder, is NS failure responded to in the same way as 
> the failure of an A record? Various Internet randos have indicated some DNS 
> clients and resolvers will do parallel lookups and take the first response 
> and others have indicated that the “try the next record” parameter for NS 
> comms is 5 to 10 seconds rather than 30 and still others claim it’s the same 
> as A record failover at 30 seconds before trying the next candidate on the 
> list. Is there a definitive answer to this or, because it’s client related, 
> are the answers too widely varied to rely upon (which is why the answers on 
> the Internet are all over the map)?

Well you have the stub resolver and the recursive server to talk about.

Stub resolvers generally use low second timeouts before moving on to the next 
address but some just shotgun every recursive server.

Recursive servers can do the same thing.

The 30 seconds comes from the TCP connect timeout.  Where the TCP/IP stack 
makes multiple connection attempts over that 30 seconds before giving up.

DNS, initially, is UDP and the client manages retransmission attempts.  Named 
uses sub second initial timeouts.  Most of the world is less that 200ms RTT 
from any other point though there are exceptions.

Mark

> Failures aside, I’m worried about creating a bad user experience EVERY time I 
> need to take a DNS server down for patching. I can’t be the first person to 
> run into this problem. Is it just something people live with (and shuffle NS 
> records around all the time) or is NS failover really smoother than A record 
> failover and I should concentrate on keeping my A records current in case of 
> failure OR planned maintenance?
>
> Any feedback would be greatly appreciated.
>
> Thanks,
>
> Scott
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> 

Re: bind as "reverse-proxy"

[Erich Eckner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 26 Feb 2020, Matus UHLAR - fantomas wrote:


On 26.02.20 15:28, Erich Eckner wrote:

is it possible to set up a zone in bind similar to a http(s) reverse proxy:


No. DNS is very far from proxying.

1. The server appears authoritative to clients (the consulted server is 
indeed authoritative).


2. Each request is passed on to the other server (or served from cache), 
but the information is *not* obtained by zone transfers (because the other 
server does not have/allow this).


For records that are managed locally, BIND is authoritative.
For records that are stored elsewhere, BIND is NOT authoritative.

So, either you have authoritative server, or you have not.

What is the point of your request?


The point is, that I have two authoritative dns servers running on the
same machine which I would like to "merge". The problem there is, that one
of them runs some special software, which does not "speak too much dns"
(it is not broken as far as I can tell, but it is also not that versatily
configurable as bind is).

A is a normal bind installation and B is the "custom made" dns server.
Unfortunately, B does not allow zone transfers and (though it allows
forwarding queries for "foreign" domains to a separate name server (A) in
principle) it does not forward AXFR/IXFR which breaks slave duplication of
A's master zone. So I cannot place B in front (which I would like to avoid
anyways, as bind is waaayyy more mature than B). So my question was,
whether I could place A in front of B - which currently works, besides
that my server now looks non-authoritative to clients.

But maybe my whole train of thought is backwards: The problem, I'm
currently experiencing, is, that the nameserver setup for B's subdomain
(i.eckner.net) looks all-right when querying A (or the nameserver of the
parent domain) directly, but not, if I traverse from the root zone.

Maybe I missed to set up some cross-reference and A not appearing
authoritative is not a problem for the name resolution?

@Tony: dnsdist looks interesting. At first glance, it looks, like it can 
do what I need: send queries to different servers depending on the queried 
domain. I'll take a closer look at it.


regards,
Erich


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl5WpTEACgkQCu7JB1Xa
e1qOSxAAqoAQeCkPrqXGVlgvcQA7WfFVfmQTaVLk8p7qVz5JwoK+UCZzUINIDlhP
Og/Ca13lPG9+G2RamLDk9OKSZW+UBIb/AipHTndGz8EHjHOWbmHYP90aeJZ4nJzZ
c4gweD9/kCOXTrWkzTkpGChxPSb+CiiiVW2TW4DKwGTniEMJ0yhX+35vobaP17eI
1A4Sg/asZsNS287K3WUxGR/R69u6SQTtcL07zgtYx0n45bCd80OCedwhdKTvSTBr
PmpRxPdY4ePy6/6dtq1aGI9eb7OrAAhHw5ign3SWj12xDLJUZQDxewpdK3gqdGFc
5Cv78xHTJ1SiZSYAugGWbRSuEdTFVCCKAIqk/310Y3HeBBKd8JCc2l9jcC0VhHDe
GsRv8XMC4oEVt3aFIe3HFACnkBAc8sp7+CLXHzsbPa+fZIQPse9hiEjXpTz3iaVu
GmJb0dMQ3zO3oI+ziC2qc3zEpmhTD10EiF7FTbWkt3yxt9Q7/rlOff3banokKRpo
/qmO34agDTf9Ao3q9LdtDkPff5jiqdKNcYDXneQnXuyHH9MEKbIm+F418R/MUFK3
z+OSuXPOhNeKfxOKwFIpzic3KM13Odaxsep4c7KNQBeKp2566iAVbPszVkpumZd5
HX89VK//kKYWrImc1smvBZkohKtu0v96QFJ+YACk1oozjzN0OSM=
=20jI
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind as "reverse-proxy"

[Tony Finch]

Erich Eckner  wrote:
>
> is it possible to set up a zone in bind similar to a http(s) reverse
> proxy:

You're looking for dnsdist https://dnsdist.org/

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fitzroy: West 5, increasing 6 to gale 8. Rough or very rough. Rain or showers.
Good, occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NS failover as opposed to A record failover

[Tony Finch]

Scott A. Wozny  wrote:
>
> Failures aside, I’m worried about creating a bad user experience EVERY
> time I need to take a DNS server down for patching.

I generally let resolvers handle retry/failover when I'm patching my
authoritative servers. Each resolver that encounters an authoritative
server that is down will retry on another server within a few seconds, and
should send follow-up queries to more responsive auth servers. There are
several retries within the libc resolver timeout, so there are multiple
opportunities to automatically deal with an outage within a reasonable
amount of time. So the badness isn't that terrible. (i.e. less than the
load time for a web page with megabytes of JavaScript.)

I reckon this should be good enough for you, because it's a similar amount
of badness that your users will encounter from your DNS UPDATE web server
failover setup.

If you want something better, on my recursive servers I use keepalived to
move the service IP addresses off servers while they are being patched.
You can do something similar for auth servers, if you have a little
cluster in each location. On your web servers, keepalived and HAproxy is
supposed to be a good combination (though I have not tried it myself).
For servers that are too far apart for layer 2 failover to work, you'll
need to get funky with anycast.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
German Bight: Northwest backing southwest later 4 to 6. Slight or moderate.
Showers. Good, occasionally moderate.___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bind as "reverse-proxy"

[Matus UHLAR - fantomas]

On 26.02.20 15:28, Erich Eckner wrote:
is it possible to set up a zone in bind similar to a http(s) reverse 
proxy:


No. DNS is very far from proxying.

1. The server appears authoritative to clients (the consulted server 
is indeed authoritative).


2. Each request is passed on to the other server (or served from 
cache), but the information is *not* obtained by zone transfers 
(because the other server does not have/allow this).


For records that are managed locally, BIND is authoritative.
For records that are stored elsewhere, BIND is NOT authoritative.

So, either you have authoritative server, or you have not.

What is the point of your request?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Where do you want to go to die?" [Microsoft]
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind as "reverse-proxy"

[Erich Eckner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

is it possible to set up a zone in bind similar to a http(s) reverse 
proxy:


1. The server appears authoritative to clients (the consulted server is 
indeed authoritative).


2. Each request is passed on to the other server (or served from cache), 
but the information is *not* obtained by zone transfers (because the other 
server does not have/allow this).


So far, I had used a forward zone (to assure condition 2), but it violates 
condition 1:


directly queried:
# dig @127.0.0.1 -p 5353 ns.i.eckner.net

; <<>> DiG 9.16.0 <<>> @127.0.0.1 -p 5353 ns.i.eckner.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61359
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ns.i.eckner.net.   IN  A

;; ANSWER SECTION:
ns.i.eckner.net.3600IN  A   193.30.121.109

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Wed Feb 26 15:09:45 CET 2020
;; MSG SIZE  rcvd: 49


querying the "reverse-proxy":
# dig @127.0.0.1 -p 53 ns.i.eckner.net

; <<>> DiG 9.16.0 <<>> @127.0.0.1 -p 53 ns.i.eckner.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30724
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: de8d1f39eca0150901005e567c38203e4e1025c43f9d (good)
;; QUESTION SECTION:
;ns.i.eckner.net.   IN  A

;; ANSWER SECTION:
ns.i.eckner.net.3600IN  A   193.30.121.109

;; Query time: 6 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Feb 26 15:10:00 CET 2020
;; MSG SIZE  rcvd: 88


This is the relevant part of my config (so far):

zone "i.eckner.net" IN {
type forward;
forwarders {
127.0.0.1 port 5353;
};
forward only;
};

Is it possible to fake/force the authoritative-bit in the answer for 
queries below "i.eckner.net"?


regards,
Erich

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl5WgIEACgkQCu7JB1Xa
e1oOlg/+Or2ffpo0YM3po5zv3VZK0q+AAOBqG5MKVvsnJPhoyfZmwmAd0B3ri3j3
105cJP0Y2sKLEWmHgUms28yws7VyTljFik8hJfncOlb3PUS4LTJeI00YjqWTgvKN
i7WgaD/l+DnJD1Hp8PRa1ddHoDqDDqVs2mZcTzr5pVmx1xb9kgsvzu6N+qph+Joj
4zhVZc3hhyTA9RpMcQbX2+uHY67j+p3q4rwHCZkCCs6JF5Y1S/BZSyne+OEOjUUz
giZNHl5Bjld6mAwUNneVFBF6VmbrTAt1W0IKpNwlDcSTX58wDEWZLY4vR1DNDFh3
BTWLqM0rM4yc9VRHdf2gkKCMFKcOtKne0/T+Pi9j2QSBRKrnvg2wwHfCfT4+0zb0
YTiiJV2gsaChXiIf7CIpNa7Uvx0bngOt8xgsY3CrRVyEY6KqnFCSXtcAIQtuoTv4
JMJoBeZLOkWM21AE5W4v4u5xJ4e88ji5T6t+s2G7lHgpjpxdl8fLMdqEGv7JThTR
vd0mlWHztl/0XfjAtEG0uCWCzYkX2F5n/PVAj+a+IiKNB70h7gFyQ9Cz/Z2tUjwG
B+2Gx4W4tev6oTej9ELyMY/6UOlxgw2yh7kKW5/BR9nYTwDgySmXzDb9uOf3N5/i
6EgceIWHDzPd6Z2PnIeCEcmR3IYIXIJSbbT6wKzv0+BGuN1dUF8=
=A0Mn
-END PGP SIGNATURE-
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: NS failover as opposed to A record failover

[Bob Harold]

On Tue, Feb 25, 2020 at 6:38 PM Mark Andrews  wrote:

>
> > On 26 Feb 2020, at 09:51, Scott A. Wozny  wrote:
> >
> > I know this isn’t a question ABOUT BIND, per se, but I think is still a
> question bind-users might have an answer to. I’ve seen various failover
> questions on the list, but nothing that talks specifically about NS records
> (at least nothing in the last decade), so I thought I’d inquire here.
> >
> > I’m familiar with round-robin DNS and using multiple A records for the
> same name. I also understand that most clients, if the top server on the
> list doesn’t respond, will wait ~30 seconds before trying the next address
> on the list. This is pretty good, as far as automatic failover goes, but
> still, having X% of your users (X being down servers / all A records
> offered) wait an extra 30 seconds is not great so I’m going to run a
> regular health check on my front facing web servers from each BIND server
> and, if a server stops responding, change my zone file and reload until the
> server starts responding again, reversing the process. Then X% of my users
> will only need to wait 30 seconds until I fix the zone file (TTL will also
> be about the same frequency as the health checks so worst case scenario
> will be 2xTTL for X% of users having to wait those extra 30 seconds).
> Overall I’m satisfied with this balance between complexity and resiliency,
> particularly considering I can do record manipulation in advance of planned
> maintenance and then this problem only becomes an issue during unexpected
> outages.
>
> There is nothing that requires clients to wait a full thirty seconds
> before moving onto the next address.  In fact Happy Eyeballs (RFC 83050)
> uses sub-second delays before attempting connections to other addresses.
> Yes, you
> can have multiple connection attempts to different servers in flight at
> the same time and just take the one that
> connects first while dropping the others.  The standard socket API
> supports this sort of behaviour but most applications doesn’t use it that
> way.
>
> https://users.isc.org/~marka/ has code samples, that pre-dates Happy
> Eyeballs, that attempts to connect to multiple addresses at once with small
> delays.  Once a connection is established the other attempts are aborted.
>
> There are examples using select(), poll() and multiple threads.
>
> > This is all well and good until I think about failure or maintenance of
> the name servers, themselves. I’ll need to give my registrar my NS IPs for
> my domain but they will not be nearly as flexible regarding changes as I am
> running my own nameservers (TTL will probably be an hour, at the very
> least) which makes maintenance work a MUCH longer process for set-up and
> tear-down, if I have to make NS record changes in coordination with my
> registrar. However, this made me wonder, is NS failure responded to in the
> same way as the failure of an A record? Various Internet randos have
> indicated some DNS clients and resolvers will do parallel lookups and take
> the first response and others have indicated that the “try the next record”
> parameter for NS comms is 5 to 10 seconds rather than 30 and still others
> claim it’s the same as A record failover at 30 seconds before trying the
> next candidate on the list. Is there a definitive answer to this or,
> because it’s client related, are the answers too widely varied to rely upon
> (which is why the answers on the Internet are all over the map)?
>
> Well you have the stub resolver and the recursive server to talk about.
>
> Stub resolvers generally use low second timeouts before moving on to the
> next address but some just shotgun every recursive server.
>
> Recursive servers can do the same thing.
>
> The 30 seconds comes from the TCP connect timeout.  Where the TCP/IP stack
> makes multiple connection attempts over that 30 seconds before giving up.
>
> DNS, initially, is UDP and the client manages retransmission attempts.
> Named uses sub second initial timeouts.  Most of the world is less that
> 200ms RTT from any other point though there are exceptions.
>
> Mark
>
> > Failures aside, I’m worried about creating a bad user experience EVERY
> time I need to take a DNS server down for patching. I can’t be the first
> person to run into this problem. Is it just something people live with (and
> shuffle NS records around all the time) or is NS failover really smoother
> than A record failover and I should concentrate on keeping my A records
> current in case of failure OR planned maintenance?
> >
> > Any feedback would be greatly appreciated.
> >
> > Thanks,
> >
> > Scott
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871