If you want to change the legal syntax of hostnames then write a RFC. As it stands RFC 952 + RFC 1123 define the legal syntax for hostnames. Even IDN maps back to RFC 952 + RFC 1123 at the DNS level. IDN does NOT permit underscore.
Named, by default, allows the lookup any name it is possible to encode in the DNS. Named, by default, only enforces check-name rules on master servers where the operator has the *choice* to disable the check if they wish to. This is a data entry check. It does more good than bad. Named also checks that NS records targets have address records. Named also checks that MX records targets have address records. Named also checks that CNAME records don't have other data. All of these catch operator errors. We have written plenty of RFC's to extend the DNS which include increasing the packet size. All of these are standards track. Almost all of the offending CPE devices started developement well (years) after these RFC's were published. So yes we can complain especially when they don't even meet the base specification which lots of them don't. Mark In message <[email protected]>, Paul Vixie writes: > > > Mark Andrews wrote: > > In message <[email protected]>, hua peng writes: > >> IIRC BIND doesn't permit an A record whose label has a underscore > >> included, for example, this one: > >> > >> aa_bb.google.com. 300 IN A 74.125.128.106 > >> > >> what RFC item is it influenced by? > >> Thanks. > > > > RFC 952, RFC 1123 and RFC 1034. Now if aa_bb.google.com is not a > > host you can turn the check off but 99.9999% of the time the owner > > name of a A record is being used as a hostname. > > mark, it's ok, the joke's over. anyone who wants to enforce RFC 952 in > their gethostbyname() libc call should feel free, but, the time to try > to enforce this in any part of DNS was maybe 1995 and probably not even > then. > > we can't righteously complain about middleboxes that think they know > what UDP/53 payloads have to look like and thus prevent EDNS from being > widely deployed, while at the same time saying that BIND's zone file > parser knows what a host name ought to look like (even if you're right > 99.9999% of the time). > > vixie > > > --------------020206050104070907050201 > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > <html><head> > <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> > </head><body bgcolor="#FFFFFF" text="#000000"><br> > <br> > Mark Andrews wrote: > <blockquote cite="mid:[email protected]" > type="cite"> > <pre wrap="">In message <a class="moz-txt-link-rfc2396E" href="mailto:5387E > [email protected]"><[email protected]></a>, hua peng writes: > </pre> > <blockquote type="cite"><pre wrap="">IIRC BIND doesn't permit an A record w > hose label has a underscore > included, for example, this one: > > aa_bb.google.com. 300 IN A 74.125.128.106 > > what RFC item is it influenced by? > Thanks. > </pre></blockquote> > <pre wrap=""><!----> > RFC 952, RFC 1123 and RFC 1034. Now if aa_bb.google.com is not a > host you can turn the check off but 99.9999% of the time the owner > name of a A record is being used as a hostname.</pre> > </blockquote> > <br> > mark, it's ok, the joke's over. anyone who wants to enforce RFC 952 in > their gethostbyname() libc call should feel free, but, the time to try > to enforce this in any part of DNS was maybe 1995 and probably not even > then.<br> > <br> > we can't righteously complain about middleboxes that think they know > what UDP/53 payloads have to look like and thus prevent EDNS from being > widely deployed, while at the same time saying that BIND's zone file > parser knows what a host name ought to look like (even if you're right > 99.9999% of the time).<br> > <pre wrap="">vixie > </pre> > </body></html> > > --------------020206050104070907050201-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
