Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On Mon, January 11, 2010 9:10 pm, Matthew Pounsett wrote: I suspect that, even though they threw an error, your registrar went ahead and passed on the same IPv4 address for both name servers to the registry. I think this may have been the problem... I went back in to the registrar's DNS control panel, cleaned everything out and started afresh. In addition to the conventional 'delegate your domain' control function I found that they also allow independent manual tweaking of the glue - I think these two frontends may well have got out of sync (my fault I'm sure for changing things too quickly) and ended up in a bit of a mess. The whole debacle has turned into something of a blessing in disguise however - I've discovered that the registrar provides a free secondary service for domains purchased through them... and their nameserver is dual-stacked too so all the better for my situation! Thanks everyone for the assistance, Mathew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Is an IPv6-only glue/delegation record a problem in a world of IPv4?
I would be grateful if someone might be able to shed some light on an apparent problem I've got with an experimental DNS I have setup. Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems unable to resolve my records and I can't help but feel it's a problem at my end rather than theirs! The domain is v6ns.org, and the record I am attempting to query for is ns1.v6ns.org - here's what the Kloth Dig tool gets: [dig 'ns1.v6ns.org' 'A' +trace] dig: couldn't get address for 'ns1.v6ns.org': failure ; DiG 9.3.2 ns1.v6ns.org A +trace ;; global options: printcmd . 301721 IN NS I.ROOT-SERVERS.NET. . 301721 IN NS J.ROOT-SERVERS.NET. . 301721 IN NS K.ROOT-SERVERS.NET. . 301721 IN NS L.ROOT-SERVERS.NET. . 301721 IN NS M.ROOT-SERVERS.NET. . 301721 IN NS A.ROOT-SERVERS.NET. . 301721 IN NS B.ROOT-SERVERS.NET. . 301721 IN NS C.ROOT-SERVERS.NET. . 301721 IN NS D.ROOT-SERVERS.NET. . 301721 IN NS E.ROOT-SERVERS.NET. . 301721 IN NS F.ROOT-SERVERS.NET. . 301721 IN NS G.ROOT-SERVERS.NET. . 301721 IN NS H.ROOT-SERVERS.NET. ;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms org. 172800 IN NS A2.ORG.AFILIAS-NST.INFO. org. 172800 IN NS A0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS D0.ORG.AFILIAS-NST.org. org. 172800 IN NS C0.ORG.AFILIAS-NST.INFO. org. 172800 IN NS B0.ORG.AFILIAS-NST.org. org. 172800 IN NS B2.ORG.AFILIAS-NST.org. ;; Received 432 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 8 ms v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO) in 4 ms I set the domain up to experiment with IPv6, which could be why I've got a problem... I have a single DNS server with a IPv4 address and two IPv6 addresses. The zone file is as follows: $ORIGIN v6ns.org. $TTL300 @ IN SOA ns1.v6ns.org. dns.newtonnet.co.uk. ( 2010012000 ; Serial 14400 ; Refresh 7200; Retry 950400 ; Expire 300 ) ; Negative Cache TTL IN NS ns1.v6ns.org. IN NS ns2.v6ns.org. ns1 IN 2a01:348:133::a1 ns1 IN A 77.103.161.36 ns2 IN 2a01:348:6:a1::2 The same delegation records are present as glue in the .org nameservers. Local lookups for ns1.v6ns.org (A and records) work fine, as they also do from MenMice's online Dig tool. So why not Kloth's? I can't help but feel it is given the lack of an IPv4 A record for ns2.v6ns.org - either as glue in .org or within my own v6ns.org zone. But should this matter? In the absence of an IPv4 A-record for the ns2.v6ns.org delegation in .org shouldn't their Dig attempt to connect to ns1.v6ns.org instead (yes, they are the same machine but noone else knows this but me... and you!)? I would be grateful for any assistance, and would be more than happy to provide further details if the above is insufficient. Mathew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On Mon, Jan 11, 2010 at 12:29 PM, Mathew J. Newton bind-us...@newtonnet.co.uk wrote: The same delegation records are present as glue in the .org nameservers. While this is not in response to your original question, I am curious. I'm not sure if you were part of the discussion we just had on IRC freenode #ipv6, but querying a .org TLD NS for records for ns1 and ns2.v6ns.org return no actual records, no errors reported, but there seem to be records shown in the ADDITIONAL section of the query response. If I understand this correctly, the lack of an ANSWER section for query would denote there is no ipv6 glue at the TLD? 2001:500:e::1 being a0.org.afilias-nst.info, a .org TLD NS ; DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 ns1.v6ns.org @2001:500:e::1 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38080 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.v6ns.org. IN ;; AUTHORITY SECTION: v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; ADDITIONAL SECTION: ns1.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 ;; Query time: 102 msec ;; SERVER: 2001:500:e::1#53(2001:500:e::1) ;; WHEN: Mon Jan 11 12:44:13 2010 ;; MSG SIZE rcvd: 150 ; DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 ns2.v6ns.org @2001:500:e::1 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 377 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns2.v6ns.org. IN ;; AUTHORITY SECTION: v6ns.org. 86400 IN NS ns2.v6ns.org. v6ns.org. 86400 IN NS ns1.v6ns.org. ;; ADDITIONAL SECTION: ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ;; Query time: 719 msec ;; SERVER: 2001:500:e::1#53(2001:500:e::1) ;; WHEN: Mon Jan 11 12:44:23 2010 ;; MSG SIZE rcvd: 150 An example showing glue in .com/.net: ; DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 ns2.he.net @G.GTLD-SERVERS.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 25892 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns2.he.net.IN ;; ANSWER SECTION: ns2.he.net. 172800 IN 2001:470:200::2 ;; AUTHORITY SECTION: he.net. 172800 IN NS ns1.he.net. he.net. 172800 IN NS ns2.he.net. he.net. 172800 IN NS ns3.he.net. he.net. 172800 IN NS ns4.he.net. he.net. 172800 IN NS ns5.he.net. ;; ADDITIONAL SECTION: ns1.he.net. 172800 IN A 216.218.130.2 ns2.he.net. 172800 IN A 216.218.131.2 ns2.he.net. 172800 IN 2001:470:200::2 ns3.he.net. 172800 IN A 216.218.132.2 ns3.he.net. 172800 IN 2001:470:300::2 ns4.he.net. 172800 IN A 216.66.1.2 ns4.he.net. 172800 IN 2001:470:400::2 ns5.he.net. 172800 IN A 216.66.80.18 ns5.he.net. 172800 IN 2001:470:500::2 ;; Query time: 100 msec ;; SERVER: 192.42.93.30#53(192.42.93.30) ;; WHEN: Mon Jan 11 12:54:02 2010 ;; MSG SIZE rcvd: 334 -- aRDy Music and Rick Dicaire present: http://www.ardynet.com http://www.ardynet.com:9000/ardymusic.ogg.m3u ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 11 Jan 2010, at 18:29, Mathew J. Newton wrote: Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems unable to resolve my records and I can't help but feel it's a problem at my end rather than theirs! It's their end The domain is v6ns.org, and the record I am attempting to query for is ns1.v6ns.org - here's what the Kloth Dig tool gets: v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO) in 4 ms If I retry this DNS-query, I get: ; DiG 9.4.3-P3 @A2.ORG.AFILIAS-NST.INFO ns1.v6ns.org. ; (2 servers found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52072 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.v6ns.org. IN A ;; AUTHORITY SECTION: v6ns.org. 86400 IN NS ns1.v6ns.org. v6ns.org. 86400 IN NS ns2.v6ns.org. ;; ADDITIONAL SECTION: ns1.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 ;; Query time: 28 msec ;; SERVER: 2001:500:40::1#53(2001:500:40::1) ;; WHEN: Mon Jan 11 20:26:17 2010 ;; MSG SIZE rcvd: 150 Which seems perfectly valid for a v4v6 delegation. I set the domain up to experiment with IPv6, which could be why I've got a problem... Shouldn't, but might... I'm running a v4-v6 DNS right now and I've been through some trouble to get it working... I have a single DNS server with a IPv4 address and two IPv6 addresses. The zone file is as follows: $ORIGIN v6ns.org. $TTL300 @ IN SOA ns1.v6ns.org. dns.newtonnet.co.uk. ( 2010012000 ; Serial 14400 ; Refresh 7200; Retry 950400 ; Expire 300 ) ; Negative Cache TTL IN NS ns1.v6ns.org. IN NS ns2.v6ns.org. ns1 IN 2a01:348:133::a1 ns1 IN A 77.103.161.36 ns2 IN 2a01:348:6:a1::2 This is NOT how it's configured in the Glue: ns1.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 Local lookups for ns1.v6ns.org (A and records) work fine, as they also do from MenMice's online Dig tool. So why not Kloth's? Possibly because it's broken. It works fine here; results conform to the zone you listed above. I can't help but feel it is given the lack of an IPv4 A record for ns2.v6ns.org - either as glue in .org or within my own v6ns.org zone. But should this matter? In the absence of an IPv4 A-record for the ns2.v6ns.org delegation in .org shouldn't their Dig attempt to connect to ns1.v6ns.org instead (yes, they are the same machine but noone else knows this but me... and you!)? I'm not a DNS expert, but I think it should. However, currently there IS a A-glue for ns2 Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On Mon, January 11, 2010 5:57 pm, Rick Dicaire wrote: While this is not in response to your original question, I am curious. I'm not sure if you were part of the discussion we just had on IRC freenode #ipv6, but querying a .org TLD NS for records for ns1 and ns2.v6ns.org return no actual records, no errors reported, but there seem to be records shown in the ADDITIONAL section of the query response. Hi Rick, Thanks for that. I wasn't in that discussion, were you discussing this sort of issue? (for the .org zones in particular?) I could be wrong, but would I be right in saying that glue records being served up under the ADDITIONAL section is perfectly valid, not least because by definition they are no authoritative for those records and hence can be ignored (and/or not cached)? I'm guessing here... If I understand this correctly, the lack of an ANSWER section for query would denote there is no ipv6 glue at the TLD? Just to clarify, I'm seeing these weird results for the A records too - I don't know if that matters either way. However, surely there must be some glue otherwise where are they getting the results from? Mathew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On Mon, January 11, 2010 6:27 pm, Miles Mccredie wrote: FWIW, this is what I'm seeing from an IPv4 only host. Not sure if the unexpected source is the problem that kloth.net is seeing or whether it's the result of putting *;; reply from unexpected source: 77.103.161.36#60741, expected 77.103.161.36#53 ;; reply from unexpected source: 77.103.161.36#60741, expected 77.103.161.36#53 ;; connection timed out; no servers could be reached It never rains but it pours?! I too have seen that on occasion. I think it's down to my crappy D-Link router, or rather its implementation of NAT. I've got a Cisco router sat here waiting to take its place when I can find time to get round to it. FWIW, at least one of the afilias hosts had the same IPv4 address for ns[12].v6ns.org. ns1.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 Hmm.. That's interesting. I know for a fact that my registrar wouldn't allow me to enter two servers with the same address, however within my zone I may have had ns[12] set with IPv4 records set for a period (a few days ago). This makes me wonder where .org is getting its records from - a combination of glue provided by the registrar and cached results from my zone? Mathew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 2010/01/11, at 12:57, Rick Dicaire wrote: If I understand this correctly, the lack of an ANSWER section for query would denote there is no ipv6 glue at the TLD? No, that would indicate that the name server you queried is not authoritative for the record you queried about. Glue, by definition, is non-authoritative data, and so appears in the ADDITIONAL section, as in the example you pasted. By contrast, Verisign's servers have long included glue in the ANSWER section. This is widely considered to be at best suboptimal, and by many (or most) to be a bug. Verisign has indicated that this behaviour is coming to an end, although I don't recall off the top of my head if they've announced a date. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 2010/01/11, at 12:29, Mathew J. Newton wrote: Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems unable to resolve my records and I can't help but feel it's a problem at my end rather than theirs! The problem may be at Kloth.. but at least one of the many possible problems they might be having could be corrected by a slightly different configuration at your end. According to RFC you must have at least two name servers on different networks for each delegation. I interpret this as two name servers *per address protocol* that you want to support. So, if you want to support queries from the v4 Internet (there may be reasons you don't) then you should have at least two name servers responding to queries over v4. Koth may be having network trouble on v4 which prevents them from getting at 77.103.161.0/24. If that is the problem, a second v4 name server in a different subnet (at a different site) might present them with a path to a name server that can answer their query. This is the reason why there is a redundancy requirement in the RFC. That said.. there is nothing wrong with a name server that only answers using one address protocol or the other. And there is functional precedent in infrastructure for name servers that are only on v6. j.gtld.biz, which is authoritative for the us. zone only has a v6 address. While this occasionally confuses an operator here and there, the DNS likes it just fine. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 2010/01/11, at 14:48, Mathew J. Newton wrote: FWIW, at least one of the afilias hosts had the same IPv4 address for ns[12].v6ns.org. ns1.v6ns.org. 86400 IN A 77.103.161.36 ns1.v6ns.org. 86400 IN 2a01:348:133::a1 ns2.v6ns.org. 86400 IN A 77.103.161.36 ns2.v6ns.org. 86400 IN 2a01:348:6:a1::2 Hmm.. That's interesting. I know for a fact that my registrar wouldn't allow me to enter two servers with the same address, however within my zone I may have had ns[12] set with IPv4 records set for a period (a few days ago). This makes me wonder where .org is getting its records from - a combination of glue provided by the registrar and cached results from my zone? The org. name servers are authoritative-only.. no caching takes place. Also, the registry is contractually prevented from modifying zone data supplied by the registrars, which would preclude it from cloning the v4 address from one name server to the other. Besides, as database objects, the relationship between one name server and the other would be pretty loose, and there'd be no reasonable way to assume that ns2.v6ns.org is authoritative for everything that ns1.v6ns.org is authoritative for. I suspect that, even though they threw an error, your registrar went ahead and passed on the same IPv4 address for both name servers to the registry. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On 2010/01/11, at 15:16, Matthew Pounsett wrote: By contrast, Verisign's servers have long included glue in the ANSWER section. This is widely considered to be at best suboptimal, and by many (or most) to be a bug. Verisign has indicated that this behaviour is coming to an end, although I don't recall off the top of my head if they've announced a date. Following up my own email.. someone pointed me to the specific reference to the vague memory I had floating around in my head: https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004838.html To summarize, the behaviour I mentioned above is scheduled to go away on March 1st, 2010.. at which point the com/net servers should start answering with glue in the ADDITIONAL section. Matt ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?
On Mon, January 11, 2010 8:33 pm, Matthew Pounsett wrote: The problem may be at Kloth.. but at least one of the many possible problems they might be having could be corrected by a slightly different configuration at your end. Thanks Matt for your (and others) continued help with this - it is much appreciated. According to RFC you must have at least two name servers on different networks for each delegation. I interpret this as two name servers *per address protocol* that you want to support. So, if you want to support queries from the v4 Internet (there may be reasons you don't) then you should have at least two name servers responding to queries over v4. I will do eventually. Given this is just for personal use/experimentation I may get one of the free DNS providers to act as a secondary. Koth may be having network trouble on v4 which prevents them from getting at 77.103.161.0/24. If that is the problem, a second v4 name server in a different subnet (at a different site) might present them with a path to a name server that can answer their query. This is the reason why there is a redundancy requirement in the RFC. I did think that, but then I can force them to use my server (using the @ option) and they resolve quite happily. It seems to be somewhere between the .org and server and mine that they have trouble with! That said.. there is nothing wrong with a name server that only answers using one address protocol or the other. And there is functional precedent in infrastructure for name servers that are only on v6. j.gtld.biz, which is authoritative for the us. zone only has a v6 address. While this occasionally confuses an operator here and there, the DNS likes it just fine. That's good to know - I thought I was trying to do something that was fundamentally forbidden! Mathew ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users