This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
- Previous message (by thread): [RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
- Next message (by thread): [RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Karrenberg
Daniel.Karrenberg at ripe.net
Fri Jul 14 08:53:23 CEST 2000
At 08:47 PM 7/13/00, Brad Knowles wrote: >> There are no problems we can >> detect with 193.in-addr.arpa name service at this point. We will follow up to >> a smaller audience. > > I'm still very concerned about the number of SERVFAIL errors that I previously saw which have since been mysteriously fixed, As I told you privately, SERVFAIL does not tell you very much about the server you test if you use a recursive query. The problem may very well be on another server down the tree towards the name you are trying to resolve, or in the connectivity between the server you test and such other server. You should use a non-recursive query for such tests. +norecurse if you use dig >and I am very, very concerned about the safety of any of the zones served by any of these machines that are both authoritative and caching/recursive. This is not a probem per-se. The main concern with recursion is the load induced by lots of resolvers just pointing at a high-level server, and of course all those people digging away with recursive queries too ;-). This is the main reason for para 2.5 in RFC2870. This is why we recomend turning recursion off on high level servers. Caching incorrect data is a seperate issue which should be addressed by running good server software which is readily available. Caching correct data is not a problem. Yes it can be inconvenient for those who neglect to reduce TTL before making changes. But turning caching off on just some servers is not going to help here. So can we now please take all those innocent people off this thread once and for all. Daniel
- Previous message (by thread): [RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
- Next message (by thread): [RETRANSMISSION] DNS problems with nameservers for .be and 193.in-addr.arpa
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ dns-wg Archives ]