lameness and unreachability
On the APNIC mailing list (sig-dns) a discussion has been begun to try and define the problem needing to be solved (assuming there is one). I'm not sure that the discussion should be mirrored here, but I wanted to call attention to those interested. List info - List-Id: APNIC SIG on DNS issues <sig-dns.lists.apnic.net> List-Archive: <http://www.apnic.net/mailing-lists/sig-dns/> Before spouting too much on my own here, what is the topic that needs to be discussed(on this mailing list)? ...what RIPE defines (or should define) as a problem delegation? ...a means to measure the health of the DNS delegations? ...how ccTLDs go about testing delegations? ...what responsibility a registry has in publicizing their test criteria? I know that some of the above are topics that are not what is desired, but I'm just trying to throw out some suggestions. The reason I am doing this is that there has been a recent spurt in DNS health mailing lists and it would be good if we could consolidate discussions so as not to cross-post, repost, etc. Also, the topics above have either recently appeared or were mentioned at the recent meeting. BTW - I am not saying that RIPE has a lame delegation problem. Stats I've seen are that "bad delegations" are much more rare in the RIPE region than in the ARIN region. There are possibly clear reasons for this - in the ARIN region, delegations are "cut" in the DNS without any pre-testing of servers. Also, ARIN has a lot of delegations that predate ARIN's establishment. Also - I'm shying away from using "lame delegations" based on how it is defined in the RFCs. The suggested name I threw onto the APNIC list is "unreachable zones." -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show.
At 9:39 AM -0400 2003/05/21, Edward Lewis wrote:
Before spouting too much on my own here, what is the topic that needs to be discussed(on this mailing list)?
...what RIPE defines (or should define) as a problem delegation?
This is a good question. IMO, as far as RIPE is concerned (in and of itself), lame delegations (or "unreachable zones") have only to do with delegations within the appropriate reverse DNS space. The forward delegations are handled separately via the ccTLDs, over which RIPE has no control. This isn't to say that the RIPE DNS WG couldn't help define some terms for this issue and suggest some ideas that appear to be workable (based on experience from ARIN, APNIC, etc...), but it doesn't seem to directly impact on RIPE itself.
...a means to measure the health of the DNS delegations?
I think we can be much more objective on this issue. We can categorize the various ways in which servers may have operational problems and be "unreachable", and using that data we can come to some determination about whether or not the entire zone is unreachable. I think that this could be a good discussion to have, or at least to monitor the appropriate part of the APNIC discussion.
...how ccTLDs go about testing delegations?
I think we could talk about how the RIPE NCC does this for the appropriate reverse DNS space, and give some suggestions on how this could be done for the forward delegation space. However, that would need input and coordination from the RIPE NCC, and we'd need a lot of input & feedback from the various ccTLD operators.
...what responsibility a registry has in publicizing their test criteria?
See above.
Also - I'm shying away from using "lame delegations" based on how it is defined in the RFCs. The suggested name I threw onto the APNIC list is "unreachable zones."
I think that is a good term. It covers more than just the specific issue of whether or not a server is "lame" for a particular zone, etc.... I believe that we should expand this to include "unreachable servers", and give some further thought as to the various different failure modes and what they might mean. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Wed, May 21, 2003 at 09:39:54AM -0400, Edward Lewis wrote:
On the APNIC mailing list (sig-dns) a discussion has been begun to try and define the problem needing to be solved (assuming there is one). I'm not sure that the discussion should be mirrored here, but I wanted to call attention to those interested.
List info - List-Id: APNIC SIG on DNS issues <sig-dns.lists.apnic.net> List-Archive: <http://www.apnic.net/mailing-lists/sig-dns/>
Before spouting too much on my own here, what is the topic that needs to be discussed(on this mailing list)?
...what RIPE defines (or should define) as a problem delegation? ...a means to measure the health of the DNS delegations? ...how ccTLDs go about testing delegations? ...what responsibility a registry has in publicizing their test criteria?
Here is the list of tests available in the ZoneCheck v2 tool, with the severity (Fatal/Warning) that are used in the configuration file to check domain in .fr before accepting the delegation. Severity Test Fatal/warning zone transfer possible zone transfer contains data zone transfer contains valid labels F check if server is really recursive F double dash in domain name (pre-IDN) F dash ('-') at start or beginning of domain name F illegal symbols in domain name (RFC1034) F correctness of given nameserver list F given primary nameserver is primary W ICMP answer W nameserver addresses are all on the same subnet (RFC2182) W address shouldn't be part of a bogon prefix F identical addresses F address in a private network (RFC1918) W nameserver's addresses on same subnet (RFC2182) W loopback delegation (RFC1537) F loopback is resolvable (RFC1537) F hostmaster email address is valid F hostmaster MX is not an alias (RFC974) W delegated domain is not an openrelay W domain of the hostmaster email is not an openrelay F 'postmaster' email address is valid (RFC1123) F MX record present (RFC1912) F MX authoritative answer F MX is not an alias (RFC1912) F MX can be resolved absence of wildcard MX F MX syntax is valid for an hostname F coherence between MX and ANY records F NS record present F NS authoritative answer F NS is not an alias (RFC1912) F NS can be resolved W Nameserver IP reverse F NS name has a valid domain/hostname syntax F coherence between NS and ANY records F one nameserver for the domain (RFC2182) F root servers list present W root servers addresses identical to ICANN (RFC2870) F root servers list identical to ICANN (RFC2870) F at least two nameservers for the domain (RFC2182) F SOA record present F SOA authoritative answer F coherence of master with primary nameserver F coherence of serial number with primary nameserver F illegal characters in SOA contact name (RFC1034) F missused '@' characters in SOA contact name (RFC1034) F SOA 'expire' at least 7 days (RFC1912) F SOA 'expire' at least 7 times 'refresh' W fully qualified master nameserver in SOA F illegal characters in SOA master nameserver W SOA 'minimum' less than 3 hours F SOA master is not an alias (RFC1912) W SOA 'refresh' at least 6 hours W SOA 'retry' at least 1 hour F SOA 'retry' lower than 'refresh' (RFC1912) W serial number of the form YYYYMMDDnn (RFC1912) F coherence between SOA and ANY records F TCP connectivity (RFC1035) F UDP connectivity (RFC1035) Now if we could create such kind of list, to check the "good health" of a domain and have people using it as a reference (ie: RIR, TLD, and implemented in the various zone checking tools), it would be a major step forward. Several list should be created as you don't perform the same check for arpa, tld and other domains. Also you certainly want to have some control on the level of checking that should be performed from an "authoritative answer for SOA and NS records" to a full checking including tests of mail delivery for hostmaster, postmaster, ... This could lead to the creation of sublists. Perhaps in a first time could we try to agree on a minimal list of items to check for a domain. -- Stephane D'Alu -- AFNIC http://zonecheck.nic.fr/v2/ The zone checking tool
For educational purposes, I'd like to ask about some of the errors/warnings as listed. I'll try to stay away from tool-specific suggestions, as this isn't the list for your tool. At 17:37 +0200 5/22/03, Stephane D'Alu wrote:
Here is the list of tests available in the ZoneCheck v2 tool, with the severity (Fatal/Warning) that are used in the configuration file to check domain in .fr before accepting the delegation.
Severity Test Fatal/warning F dash ('-') at start or beginning of domain name
According to 1035, that is legal. Or do you mean a - at the beginning of a hostname?
F illegal symbols in domain name (RFC1034)
I don't think there are any - in a 'domain' name. Yes, in a host name.
W ICMP answer
I don't know that this is a concern of DNS - what the other protocols can or can't do.
W nameserver addresses are all on the same subnet (RFC2182)
The problem with this test is the rise of anycast. It's harder to determine remotely if servers are all on the same subnet.
W delegated domain is not an openrelay W domain of the hostmaster email is not an openrelay
That's beyond DNS. A real concern, but if I just want to test DNS, then I don't want to do those tests.
W SOA 'minimum' less than 3 hours W SOA 'refresh' at least 6 hours W SOA 'retry' at least 1 hour
I would think that these are policy dependent - sometimes shortened numbers are a good thing - if you are willing to pay the performance price.
W serial number of the form YYYYMMDDnn (RFC1912)
With the advent of dynamic update, the last is no longer recommended. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show.
Ed Lewis wrote:
W SOA 'minimum' less than 3 hours W SOA 'refresh' at least 6 hours W SOA 'retry' at least 1 hour
I would think that these are policy dependent - sometimes shortened numbers are a good thing - if you are willing to pay the performance price.
"you" is us in certain cases. As discussed in RIPE 203 the refresh and retry values affect the zone server operators. It's useful to check relative consistency, i.e. retry<refresh, refresh + retry < expire etc, but the absolute numbers are probably less important (certain implementation specific boundaries nonwithstanding). The "minimum" value as well as the TTL values affect the overall DNS cache performance, so everybody pays the price. A warning is appropriate for certain thresholds, since zone maintainers dealing with exceptional cases should be able to interpret that warning with a grain of salt.
W serial number of the form YYYYMMDDnn (RFC1912)
I did not yet see the original message, but I guess there's a "not" missing here.
With the advent of dynamic update, the last is no longer recommended.
Well, I'd rephrase that to "there are more cases where this recommendation is inappropriate". Still the vast majority of zones is small and stable, so it's unlikely Dynamic Update will be used there. However, that recommendation has another drawback. I've seen many cases where after initial setup (probably done by an external consultant) subsequent SOA serial changes were left to the GUI interface/server maintenance tool, which just increases the value by '1'. That means you see the common format, you think it encodes the date of the last change and you're fooled. -Peter
On Thu, May 22, 2003 at 11:49:25AM -0400, Edward Lewis wrote:
For educational purposes, I'd like to ask about some of the errors/warnings as listed. I'll try to stay away from tool-specific suggestions, as this isn't the list for your tool.
At 17:37 +0200 5/22/03, Stephane D'Alu wrote:
Here is the list of tests available in the ZoneCheck v2 tool, with the severity (Fatal/Warning) that are used in the configuration file to check domain in .fr before accepting the delegation.
Severity Test Fatal/warning F dash ('-') at start or beginning of domain name
According to 1035, that is legal. Or do you mean a - at the beginning of a hostname?
In fact the test check for a '-' at the beginning or at the end of a label as suggested in the grammar of 1035.
F illegal symbols in domain name (RFC1034)
I don't think there are any - in a 'domain' name. Yes, in a host name.
Test that all characters are in the set [a-z0-9\-]
W ICMP answer
I don't know that this is a concern of DNS - what the other protocols can or can't do.
Agree, this is not directly DNS related (so it is only a warning), but it could sometimes give you a hit on what is wrong.
W nameserver addresses are all on the same subnet (RFC2182)
The problem with this test is the rise of anycast. It's harder to determine remotely if servers are all on the same subnet.
I don't think there are many anycast server for now, but the heuristic used to determine the subnet make it already a policy issue :( And I fear that the rise of anycast server will make it really difficult to check the consistency of the different server for a zone.
W delegated domain is not an openrelay W domain of the hostmaster email is not an openrelay
That's beyond DNS. A real concern, but if I just want to test DNS, then I don't want to do those tests.
That was the point of having a list with different degree of 'completeness', you consider (with a RIR point of view) that a minimal set of test is enough to check the 'reachability of a zone', we consider (with a ccTLD point of view) that these tests should be part of a 'good configuration', but I'm sure that different RIR or ccTLD could have intermediate preferences. We could provide different list of test, where the degree of completeness increase.
W SOA 'minimum' less than 3 hours W SOA 'refresh' at least 6 hours W SOA 'retry' at least 1 hour
I would think that these are policy dependent - sometimes shortened numbers are a good thing - if you are willing to pay the performance price.
These tests are only marked as 'Warning', due to the fact that if you really know what you are doing you could want to go beyond the recommanded values. I would like to say that having some tests with a warning severity, make them serve the purpose of a reminder, and that doesn't hurt as people knowing what they are doing will just considered it as a warning other will be gratefull for the hint.
W serial number of the form YYYYMMDDnn (RFC1912)
With the advent of dynamic update, the last is no longer recommended.
I'll see if there is a way to make an improved test on the serial number (or retire the test otherwise) Sincerly, -- Stephane D'Alu -- AFNIC http://zonecheck.nic.fr/v2/ Check your domain name
At 19:02 +0200 5/22/03, Stephane D'Alu wrote:
In fact the test check for a '-' at the beginning or at the end of a label as suggested in the grammar of 1035.
That section of 1035 is a source of great confusion. Note that the text preceding the parsing rules says: "The following syntax will result in fewer problems with many applications that use domain names (e.g., mail, TELNET)." It doesn't say that the syntax rules are mandatory. In fact, elsewhere: # Because these files are text files several special encodings are # necessary to allow arbitrary data to be loaded. In particular: # # \X where X is any character other than a digit (0-9), is # used to quote that character so that its special meaning # does not apply. For example, "\." can be used to place # a dot character in a label. # # \DDD where each D is a digit is the octet corresponding to # the decimal number described by DDD. The resulting # octet is assumed to be text and is not checked for # special meaning. So, arbitrary octet values are allowed, but isn't 8-bit clean because of the upper==lower case rules.
I don't think there are many anycast server for now, but the heuristic used to determine the subnet make it already a policy issue :(
And I fear that the rise of anycast server will make it really difficult to check the consistency of the different server for a zone.
I've already been slapped by our beloved WG chair (Jim) for the same comment when I accused him of placing both name servers for an ENUM experiment on one LAN. He muttered 'they're anycasted...'
We could provide different list of test, where the degree of completeness increase.
At least a flag to trim back the tests...
These tests are only marked as 'Warning', due to the fact that if you really know what you are doing you could want to go beyond the recommanded values.
Peter mentioned that there is a RIPE document behind this. I wasn't aware of that. (As an aside, there was a short post meeting discussion about where would we publish operations documents - as in within what venue?) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer Your office is *not* a reality-based sit-com TV show.
participants (4)
-
Brad Knowles -
Edward Lewis -
Peter Koch -
Stephane D'Alu