Re: [DNSOP] new version of IPv6 rDNS for ISPs
Joe Abley joe.ab...@icann.org wrote: If there was a possible solution where a customer device could auto-register a name using dynamic DNS, how would it know what nameservers to send the UPDATE messages to? Extract the MNAME from the closest-enclosing SOA? How do you find the closest-enclosing SOA, bearing in mind that the address concerned might previously have been used by someone else, and hence the blah.blah.ip6.arpa owner name might already exist? Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authority section of its reply (or possibly in the answer section though that's unlikely). http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
Joe Abley joe.ab...@icann.org wrote: I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? Are name servers allowed to leave out the SOA record? It would break negative cacheing. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
John Levine jo...@taugh.com wrote: Why do you think that a host that is not a server and will never be contacted by (non-malicious) other hosts needs a name? Is there such a thing as a host that is not a server? Multicast DNS and DNS-SD exist so that you can discover devices and services on your lan. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 2012-11-23, at 06:28, Tony Finch d...@dotat.at wrote: Joe Abley joe.ab...@icann.org wrote: I think you skipped a step -- you need to find the zone cut before you can find the nameservers responsible for the zone. I guess I do that by asking for blah.ip6.arpa/IN/SOA and checking the authority section, but what if the authority section is empty because of software choices in some nameserver? Are name servers allowed to leave out the SOA record? It would break negative cacheing. I was being pessimistic. If that authority-section SOA was frequently missing (e.g. for devices behind home gateways) would anything break from the perspective of stub resolvers? I can't think of anything; hence I assume it's broken. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] finding the closest delegation
On 23 Nov 2012, at 11:17, Tony Finch d...@dotat.at wrote: Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authority section of its reply (or possibly in the answer section though that's unlikely). http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery We have been here before. The ENUM name space has comparable properties to ip6.arpa: lots of labels, irregular delegation points and sparse population. Some ENUM applications and use cases had a need to find the closest encloser too. So a long time ago, I helped write up something similar for the ENUM WG -- http://tools.ietf.org/html/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was apparently a Very Bad Thing to treat data from the Authority Section as an answer from the DNS: resolving servers could do this, but nothing else apparently. I suspect Mark's draft may have been killed because of that too. FWIW there were other religious issues which meant that ENUM draft ended up going nowhere. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 23 Nov 2012, at 11:28, Tony Finch d...@dotat.at wrote: Are name servers allowed to leave out the SOA record? Yes. Though it depends on what the question was, which server you ask and what data it has. RFC2308 lists some examples of valid NXDOMAIN/NODATA responses containing no SOA record. It would break negative cacheing. So what? It's not compulsory to implement or support that. Which would of course be a Bad Idea. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] finding the closest delegation
Just use DNSSEC, the RRSIG records tell you the apex of the zone :-) Olafur On 23/11/2012 06:42, Jim Reid wrote: On 23 Nov 2012, at 11:17, Tony Finch d...@dotat.at wrote: Just query for the SOA at the full RDNS name, and the name server will return the zone apex name and SOA record in the authority section of its reply (or possibly in the answer section though that's unlikely). http://tools.ietf.org/html/draft-andrews-dnsext-soa-discovery We have been here before. The ENUM name space has comparable properties to ip6.arpa: lots of labels, irregular delegation points and sparse population. Some ENUM applications and use cases had a need to find the closest encloser too. So a long time ago, I helped write up something similar for the ENUM WG -- http://tools.ietf.org/html/draft-ietf-enum-void-02 -- and was told I was a naughty boy. It was apparently a Very Bad Thing to treat data from the Authority Section as an answer from the DNS: resolving servers could do this, but nothing else apparently. I suspect Mark's draft may have been killed because of that too. FWIW there were other religious issues which meant that ENUM draft ended up going nowhere. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new version of IPv6 rDNS for ISPs
On 21 November 2012 15:01, Lee Howard l...@asgard.org wrote: You may remember this draft from a couple of years ago. People keep asking me what a residential ISP should do for IPv6 PTR records, and I keep repeating what's in the draft. The intent is to document existing solutions, since prepopulating PTRs like we did in IPv4 doesn't work. Last time I brought it to DNSOP, there was interest, but not necessarily as a working group document. Since it's been a while, and the operator community is still asking for guidance, I've updated it, and would like a renewed review of it as an individual submission (unless this WG or v6ops wants it). I'm in support of this document being published. One observation is that the delegation to CPE routers (home gateways) is contradictory to RFC6092: REC-8 By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server. Not suggesting delegation to CPE shouldn't happen, but would it would negate this requirement. Regards Daryl ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] finding the closest delegation
On 2012-11-23 2:34 PM, Mark Andrews wrote: ... There is nothing wrong with using the SOA record from the -ve response. Named has been doing it for about 15 years in nslookup. If it is not there it falls back to stripping a label at a time until it gets the SOA record. indeed not. i think mark means nsupdate here. the history of this is, i wrote for late model bind8 a function called res_findzonecut(), which was part of integrating a contributed implementation of RFC 2136, which i'd been the editor and main author of. the comments at the top of lib/res/res_findzonecut.c are shown below. there's nothing untoward, or spec-violating, or even spec-bending going on here. /* * int * res_findzonecut(res, dname, class, zname, zsize, addrs, naddrs) * find enclosing zone for a dname,class, and some server addresses * parameters: * res - resolver context to work within (is modified) * dname - domain name whose enclosing zone is desired * class - class of dname (and its enclosing zone) * zname - found zone name * zsize - allocated size of zname * addrs - found server addresses * naddrs - max number of addrs * return values: * 0 - an error occurred (check errno) * = 0 - zname is now valid, but addrs[] wasn't changed * 0 - zname is now valid, and return value is number of addrs[] found * notes: * this function calls res_nsend() which means it depends on correctly * functioning recursive nameservers (usually defined in /etc/resolv.conf * or its local equivilent). * * we start by asking for an SOAdname,class. if we get one as an * answer, that just means dname,class is a zone top, which is fine. * more than likely we'll be told to go pound sand, in the form of a * negative answer. * * note that we are not prepared to deal with referrals since that would * only come from authority servers and our correctly functioning local * recursive server would have followed the referral and got us something * more definite. * * if the authority section contains an SOA, this SOA should also be the * closest enclosing zone, since any intermediary zone cuts would've been * returned as referrals and dealt with by our correctly functioning local * recursive name server. but an SOA in the authority section should NOT * match our dname (since that would have been returned in the answer * section). an authority section SOA has to be above our dname. * * however, since authority section SOA's were once optional, it's * possible that we'll have to go hunting for the enclosing SOA by * ripping labels off the front of our dname -- this is known as doing * it the hard way. * * ultimately we want some server addresses, which are ideally the ones * pertaining to the SOA.MNAME, but only if there is a matching NS RR. * so the second phase (after we find an SOA) is to go looking for the * NS RRset for that SOA's zone. * * no answer section processed by this code is allowed to contain CNAME * or DNAME RR's. for the SOA query this means we strip a label and * keep going. for the NS and A queries this means we just give up. */ paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
